Multipolygonwahnsinn - oder: Durchblick war gestern!

aighes · 2012-11-06 00:18:48

Ich weiß nicht, wo du den Aufwand/die Komplexität siehst. Wenn ich ein MP hab und ein Teil der Kontur soll zu einer Hecke werden, dann markiere ich Startpunkt und Endpunkt (wenn diese Teil eines Weges sind) und drücke p (Weg auftrennen) oder ich trenne erst den Startpunktweg auf und dann den Endpunktweg. Dann markiere ich alle Wege, die nun Hecke werden sollen und füge ein barrier=hedge an. Fertig. Dürfte sogar schneller gehen, als die Geometrie nach zu zeichnen.

Das von kartler175 angesprochene Problem, ist aber ein anderes. Nämlich, dass man Objekte übereinander legt, die nichts miteinander zu tun haben. Da ist es dann aber egal, ob man einen Weg hat und mehrere Relationen oder viele Wege übereinander. In beiden Fällen bewege ich alle Objekte, die den Node nutzen, den ich verschiebe.

MasiMaster · 2012-11-06 00:44:38

aighes wrote:

Die Probleme sind:
in Kombination mit Straßen/Wegen die auf der Straßenmitte als Linie erfasst sind, dass man das Feld, die Wiese oder was auch immer größer macht, als sie in Wirklichkeit ist.

Das hat meines Erachtens nicht mit MP zu tun, sondern mit der Ansicht, ob man die Wiesen an die Straßen dranpappen will oder nicht. Ist zwar ein großer Streitpunkt, hat aber auf die Frage nach einer Verbesserung der Editoren keine Auswirkung.

mach mal eine Mehrfachauswahl mit Objekten, die jeweils mit anderen Objekten zusammen liegen. Da macht es keinen Spaß, nach jedem Objekt, das man der Auswahl hinzufügt auch noch auswählen zu müssen, welches der x Elemente man gerne hätte.

Ja, es macht wirklich keinen Spaß! Wenn ich eine Mehrfachauswahl machen möchte, ist das in (fast) allen Fällen immer die Straße, zumindest bei dem, was ich kartiere.
mMn könnte die Straße (Linie mit dem highway-Tag) als erstes ausgewählt werden, automatisch vom Editor vorgegeben. Weiß jetzt grad keine anderen Fälle, bei denen ich sonst noch Mehrfachauswahl nutze... Vielleicht manchmal Flächen, dies kann ich aber nur, wenn sie nicht als "Wahnsinns-Multipolygon" existieren.

unzählige Fehler, wo eine einmündende Straße an der Fläche endet und nicht mit der Straße verbunden ist.

Sorry, hab keine Vorstellung was du meinst, hast du ein Beispiel?

eine deutlich erhöhte Datenmenge. Je mehr Nodes die doppelt erfasste Geometrie hat, desto mehr spart man.

Zustimmung: Ja, bei größeren Geometrien gibt es eine höhere Datenmenge. Bei sehr kleinen das Gegenteil. Mehr Knoten werden übrigens nicht gebraucht, sie sind "nur" Element in mehreren Objekten.
(Dieser letzte Abschnitt ist sicher wichtig bei dem Konzept zur Verwendung von MP, hat aber wenig mit Verbesserungen in den Editoren zu tun)
Im Gegensatz zur Datenmenge werfe ich mal das Argument ein: Geometrien, bestehend aus Einzellinien in einer Multipolygon-Relation zusammengefasst, verbrauchen ein Vielfaches an Rechenpower als eine simple Fläche als geschlossene Linie.

MasiMaster · 2012-11-06 01:10:13

aighes wrote:

Ich weiß nicht, wo du den Aufwand/die Komplexität siehst. Wenn ich ein MP hab und ein Teil der Kontur soll zu einer Hecke werden, dann markiere ich Startpunkt und Endpunkt (wenn diese Teil eines Weges sind) und drücke p (Weg auftrennen) oder ich trenne erst den Startpunktweg auf und dann den Endpunktweg. Dann markiere ich alle Wege, die nun Hecke werden sollen und füge ein barrier=hedge an. Fertig. Dürfte sogar schneller gehen, als die Geometrie nach zu zeichnen.

