Multipolygonwahnsinn - oder: Durchblick war gestern!

Taunide · 2013-08-09 15:05:06

streckenkundler wrote:

MP's mit mehreren Outer sind zwar zugelassen, ich finde diese aber doch sehr unschön. Wenn man zu einer Fläche neuere Erkenntnisse hat und eine Teilfläche aus dem MP abschneiden und als simple Fläche weiterverarbeiten will, weigert sich z.B. JOSM zu schneiden: Es kann MP's mit mehreren Outer nicht verarbeiten.

Wir mappen nicht für Editoren oder? JOSM oder Potlatch sind nicht das Mass aller Dinge. Ich schneide auch schon mal Flächen aus einem MP heraus und verarbeite sie als Einzelelemente weiter, aber das kommt wohl eher selten vor. Ich war auch mal ein Anhänger der "Viele Inner, Eine Outer" Theorie. Ist aber Krampf wenn die Outer-Grenze des Waldgebiets 100km lang ist und 400 Ecken hat. Besonders wenn man dann feststellt dass sie noch zu grob gemappt ist, oder neue Sat-Bilder nahelegen, dass jemand früheres die Baumschatten mitgemappt hat o.ä. Feinarbeiten nötig sind, wo aus den 400 Ecken dann 1600 werden. Das schafft man kaum fürs ganze Multipolygon auf einen Streich, was es dann nützlich macht, "neue" überarbeitete Outers, von älteren zu trennen.

Hm... wenn man vielen MP-Monstern Herr werden und sie in handhabbare Stücke teilen will, wird man an einer neuen Nummer nicht umhin kommen....

Das war schon klar! Und um nicht nur aus einem Monster zwei neue zu machen, behält man sinnvollerweise das, allen Mappern der Gegend eh schon gut vertraute alte Monster! Eine Struktur, wo ich weiss, das gute alte 69.xxx Polygon hat eben die und die Eigenheiten, und das 67.xxx drei Ecken weiter jene, ist eben immer noch besser als wenn aus den 2 plötzlich 10 MP's draus geworden sind, jetzt alle mit ähnlichen 1.73x.xxx Nummern, alle kleiner als die ursprünglichen, aber immer noch weit entfernt davon gut wartbar zu sein, oder auch nur sinnvoller lokal aufgeteilt. Das Gegenteil von Gut ist nämlich immer Gut gemeint, nicht bloß allein in der Politik.
Ich mag beim Mappen nicht noch eine Exceltabelle oder sowas offen haben oder pflegen für all die ähnlichen Nummern, da hört's nämlich auf mit dem Spaß.

...und wir brauchen den Datentyp Polygon und sollten möglichst OGC-Konform sein.

Vorsicht, mit Konformitäten und angeblichen "Sachzwängen" lässt sich auch eine Menge begründen, was absoluter Scheiss ist. Solche Begründungen sind deshalb für sich allein nie ausreichend.

Last edited by Taunide (2013-08-09 15:06:53)

wambacher · 2013-08-09 15:28:36

Taunide wrote:

Eine Struktur, wo ich weiss, das gute alte 69.xxx Polygon hat eben die und die Eigenheiten, und das 67.xxx drei Ecken weiter jene, ist eben immer noch besser als wenn aus den 2 plötzlich 10 MP's draus geworden sind, jetzt alle mit ähnlichen 1.73x.xxx Nummern, alle kleiner als die ursprünglichen, aber immer noch weit entfernt davon gut wartbar zu sein, oder auch nur sinnvoller lokal aufgeteilt.

Ich glaube, du hast meinen kleine Beitrag zur "Nummernvergabe" nicht oder nur flüchtig gelesen . Die Ids neuer Relationen werden aufsteigend vergeben und das kann nicht beeinflußt werden. Damit muß du leben.

Ich habe mir öfters geholfen indem ich vernünftige note=* an die Relation gehängt habe; diese werden dann in Josm angezeigt, wenn es keinen Namen oder Ref gibt. Bei den PLZ-Gebieten ist das sogar üblich.

Gruss
Walter