Sorry, hab mich vielleicht falsch ausgedrückt. Ich meinte eine breite Hecke, so eine Unterholz-Straßensäumung, also als Fläche anstatt als Linie zu Zeichnen.
http://tools.geofabrik.de/mc/?mt0=googl … 81&zoom=18
(bitte keine Disskussion, ob für den Streifen landuse=forest richtig ist oder nicht!)

aighes · 2012-11-06 12:34:16

MasiMaster wrote:

mach mal eine Mehrfachauswahl mit Objekten, die jeweils mit anderen Objekten zusammen liegen. Da macht es keinen Spaß, nach jedem Objekt, das man der Auswahl hinzufügt auch noch auswählen zu müssen, welches der x Elemente man gerne hätte.
Ja, es macht wirklich keinen Spaß! Wenn ich eine Mehrfachauswahl machen möchte, ist das in (fast) allen Fällen immer die Straße, zumindest bei dem, was ich kartiere.
mMn könnte die Straße (Linie mit dem highway-Tag) als erstes ausgewählt werden, automatisch vom Editor vorgegeben. Weiß jetzt grad keine anderen Fälle, bei denen ich sonst noch Mehrfachauswahl nutze... Vielleicht manchmal Flächen, dies kann ich aber nur, wenn sie nicht als "Wahnsinns-Multipolygon" existieren.

Trifft für dich evtl. zu, für andere evtl. eher nicht. Wenn ich Radrouten eintrage, interessieren mich die Wege, dito beim Ausbügeln von Routingfehlern. Wenn ich Grenzen bearbeiten will, dann hätte ich aber gerne den Grenz-Way usw.

MasiMaster wrote:

unzählige Fehler, wo eine einmündende Straße an der Fläche endet und nicht mit der Straße verbunden ist.
Sorry, hab keine Vorstellung was du meinst, hast du ein Beispiel?

Das sind die Fehler, die josm anmekert mit Weg endet an Fläche. Stell dir vor eine Straße liegt auf dem Rand einer Wiese. Zwischen zwei Straßennodes hat die Weise aber noch einen weiteren Node, an dem eine andere Straße einmündet. Das tückisch an dem Fehler ist, dass man ihn nur sehr schwer sieht. josm zeigt ein großen Knotenquadrat an, da ja alle Wege mit einem anderen Weg verbunden sind. Nur ist es in dem Fall dummerweise der falsche. Wäre dort nur ein Way, wäre die einmündende Straße entweder verbunden oder eben nicht verbunden. Wie man den Fehler reproduzieren kann, kann ich dir jedoch nicht sagen. Ich hab den Fehler bisher nur ausgebügelt.

MasiMaster wrote:

eine deutlich erhöhte Datenmenge. Je mehr Nodes die doppelt erfasste Geometrie hat, desto mehr spart man.
Zustimmung: Ja, bei größeren Geometrien gibt es eine höhere Datenmenge. Bei sehr kleinen das Gegenteil. Mehr Knoten werden übrigens nicht gebraucht, sie sind "nur" Element in mehreren Objekten.

Gehen wir von einem simplen Quadrat aus ( 4 Nodes ) und je zwei Ways übereinander aus. Also ein Feld mit Feldwegen drumherum zum Beispiel.
Zu jedem Way wird gespeichert, welche Nodes er beinhaltet. Macht in den Daten 5 Wege und 12 Node-Verweise. Macht insgesamt 9 Objekte und 12 Verweise in der DB. Beim MP hat man 4 Wege, eine Relation und 4 Knoten. Macht ebenfalls 9 Objekte in der DB. Dazu kommen 8 Verweise von den Wegen auf die Knoten und 4 Verweise von der Relation auf die Wege. Also selbst im simpelsten Fall verbraucht ein MP nicht mehr Platz. Je mehr Nodes du einfügst und je mehr Wege über einander liegen, desto besser wird das MP.

Bei der Auswahl der MP-Fläche macht josm aber keinen Unterschied. Die bekommst du auch über Alt+Klick bzw. Mittlere Maustaste angezeigt. Ob das nun also ei komplexes MP ist oder ein Polygon ist für das Auswählen unerheblich.

MasiMaster wrote:

Im Gegensatz zur Datenmenge werfe ich mal das Argument ein: Geometrien, bestehend aus Einzellinien in einer Multipolygon-Relation zusammengefasst, verbrauchen ein Vielfaches an Rechenpower als eine simple Fläche als geschlossene Linie.

Bedingt, da MP's ohnehin aufgelöst werden müssen.

Taunide · 2012-11-06 13:27:37

Eine Frage ist auch, wo man landuse-MP'e enden lässt.

Hier gibt es Waldgebiete, die eigentlich erst nach dutzenden KM enden, die an einer Stelle ganz schmal und plötzlich wieder breit werden, wo es eigentlich keinen logischen Zusammenhang gibt, weil die niemand als zusammenhängenden Wald ansieht. Aus meiner Sicht macht es da Sinn, Waldpolygone zu trennen.

Andererseits gibt es auch ziemlich sinnfreie Auftrennungen zusammengehöriger Wald-MP'e, bloss weil da vielleicht ein kleines gewundenes Sträßchen durchführt (sepatate Outer-Grenzenlinien mit jeweils 100 nodes), oder weil jemand fand, dieses oder jenes MP sei jetzt langsam "zu groß"... Und dann passieren sehr leicht Fehler, weil man neue "inner"-Elemente versehentlich in das falsche outer steckt, besonders wenn das eine MP 22985395 und das andere 22983569 heisst, und in der Auswahlliste noch 200 andere MP'e mit ähnlichen Nummern sind.

Meine ganz speziellen Freunde sind aber die kombinierten "outer" Grenzen farmland/Forest, farm/meadow, farmland/residential, residential/cemetry, und was da an Kombinationen mehr sind. Die sind fix dahingetagged, aber wehe es ist ein Fehler drin, den sucht man tagelang. Und die dahinter stehende Struktur ist nie wieder änderbar. Aber die kommt mit den wenigsten getaggten nodes aus und erweckt den Anschein großer "Effizienz"...

mdk · 2012-11-06 14:55:03

MasiMaster wrote:

unzählige Fehler, wo eine einmündende Straße an der Fläche endet und nicht mit der Straße verbunden ist.
Sorry, hab keine Vorstellung was du meinst, hast du ein Beispiel?

Nach 5min Suche:
http://www.openstreetmap.org/browse/node/1619229256
Man muss schon mit einem Editor seeeehr nahe ranzoomen. Der von Süden kommende Track endet nicht am diagonal verlaufenden Track, sonden am 30cm entfernten landuse.

aighes · 2012-11-06 14:57:35

MP-Relation auswählen, die ist nun lila hervorgehoben. Strg gedrückt halten und alles auswählen, was in das MP mit rein soll. Relationseditor öffnen alles übernehmen und WICHTIG die Relation wieder entfernen.

Oder gleich über das PlugIn Relationswerkzeuge. Wenn du da ein MP ausgewählt hast, wird das gelb umrandet. Dann wählst du ein Element aus, dass hinzugefügt werden soll und drückst den +Knopf.

Durch die Hervorhebung siehst du in beiden Fällen, wenn du das MP verlassen solltest.

Radeln · 2012-11-06 16:35:01

aighes wrote:

MP-Relation auswählen, die ist nun lila hervorgehoben. Strg gedrückt halten und alles auswählen, was in das MP mit rein soll. Relationseditor öffnen alles übernehmen und WICHTIG die Relation wieder entfernen.

Letzteres ist mit JOSM nicht nötig, da circulärer Verweis, oder?

aighes · 2012-11-06 17:01:54

Tatsache, das macht josm mittlerweile sogar automatisch.

chris66 · 2012-11-06 17:12:01

Aber nur ein-stufig.
Rel A enthält Rel B als Member und Rel B hat Rel A als Mitglied wird nicht bemängelt.

Radeln · 2012-11-06 17:32:27

chris66 wrote:

Aber nur ein-stufig.
Rel A enthält Rel B als Member und Rel B hat Rel A als Mitglied wird nicht bemängelt.