streckenkundler · 2013-08-09 16:21:44

Taunide wrote:

Wir mappen nicht für Editoren oder?

Nein natürlich nicht! Deswegen schrieb ich ja auch unschön. Die Nichtbearbeitbarkeit eines MP's mit mehreren geschlossenen Outer ist etwas, was zumindestens im JOSM fehlt. Da JOSM mit seinem Funktionsumfang durchaus mit einem GIS-Programm wie Q-Gis, oder ArcGIs vergleichbar ist, ist das ein Feature, was schlichtweg fehlt.
Ich bin trotzdem der Meinung, daß mehrere geschlossene Outer in einem MP i.d.R. nicht nötig sind.

Taunide wrote:

Und um nicht nur aus einem Monster zwei neue zu machen, behält man sinnvollerweise das, allen Mappern der Gegend eh schon gut vertraute alte Monster!

Manchmal sollte mann aber doch einen Schnitt machen. Ich erinnere an die Acker-Monster im Oderbruch, daß hier schon mal Thema war: http://www.openstreetmap.org/#map=11/52 … 3&layers=N Ich mag da nicht ran, aber da ist soviel falsch... daß man es eigentlich löschen und als kleinteilige und viel mehr Einzelflächen neu erfassen muß. Da ist z.T. alles mineinander vermanscht: Grünland, Residental, Flüsse, Gräben, Wald, Feuchtgebiete... Da hab ich aber keine Lust darauf.

Taunide wrote:

Vorsicht, mit Konformitäten und angeblichen "Sachzwängen" lässt sich auch eine Menge begründen, was absoluter Scheiss ist. Solche Begründungen sind deshalb für sich allein nie ausreichend.

Hm... sehe ich anders... Ein gewisses Level sollte schon da sein... aber lassen wir das...

Gruß,

Sven

streckenkundler · 2013-08-09 16:28:53

SunCobalt wrote:

Woher die 2000er Grenze kommt und was es für Implikationen hätte, wenn man die Grenze aufhebt, weiß ich nicht

Das würde mich mal interessieren.

Sven

EvanE · 2013-08-09 18:40:57

streckenkundler wrote:

SunCobalt wrote:
Woher die 2000er Grenze kommt und was es für Implikationen hätte, wenn man die Grenze aufhebt, weiß ich nicht
Das würde mich mal interessieren.

Hallo Sven

Einen Weg mit mehreren 100 Punkten zu bearbeiten, ist recht lästig. Also hat man aus Gründen der Praktibilität eine großzügig bemessene Grenze gewählt, die dennoch von einigen Mappern weitgehend ausgenutzt wird.

Das gleiche Problem hat man auch bei sehr langen Routen-Relationen (die Member-Zahl ist nicht begrenzt). Dort löst man das Problem, indem man solche Routen in (immer noch große) Teilstücke zerlegt und für die Gesamt-Route eine Relation mit type=superroute verwendet.

Unabhängig von den Problemen beim Bearbeiten mag eine lange Knoten-/Member-Liste auch ungünstig für die DB sein.

Siehe auch API v0.6 (Archive)#New_limits oder die Erläuterungen zu API v0.6#Capabilities: GET /api/capabilities

Edbert (EvanE)

streckenkundler · 2013-08-09 20:46:22

Hallo Edbert,

EvanE wrote:

Einen Weg mit mehreren 100 Punkten zu bearbeiten, ist recht lästig. Also hat man aus Gründen der Praktibilität eine großzügig bemessene Grenze gewählt, die dennoch von einigen Mappern weitgehend ausgenutzt wird.

Also ist es bis hier hin der Grund erst mal nur die Praktikabilität. Also eine "künstliche" Grenze, um dem Mapper nicht dazu zu verleiten, übergroße Monster zu schaffen.

EvanE wrote:

Das gleiche Problem hat man auch bei sehr langen Routen-Relationen (die Member-Zahl ist nicht begrenzt). Dort löst man das Problem, indem man solche Routen in (immer noch große) Teilstücke zerlegt und für die Gesamt-Route eine Relation mit type=superroute verwendet.

Also ein irgendwie Hilfskonstrukt, um dennoch die API-Grenzen zu überschreiten...

EvanE wrote:

Unabhängig von den Problemen beim Bearbeiten mag eine lange Knoten-/Member-Liste auch ungünstig für die DB sein.

Für die DB glaube ich das nicht, der DB sollte und muß es egal sein. Wenn, dann eher in Hinblick auf Multiusernutzungsfähigkeit, gleicheitiges Bearbeiten und Aktualisieren von Knoten-Daten und deren Replikation beim angrenzenden Bearbeiter, sowie der Signallaufzeit zwischen erstellen, einspielen, Datenbankprüfung, Speichern; kombiniert mit einem erneuten Abruf von Dritten...ect... oder der Internetverbindung...

EvanE wrote:

Siehe auch API v0.6 (Archive)#New_limits oder die Erläuterungen zu API v0.6#Capabilities: GET /api/capabilities

Die 2000er Grenze ist ist immer nur in der der Soll-und Möglichkeitsform erwähnt, Ein Grund, warum es diese gibt, ist nicht genannt. Es wäre mir auch neu, wenn es bei einem SQL-Server, ob My-SQL, Qracle, IBM, MS oder Postgres (was anders steht nicht dahinter) eine Grenze der Objektgröße gäbe.

Mit anderen Worten, in besonderen Fällen (besonders im Wki erläurtert) sollte es möglich sein, fehlerfrei Objekte mit Knotenzahl >2000 zu erstellen und zu verarbeiten. Man sollte sie aber nach Möglichkeit vermeiden.

Viele Grüße,

Sven

Last edited by streckenkundler (2013-08-09 20:48:47)

EvanE · 2013-08-11 15:20:28

streckenkundler wrote:

Die 2000er Grenze ist ist immer nur in der der Soll-und Möglichkeitsform erwähnt, Ein Grund, warum es diese gibt, ist nicht genannt. Es wäre mir auch neu, wenn es bei einem SQL-Server, ob My-SQL, Qracle, IBM, MS oder Postgres (was anders steht nicht dahinter) eine Grenze der Objektgröße gäbe.
Mit anderen Worten, in besonderen Fällen (besonders im Wki erläurtert) sollte es möglich sein, fehlerfrei Objekte mit Knotenzahl >2000 zu erstellen und zu verarbeiten. Man sollte sie aber nach Möglichkeit vermeiden.

Hallo Sven

Der Grund ist die Praktikabilität. Irgendeine Grenze muss man schließlich setzen und die darf man dann auch nicht mehr überschreiten.

Solche scheinbar 'willkürlichen' Grenzen gibt es ja einige.
- min-/max-Version
- maximale Fläche für eine Anfrage
- maximale Menge für Trackpoints in einer Anfrage
- maximale Zahl der Objekte in einem Änderungssatz
- maximale Zeit bis ein Ändrungssatz automatisch geschlossen wird
- maximale Zeit bis Timeout
- maximale Anzahl der Zeichen in einem Value
- ...

Die dienen auch dazu, durch feste Obergrenzen die Datenbank besser optimieren zu können. Bei mehreren Milliarden Punkten, mehreren 100 Milionen Wegen und mehreren Millionen Relationen ergibt jede Millisekunde Ersparnis einen spürbaren Effekt für die Gesamtperformance.

Persönlich finde ich die 2000er Grenze für Knoten in einem Weg viel zu groß. Nach meiner Meinung würde 1000 Knoten dafür völlig ausreichen.

Edbert (EvanE)

fireball2 · 2013-08-12 11:56:35

Hallo Leute, ich muss mich leider noch mal melden zur Problematik "Touching inner Rings" (siehe Seite 16 Post 379). Ich habe testweise dieses Objekt Ende Juli derart "repariert", wie es Benutzer "streckenkundler" im Post 380 beschrieben hatte.

streckenkundler wrote:

Ich persönlich hinterlasse keine touching inner Rings. Ich grenze eine taglose inner Fläche ab, die die betreffenden inner-Flächen umfasst und entlasse dann die betreffenden inner-Flächen aus dem MP und lasse sie als simple Flächen stehen.