Ist eine MP-Relation in einer selbigen überhaupt erlaubt?

chris66 · 2012-11-06 17:43:24

Bei MPs ist dies zumindest unüblich. Verboten ist in OSM ja leider nichts.

Für zirkuläre Relationen wüsste ich momentan keinen sinnvollen Anwendungsfall.

Last edited by chris66 (2012-11-06 18:05:00)

aighes · 2012-11-06 18:00:38

Erlaubt (meint spezifiziert) sind Relationen in Relationen bei Routen als sogenannte Superrelationen und in boundary-relationen als subarea. Wahrscheinlich auch in collections, aber das ist ein anderer Punkt.

MasiMaster · 2012-11-06 22:24:12

aighes wrote:

MasiMaster wrote:
aighes wrote:
unzählige Fehler, wo eine einmündende Straße an der Fläche endet und nicht mit der Straße verbunden ist.
Sorry, hab keine Vorstellung was du meinst, hast du ein Beispiel?
Das sind die Fehler, die josm anmekert mit Weg endet an Fläche. Stell dir vor eine Straße liegt auf dem Rand einer Wiese. Zwischen zwei Straßennodes hat die Weise aber noch einen weiteren Node, an dem eine andere Straße einmündet. Das tückisch an dem Fehler ist, dass man ihn nur sehr schwer sieht. josm zeigt ein großen Knotenquadrat an, da ja alle Wege mit einem anderen Weg verbunden sind. Nur ist es in dem Fall dummerweise der falsche. Wäre dort nur ein Way, wäre die einmündende Straße entweder verbunden oder eben nicht verbunden. Wie man den Fehler reproduzieren kann, kann ich dir jedoch nicht sagen. Ich hab den Fehler bisher nur ausgebügelt.

Ok, das passiert möglicherweise wenn man eine neue Linie (auf den gleichen Knoten) nicht mit "verfolgen" malt, oder es hat mit dem Autofang zu tun, wenns mal ruckelt.

aighes wrote:

MasiMaster wrote:
Im Gegensatz zur Datenmenge werfe ich mal das Argument ein: Geometrien, bestehend aus Einzellinien in einer Multipolygon-Relation zusammengefasst, verbrauchen ein Vielfaches an Rechenpower als eine simple Fläche als geschlossene Linie.
Bedingt, da MP's ohnehin aufgelöst werden müssen.

Genau dieses (wahrscheinlich rechenintensive) Auflösen könnte man bei vielen Multipolygonen sparen.

aighes · 2012-11-06 22:42:46

Mit bedingt meinte ich, dass die Berechnung des Polygons aus mehreren Wegen und die Berechnung eines Polygons aus einem Weg sich nicht groß unterscheidet. Der Mehraufwand liegt primär im Parsen der Datei. Dieser Aufwand ist aber immer da, wenn man Multipolygone auswerten will.

MasiMaster · 2012-11-07 15:35:53

aighes wrote:

Mit bedingt meinte ich, dass die Berechnung des Polygons aus mehreren Wegen und die Berechnung eines Polygons aus einem Weg sich nicht groß unterscheidet. Der Mehraufwand liegt primär im Parsen der Datei. Dieser Aufwand ist aber immer da, wenn man Multipolygone auswerten will.

Ja, ich sprach aber von simplen Flächen als geschlossene Linie, ohne innenliegende Flächen, also ohne Multipolygon. Die werden von manchen Mappern als zerstückeltes MP gemappt.

Man kann übrigens auch einen Wald auf einer großen Wiese ohne Multipolygon realisieren. 2 Wiesenstücke + 1x Wald. Es heißt ja nur Landnutzung und nicht Grundstück, also kann man auch mittendrin unterteilen.
Geht allerdings nicht, wenn die ganze Wiese einen Namen hat.

Radeln · 2012-11-07 17:20:59

MasiMaster wrote:

Ja, ich sprach aber von simplen Flächen als geschlossene Linie, ohne innenliegende Flächen, also ohne Multipolygon. Die werden von manchen Mappern als zerstückeltes MP gemappt.

Und dann noch mit *way als Grenzen.

aighes · 2012-11-07 17:47:05