Leider meint OSMI noch immer es gäbe "touching inner rings" obwohl ich die beiden berührenden Objekte (1, 2) aus dem Multipolygon (role=inner) herausgenommen habe. Stattdessen habe ich nun dieses taglose inner "eingebaut".

Wo meint Ihr, liegt jetzt das "Problem", an OSMi oder an meiner "falschen" Reparatur?
Eine Diskussion über die Bauweise des Objekts selbst oder das "touching inner rings" eigentlich keine Fehler sind, brauchen wir an dieser Stelle nicht zu führen. Mich würde lediglich interessieren, wie man mehrere zusammenliegende inner-Bereiche derart aufbaut, so dass OSMi nicht mehr meckert. Geht das überhaupt? OK, vermutlich indem man zwischen den einzelnen Flächen einen kleinen Abstand läßt, aber wenn es diesen in der Realität tatsächlich nicht gibt, wie dann? Gruß fireball2

streckenkundler · 2013-08-12 12:21:07

Hei,

fireball2 wrote:

Hallo Leute, ich muss mich leider noch mal melden zur Problematik "Touching inner Rings" (siehe Seite 16 Post 379). Ich habe testweise dieses Objekt Ende Juli derart "repariert", wie es Benutzer "streckenkundler" im Post 380 beschrieben hatte.

So ist es meiner Ansicht nach richtig. Das hängt wahrscheinlich am Aktualisierungsdatum OSMI. so, wie das jetzt ist, sollte keine Touching-Inner Rings- Meldung mehr kommen.

Sven

fireball2 · 2013-08-12 12:33:22

Das dürfte eben leider nicht der Fall sein. Genau aus diesem Grund melde ich mich doch erst jetzt wieder zu dieser Problematik, weil ich einige Aktualisierungen vom OSMi abgewartet habe.
- meine Änderungen fanden am 31. Juli statt (klick)
- OSMi wurde seitdem mehrmals und zuletzt am 9. August aktualisiert
Wir können gern noch ein wenig abwarten, aber vermutlich läuft es darauf hinaus, dass OSMi hier etwas (zu) feinfühlig Fehler anzeigt, oder?

Oli-Wan · 2013-08-12 12:45:36

Nein. Das MP hat nur einen inneren Ring - wie sollen sich da mehrere innere Ringe berühren?

Der OSM Inspector hat derzeit noch ein paar andere Macken - vgl. http://forum.openstreetmap.org/viewtopic.php?id=22067 - und mir sind auch schon andere vermeintliche Fehler begegnet, die bereits vor dem angegebenen Aktualisierungsdatum behoben wurden. Da scheint es ein Problem mit dem Datenimport zu geben - aber genaueres dürfte nur Frederik wissen.

Wolmatinger · 2013-08-12 14:09:43

BTW, weshalb ist dies ein MP? http://www.openstreetmap.org/browse/way/44687805

streckenkundler · 2013-08-12 14:16:17

Hei,

Wolmatinger wrote:

BTW, weshalb ist dies ein MP? http://www.openstreetmap.org/browse/way/44687805

das ist ein Beispiel für eine unsinnige MP-Anwendung. Es ist schlicht eine simple Fläche. Eine MP-Relation mit einer einzigen Fläche, die eine outer-Rolle hat, ist für mich Humbug...
Ich würde Tags an die Outer-Linie setzen und die MP-Relation löschen...

Sven

Wolmatinger · 2013-08-12 14:57:28

streckenkundler wrote:

Hei,
Wolmatinger wrote:
BTW, weshalb ist dies ein MP? http://www.openstreetmap.org/browse/way/44687805
das ist ein Beispiel für eine unsinnige MP-Anwendung. Es ist schlicht eine simple Fläche. Eine MP-Relation mit einer einzigen Fläche, die eine outer-Rolle hat, ist für mich Humbug...
Ich würde Tags an die Outer-Linie setzen und die MP-Relation löschen...
Sven

Erledigt.