Die Menge der MP's und wie die beschaffen sind ist nahezu egal. Das was Zeit kostet ist das Einlesen der Daten. Zuerst muss man Relationen lesen, dann die Ways und dann die Nodes. Das muss man aber immer machen, wenn man MP's überhaupt auswerten möchte.

morjak · 2012-11-07 18:16:05

Radeln wrote:

MasiMaster wrote:
Ja, ich sprach aber von simplen Flächen als geschlossene Linie, ohne innenliegende Flächen, also ohne Multipolygon. Die werden von manchen Mappern als zerstückeltes MP gemappt.
Und dann noch mit *way als Grenzen.

Und das ist auch gut so. Die Leute, die sich am meisten gegen Multipolygone mit aus mehreren Wegen bestehenden Ringen wehren, verlieren erfahrungsgemäß dann auch als erste den Überblick, weil 3 oder mehr Linien übereinander liegen. Da werden dann z.B. Flächen und Straßen, mitunter vom gleichen Mapper, mehrfach eingetragen, weil man nicht sieht, dass sie schon da sind oder es gibt Konstruktionen, die schon vom Hingucken weh tun und geometrisch völlig paradox sind.
Außerdem sucht man Fehler, die OSMI anmeckert meistens vergebens, weil sie überall stecken können.

Meine Lösung sind kleine Multipolygone die alles nutzen, was eh schon da ist. Damit bleibt es übersichtlich und einfach zu warten.

Radeln · 2012-11-07 19:31:17

morjak wrote:

Radeln wrote:
MasiMaster wrote:
Ja, ich sprach aber von simplen Flächen als geschlossene Linie, ohne innenliegende Flächen, also ohne Multipolygon. Die werden von manchen Mappern als zerstückeltes MP gemappt.
Und dann noch mit *way als Grenzen.
Und das ist auch gut so. Die Leute, die sich am meisten gegen Multipolygone mit aus mehreren Wegen bestehenden Ringen wehren, verlieren erfahrungsgemäß dann auch als erste den Überblick, weil 3 oder mehr Linien übereinander liegen. Da werden dann z.B. Flächen und Straßen, mitunter vom gleichen Mapper, mehrfach eingetragen, weil man nicht sieht, dass sie schon da sind oder es gibt Konstruktionen, die schon vom Hingucken weh tun und geometrisch völlig paradox sind.
Außerdem sucht man Fehler, die OSMI anmeckert meistens vergebens, weil sie überall stecken können.
Meine Lösung sind kleine Multipolygone die alles nutzen, was eh schon da ist. Damit bleibt es übersichtlich und einfach zu warten.

Übersichtlich und einfach zu warten, da habe ich andere Erfahrungen gemacht.
Deine Argumente sind erschlagend.

morjak · 2012-11-07 20:16:03

Radeln wrote:

Übersichtlich und einfach zu warten, da habe ich andere Erfahrungen gemacht.

Für jemanden, der sich mal 10 Minuten Zeit nimmt, die entsprechenden Seiten im Wiki zu lesen, ist es einfacher.
Aber leider fehlt es den Meisten am Willen, sich einzuarbeiten. Es wird irgendwas in die Datenbank eingetragen, Hauptsache Mapnik ist schön bunt.

buedner · 2012-11-07 20:33:44

Der größte Vorteil dieser Dinger ist, dass man sie weitgehend ignorieren kann, wenn man sich nicht mit Flächen beschäftigen will.
Wenn die Anzahl der Mitglieder nicht zu groß ist, sind sie auch recht gut editierbar.

Ein Gebiet, in dem Flächen auf diese Art dargestellt werden, ist für mich wesentlich angenehmer zu bearbeiten, als die gigantischen Monstergebilde aus kaum noch vernünftig zu trennenden Flächenpolygonen und Wegen.

Gruß
Jens

Pfad-Finder · 2012-11-07 22:25:40

morjak wrote:

Die Leute, die sich am meisten gegen Multipolygone mit aus mehreren Wegen bestehenden Ringen wehren, verlieren erfahrungsgemäß dann auch als erste den Überblick, weil 3 oder mehr Linien übereinander liegen. Da werden dann z.B. Flächen und Straßen, mitunter vom gleichen Mapper, mehrfach eingetragen, weil man nicht sieht, dass sie schon da sind oder es gibt Konstruktionen, die schon vom Hingucken weh tun und geometrisch völlig paradox sind.
Außerdem sucht man Fehler, die OSMI anmeckert meistens vergebens, weil sie überall stecken können.
Meine Lösung sind kleine Multipolygone die alles nutzen, was eh schon da ist. Damit bleibt es übersichtlich und einfach zu warten.

Für den Profi ja. Für den Gelegenheitsmapper, der nur mal schnell die Qualität eines Feldwegs ändern will, ist es eine elende Fummelei. Und ohne die Gelegenheitsmapper ist die Aktualität nicht zu halten geschweige denn flächendeckend eine brauchbare Qualität zu erreichen.

morjak wrote:

Aber leider fehlt es den Meisten am Willen, sich einzuarbeiten.

Die Grundsatzfrage, die sich hier doch immer wieder stellt, laut: Ist OSM ein Projekt von Spezialisten? Dann wären komplizierte MP-Konstruktionen ok. Oder ist es ein Schwarmintelligenz-Projekt, das inhaltlichen Input von "Laien" wirklich willkommen heißt und ihnen sowenig technische Hürden wie möglich bereitet?

Übrigens bezog sich meine Anspielung mit der Königsbrücker Heide weiter oben genau auf diesen User.

aighes · 2012-11-07 22:34:00

Pfad-Finder wrote:

Für den Profi ja. Für den Gelegenheitsmapper, der nur mal schnell die Qualität eines Feldwegs ändern will, ist es eine elende Fummelei. Und ohne die Gelegenheitsmapper ist die Aktualität nicht zu halten geschweige denn flächendeckend eine brauchbare Qualität zu erreichen.

Ne, genau für den wird es einfacher, weil er einen Weg hat, den er verschieben muss. Wenn du zwei Flächen und einen Weg übereinander hast, dann muss der Gelegenheitsmapper erstmal wissen, wie er zu dem Objekt kommt, dass er bearbeiten will oder gar erstmal wissen, dass da ein Objekt ist, dass er bearbeiten sollte und nicht einfach ein neues einzeichnet.

Radeln · 2012-11-07 22:42:46

aighes wrote:

Pfad-Finder wrote:
Für den Profi ja. Für den Gelegenheitsmapper, der nur mal schnell die Qualität eines Feldwegs ändern will, ist es eine elende Fummelei. Und ohne die Gelegenheitsmapper ist die Aktualität nicht zu halten geschweige denn flächendeckend eine brauchbare Qualität zu erreichen.
Ne, genau für den wird es einfacher, weil er einen Weg hat, den er verschieben muss. Wenn du zwei Flächen und einen Weg übereinander hast, dann muss der Gelegenheitsmapper erstmal wissen, wie er zu dem Objekt kommt, dass er bearbeiten will oder gar erstmal wissen, dass da ein Objekt ist, dass er bearbeiten sollte und nicht einfach ein neues einzeichnet.

+1

Announcement

#226 2012-11-06 00:18:48

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#227 2012-11-06 00:44:38

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#228 2012-11-06 01:10:13

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#229 2012-11-06 12:34:16

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#230 2012-11-06 13:27:37

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#231 2012-11-06 14:55:03

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#232 2012-11-06 14:57:35

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#233 2012-11-06 16:35:01

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#234 2012-11-06 17:01:54

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#235 2012-11-06 17:12:01

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#236 2012-11-06 17:32:27

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#237 2012-11-06 17:43:24

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#238 2012-11-06 18:00:38

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#239 2012-11-06 22:24:12

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#240 2012-11-06 22:42:46

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#241 2012-11-07 15:35:53

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#242 2012-11-07 17:20:59

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#243 2012-11-07 17:47:05

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#244 2012-11-07 18:16:05

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#245 2012-11-07 19:31:17

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#246 2012-11-07 20:16:03

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#247 2012-11-07 20:33:44

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#248 2012-11-07 22:25:40

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#249 2012-11-07 22:34:00

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#250 2012-11-07 22:42:46

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

Board footer