Wolmatinger · 2013-08-12 15:02:13

http://www.openstreetmap.org/browse/way/221522024

Sollte die riverbank nicht aus dem landuse (sprich: landuse aufteilen) raus?

fireball2 · 2013-08-13 12:57:57

Warum nicht, gerne. Dort wo ein Fluß ist, dort kann schließlich kein Wohngebiet sein. Und vielen Dank fürs drübergucken, sowie für die Korrektur des MPs. Leider wurden früher, wohl aufgrund der schlechten Sat-Bilder, die landuse-Flächen nur sehr grob eingezeichnet. Jetzt kann man diese aufgrund der besseren Auflösung natürlich wieder verfeinern, wieder viel Arbeit und schwieriger als als früher, wo man nur die neue Fläche "einmalen" mußte. Ich persönlich finde genaue Wege und Straßen wichtiger, als eine schöne bunte Karte mit wenigen "weißen" Flächen. Aber diese persönliche Ansicht kommt nunmal auf die Zielgruppe an.

Last edited by fireball2 (2013-08-13 12:58:24)

Wolmatinger · 2013-08-13 18:38:03

streckenkundler wrote:

Nein natürlich nicht! Deswegen schrieb ich ja auch unschön. Die Nichtbearbeitbarkeit eines MP's mit mehreren geschlossenen Outer ist etwas, was zumindestens im JOSM fehlt. Da JOSM mit seinem Funktionsumfang durchaus mit einem GIS-Programm wie Q-Gis, oder ArcGIs vergleichbar ist, ist das ein Feature, was schlichtweg fehlt.
Ich bin trotzdem der Meinung, daß mehrere geschlossene Outer in einem MP i.d.R. nicht nötig sind.

Wie willst Du dann mehrere Polygone, die zusammen gehören (nicht räumlich) darstellen? Laut Wiki auch dafür vorgesehen.
Z.B. Ortsteile sind durch größere Flächen (Wald, Wiesen, ...) getrennt.

Die site-Relation, mit der dies möglich wäre, ist nicht etabliert.

fireball2 · 2013-08-13 19:36:04

Ist es denn üblich mit mehreren landuse=residential Ortsteile darzustellen? Welchen Namen soll man denn dann diesen Konstrukten geben, den des Ortes? Den place-tag und die Grenzen gibt doch auch noch.

wambacher · 2013-08-13 20:29:28

fireball2 wrote:

Ist es denn üblich mit mehreren landuse=residential Ortsteile darzustellen? Welchen Namen soll man denn dann diesen Konstrukten geben, den des Ortes? Den place-tag und die Grenzen gibt doch auch noch.

ich gebe denen in der Regel keinen Namen. Nur ganz selten hat ein partielles Residential schon mal eine Bezeichnung z.B. "Blumensiedlung" oder "Obere Trift". Dann könnte man den Namen an das Residential tackern - aber nur wenn es wirklich exakt den Bereich abdeckt.

Gruss
walter

streckenkundler · 2013-08-13 20:53:19

Hei,

Wolmatinger wrote:

Wie willst Du dann mehrere Polygone, die zusammen gehören (nicht räumlich) darstellen? Laut Wiki auch dafür vorgesehen.

Hier unterscheide ich: einerseit der räumliche Zusammenhang der Flächen und andererseits der geometrische Zusammenhang.
Das type=multipolygon oder nicht, ist für mich zunächst eine reine geometrische Unterscheidung zwischen komplexen Polygonen mit mehreren Linien und einfachen Polygonen aus nur einer Linie. Mehr nicht. Das sagt nicht über einen räumlichen Zusammenhang in der Nähe liegender simpler oder komplexer Polygone aus. Das ist der Punkt, wo type=site ins Spiel kommt.

Wolmatinger wrote:

Z.B. Ortsteile sind durch größere Flächen (Wald, Wiesen, ...) getrennt.

das macht die Administrative Grenze bis hinunter zu admin_level=10. Erst es wenn es Siedlungsflecken gibt, die nicht durch einen eigenen Ortsteil abgegrenzt werden, muß man sich Gedanken machen. Vor dem Problem stehe ich hier im Spreewald.

Wolmatinger wrote:

Die site-Relation, mit der dies möglich wäre, ist nicht etabliert.

Nicht etabliert würde ich nicht sagen...
http://taginfo.openstreetmap.org/search?q=type%3Dsite
Mit type=site sollte man aber durchaus vorsichtig sein. Ich hab sie aber schon des öfteren angewendet: z.B. um alle baulichen Elemente einer Schleuse zusammenzufassen oder die Gebäudeteile des Lübbener Schlosses: http://www.openstreetmap.org/browse/relation/2598352

Sven

hurdygurdyman · 2013-08-16 11:36:44

Was sagt man denn zu so etwas?
http://www.openstreetmap.org/browse/relation/13333
Wird bei OSMI bemängelt. Nach simple features ist das auch kein MP (auch wenn die hier noch keinen offiziell interessieren).
Ist wohl der 2000-node-Grenze geschuldet.
Ich lass das mal zum bestaunen, werde dann aber die Trennlinie rausnehmen und die beiden outer als Teilwege in der Relation belassen.

streckenkundler · 2013-08-16 11:51:13

hurdygurdyman wrote:

Was sagt man denn zu so etwas?

- aufteilen an der Kreisstraße?
- abgrenzen nach Nadel- Misch und Laubwaldbereiche ...

Das macht das schon kleiner. Im südlichen Teil ist etwas, was wie Buschland aussieht...
Ich meine, man sieht recht deutlich einen Unterschied zwischen Nadel- und Laubwald.

Der Schattenwurf im südwestlichen Teil ist schlimm... Nicht einfach, auf die Schnelle was zu sagen...

Sven

wambacher · 2013-08-16 13:06:39

hurdygurdyman wrote:

...werde dann aber die Trennlinie rausnehmen und die beiden outer als Teilwege in der Relation belassen.

Bitte nicht! Mach lieber zwei getrennte MP (ohne s) raus, die dann per se einfacher sind.

Gruss
walter

Wolmatinger · 2013-08-16 13:53:40

wambacher wrote:

hurdygurdyman wrote:
...werde dann aber die Trennlinie rausnehmen und die beiden outer als Teilwege in der Relation belassen.
Bitte nicht! Mach lieber zwei getrennte MP (ohne s) raus, die dann per se einfacher sind.
Gruss
walter

+1

und die layer an den inner entfernen

Gruss

peb12345 · 2013-08-16 14:33:49

wambacher wrote:

hurdygurdyman wrote:
...werde dann aber die Trennlinie rausnehmen und die beiden outer als Teilwege in der Relation belassen.
Bitte nicht! Mach lieber zwei getrennte MP (ohne s) raus, die dann per se einfacher sind.
Gruss
walter

+1

MP mit mehreren outer linien sind in Mitteleuropa doch eher selten nötig.
Das Wiki lehnt das auch ab. Einfach mal nachlesen.

Announcement

#401 2013-08-09 15:05:06

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#402 2013-08-09 15:28:36

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#403 2013-08-09 16:21:44

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#404 2013-08-09 16:28:53

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#405 2013-08-09 18:40:57

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#406 2013-08-09 20:46:22

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#407 2013-08-11 15:20:28

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#408 2013-08-12 11:56:35

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#409 2013-08-12 12:21:07

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#410 2013-08-12 12:33:22

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#411 2013-08-12 12:45:36

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#412 2013-08-12 14:09:43

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#413 2013-08-12 14:16:17

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#414 2013-08-12 14:57:28

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#415 2013-08-12 15:02:13

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#416 2013-08-13 12:57:57

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#417 2013-08-13 18:38:03

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#418 2013-08-13 19:36:04

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#419 2013-08-13 20:29:28

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#420 2013-08-13 20:53:19

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#421 2013-08-16 11:36:44

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#422 2013-08-16 11:51:13

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#423 2013-08-16 13:06:39

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#424 2013-08-16 13:53:40

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#425 2013-08-16 14:33:49

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

Board footer