Multipolygonwahnsinn - oder: Durchblick war gestern!

reneman · 2012-12-23 15:00:35

Hab die Rel. mit inner hinzugefügt. Sollte also demnächst korrekt angezeigt werden.
(Nimm die Relation mit der selben ID )

Last edited by reneman (2012-12-23 15:01:39)

FvGordon · 2012-12-23 15:10:09

trelgne wrote:

Hier mal wieder so ein Problem mit ausgestanzten Wiesenflächen innerhalb des Spessarts. OSM org zeigt alle vier Flächen korrekt, in der Wanderreitkarte wird nur eine davon angezeigt. Diese zeigt in Potlatch unter Relation auch "Multipolygon Spessart". Muss ich jetzt zum korrekten Erfassen der fehlenden drei Flächen dieselbe Relation suchen und eintragen? Woher weiß ich in Potlatch, welche der angebotenen Relationen mit dem Namen "multipolygon..." überhaupt die richtige ist?
http://www.wanderreitkarte.de/index.php … 70&zoom=16
http://www.openstreetmap.org/?lat=50.04 … 6&layers=M

Hallo trelgne,

wenn Du eine Landfläche zu einer Relation hinzufügen möchtest, kannst Du sie anklicken und unten links bei Relation auf "Add to" klicken. Dann kommt eine Auswahl an Relationen, aus der Du hier die Relation "2743: multipolygon Spessart" auswählen kannst (die selbe Nummer steht auch an der Landfläche, die in der Wanderreitkarte richtig angezeigt wird - mit der Position in der Relation hinter der Nummer (2743/8)). Dann noch links im Relations-Bereich als Rolle "inner" hinzufügen - fertig (für diese Wiese). Es gibt Richtung Süd-Osten noch viele weitere kleine Wiesen, die nur in Mapnik zu sehen sind - die wohl alle per inner-Rolle noch nicht ausgestanzt sind.

Helfende Weihnachtsgrüße,
Franz

GeorgFausB · 2012-12-23 16:34:20

Moin,

FvGordon wrote:

trelgne wrote:
Hier mal wieder so ein Problem mit ausgestanzten Wiesenflächen innerhalb des Spessarts.
wenn Du eine Landfläche zu einer Relation hinzufügen möchtest, kannst Du sie anklicken und unten links bei Relation auf "Add to" klicken. Dann kommt eine Auswahl an Relationen, aus der Du hier die Relation "2743: multipolygon Spessart" auswählen kannst (die selbe Nummer steht auch an der Landfläche, die in der Wanderreitkarte richtig angezeigt wird - mit der Position in der Relation hinter der Nummer (2743/8)). Dann noch links im Relations-Bereich als Rolle "inner" hinzufügen - fertig (für diese Wiese). Es gibt Richtung Süd-Osten noch viele weitere kleine Wiesen, die nur in Mapnik zu sehen sind - die wohl alle per inner-Rolle noch nicht ausgestanzt sind.

wen wunderts - gehört die Wiese denn nicht zum Spessart?
Ist der Spessart tatsächlich nur der Laubwald?

Gruß
Georg

der im Geographie-Unterricht den Spessart immer noch als Mittelgebirge oder geografische Region gelernt hat -
und dem es ob solcher Tagging-Methoden immer furchtbar graust ...

trelgne · 2012-12-23 17:25:31

Danke für die Hilfe. Wie soll ich vorgehen, wenn ich das nächste Mal irgendwo eine Fläche ausstanze? Unter Relationen werden verschiedene Multipolygone angezeigt; woher soll ich wissen, welche die richtige ist, wenn grad mal keine andere Wiese in der Nähe ist, deren ID ich übernehmen kann? Woher soll ich wissen, dass überhaupt eine Multipolygon-Relation vonnöten ist?

reneman · 2012-12-23 18:02:30

Wenn da wo du taggst, schon irgend etwas gerendert wird, dann muss da zwangsläufig eine größere Fläsche vorhanden sein. Wenn ich innerhalb dieser ein landuse tagge, dann sollte man schon mal einen Blick auf das größere Element drum herum werfen, deren Attribute geben dann genug Hinweise

Last edited by reneman (2012-12-23 18:03:00)

Ebbe73 · 2012-12-23 23:07:16

Hallo zusammen,

GeorgFausB wrote:

wen wunderts - gehört die Wiese denn nicht zum Spessart?
Ist der Spessart tatsächlich nur der Laubwald?

primär drückt das Multipolygon aus, dass dort Wiese und kein Wald ist. Um so etwas abzubilden, wurden Multipolygone geschaffen.

Die Bezeichnung mit Spessart ist dagegen nur ein zweitrangiger "Bonus".

GeorgFausB wrote:

und dem es ob solcher Tagging-Methoden immer furchtbar graust ...

Dementsprechend: mir graust es immer furchtbar, wenn in Multipolygone weitergehende Abhängigkeiten hinein interpretiert werden.

Augustus Kling · 2012-12-24 00:18:06

Ein Multipolygon drückt aus welche Wege Flächengrenzen sind (äußere und innere) und welche Flächen zum selben Objekt gehören. Ob irgendwo Wald ist oder wo der Name Spessart gilt, ist dafür gleich wichtig. Ein Mulipolygon beschreibt einfach auf welcher Fläche alle Tags der Relation gelten.

Georg wird darauf anspielen, dass die Wiese vom Spessart ausgenommen ist obwohl nur beabsichtigt war sie vom Wald auszunehmen. Es bräuchte hier 2 Multipolygone. Eins beschreibt den Wald und ist das gleiche wie Relation 2743 nur ohne Namen. Das zweite Multipolygon hat eventuell¹ die selben Wege in der Rolle outer, keine² Elemente der Rolle inner und trägt den Namen Spessart.

Mapnik zeichnet Mulipolygone wie JOSM in fast allen Fällen korrekt.

¹ Falls der Spessart durch den Waldrand begrenzt sein soll.
² Weil alles innerhalb des Waldes Teil des Spessart ist.

Ebbe73 · 2012-12-24 01:43:11

Augustus Kling wrote:

Georg wird darauf anspielen, dass die Wiese vom Spessart ausgenommen ist obwohl nur beabsichtigt war sie vom Wald auszunehmen.

Ja, das ist schon klar. Das Problem kenne ich leider auch seit langem vom Harz zu genüge. Solange es kein weiträumig akzeptiertes Tagging-Schema für Regionen, Mittelgebirge, etc. gibt, halte ich diese "Ungenauigkeit" aber für akzeptabel. Es ist immer noch besser, die Mittelgebirgsbezeichnung erst mal "unzureichend" nur am Wald anzugeben als damit solange zu warten, bis sich ein Tagging-"Standard" für Regionen entwickelt hat.

Augustus Kling wrote:

Es bräuchte hier 2 Multipolygone.

Darauf wird es dann wohl irgendwann hinauslaufen. Erst dann lassen sich Regionen sinnvoll abgrenzen - und sollten dann auch vom Wald- und Wiesen-Tagging getrennt erfasst werden.

christiank61 · 2013-01-17 18:31:23

Nop wrote:

Ich dachte früher immer, OSM hätte die Mission
- als offenes Projekt möglichst viele Leute in aller Welt als Mapper zu gewinnen
- einen Geodatenbank für Jedermann bereitzustellen
Mit solchen exzessiven Multipolygonkonstrukten wird beides unmöglich gemacht.

Hallo,

Der Thread ist zwar schon etwas älter und eigentlich wurde das Thema schon ausführlich behandelt,
Jedoch:

Ich bin mittlerweile auch ziemlich frustriert das manche Länder nur mit Rechnern gerendert werden können die von den Kosten her für einen Privaten kaum leistbar sind - wegen der MP's die unglaublich Rechenzeit verschlingen - von den Kartenrandproblemen mal abgesehen.
Das die Mälaren Stunden an Rechenzeit verschlingen obwohl sie problemlos aufzuteilen wären und teilweise "outers" aufweisen die in keinster Weise nötig - weil gar nicht mit den Hauptwasserflächen verbunden sind ist lästig, aber bei rund 1000 Members noch machbar.
Qubec geht fast nicht auf einem halbwegs normalen Rechner.
Japan überhaupt nicht - Frederik Ramm hat schon mal versucht mit den Japanern ins Einvernehmen zu kommen - scheinbar ohne Erfolg siehe http://lists.openstreetmap.org/pipermai … 05391.html

Ich stimme NOP völlig zu das diese Entwicklung die "normalen" Mitstreiter in der OSM an den Rand drängt, wer hat schon locker +2000Euro für einen Zweitrechner zum Rendern dieser Monster übrig.
Es ist zwar richtig das die Mapper nicht ausschliesslich für die Renderer arbeiten sollen, nur führt die derzeitige Entwicklung in die Richtung in der nur mehr kommerzielles Rendern Sinn macht - ob das die Grundintention von OSM war/ist bezweifle ich.

jm2c
Christian aus der Wachau

Weide · 2013-01-18 08:27:20

Hi Christian,

jetzt verstehe ich das Problem hinter Deiner Mail besser.

wer hat schon locker +2000Euro für einen Zweitrechner zum Rendern dieser Monster übrig.

Nachvollziehen kann ich das nicht. Ich habe einen Rechner von 2010, der damals nicht etwa über 2000€ sondern unter 500€ gekostet hat. Für meinen Schwedenurlaub im letzten Jahr habe ich damit Schwedenkarten erzeugt und hatte keine Probleme. Das ist auch kein Zweitrechner, sondern der Rechner auf dem ich gleichzeitig arbeite.

Das die Mälaren Stunden an Rechenzeit verschlingen obwohl sie problemlos aufzuteilen wären und teilweise "outers" aufweisen die in keinster Weise nötig - weil gar nicht mit den Hauptwasserflächen verbunden sind ist lästig, aber bei rund 1000 Members noch machbar.

Das Hauptargument für das "Zusammenlassen" ist, dass es nicht "die Mälaren" sondern "der Mälarsee" ist ... es ist nunmal ein See namens Mälaren.
Ich sehe da auch nur zwei voneinander getrennte nennenswert große Stücke und die sind einfach falsch gemappt. Da führt eine Brücke über den Mälar und die wurde nicht als Brücke getaggt, sondern der See wurde statt dessen auf beiden Seiten beendet.

Der Vollständigkeit halber sei noch ein weiteres outer-Stück erwähnt, dass aber keine nennenwerte Größe hat. Da bin ich mir nicht sicher, ob es überhaupt zum Mälar gehört. Aber es rauszuwerfen kann das Problem eigentlich nicht ändern.

Japan überhaupt nicht - Frederik Ramm hat schon mal versucht mit den Japanern ins Einvernehmen zu kommen - scheinbar ohne Erfolg siehe http://lists.openstreetmap.org/pipermai … 05391.html

Das sieht nach einem ganz anderen Problem aus. Da werden augenscheinlich (zumindest auf den ersten Blick) sinnlos gleichartige Flächen zu einem MP zusammengefasst. Sowas habe ich schon öfter -- besonders bei Wäldern -- gesehen und ist meines Erachtens Unfug.

MfG
Weide

christiank61 · 2013-01-18 08:53:58

Weide wrote:

Hi Christian,
jetzt verstehe ich das Problem hinter Deiner Mail besser.
wer hat schon locker +2000Euro für einen Zweitrechner zum Rendern dieser Monster übrig.
Nachvollziehen kann ich das nicht. Ich habe einen Rechner von 2010, der damals nicht etwa über 2000€ sondern unter 500€ gekostet hat. Für meinen Schwedenurlaub im letzten Jahr habe ich damit Schwedenkarten erzeugt und hatte keine Probleme. Das ist auch kein Zweitrechner, sondern der Rechner auf dem ich gleichzeitig arbeite.

Hallo Weide,

Das Problem ist das ich meine Karten als Vectorkarten für Mapsforge (Android) rendere und hier brauchen alleine die Mälaren (nur diese Relation für sich) satte 4h zum Rendern. Mapsforge reagiert allergisch auf grosse MPs. Und da gibt es innerhalb der Mälaren die Insel Lovon (Lovön??) die auf allen Mapsforge Karten im See versinkt, ich möchte das gerne bereinigen.
Die grossen MPS in Quebec gehen gar nicht, Japan habe ich nach sage und schreibe 14 tagen Rechenzeit abgebrochen und ab und zu muss ich meinen T410 (mit Samsung SSD - also gar nicht sooo langsam) auch aus dem Dock nehmen und zu einem Kunden fahren - das wars dann...

Nun kann man natürlich sagen das dieses Problem mit Mapsforge unter Einzelschicksal fällt ;-) nur ist - glaube ich - Android ein sehr gutes Vehikel um OSM zur weiteren Verbreitung zu verhelfen.

Ich versuche auch kleinen Fehler in MP's auf die Schliche zu kommen und zu Bereinigen, nur wenn ich - auf Grund der Renderzeiten - dazu keine Vernünftige Basis habe ist das Öde...

Aber was solls, die OSM Datenbasis ist insgesamt wirklich einzigartig und ich hoffe das dieser Thread ev. doch dazu führt das keine MonsterMP's mehr entstehen - Wünschen kann mann sich's ja

LG
Christian
www.openandromaps.org

Last edited by christiank61 (2013-01-18 10:08:22)

geri-oc · 2013-01-18 10:51:50

Aber was solls, die OSM Datenbasis ist insgesamt wirklich einzigartig und ich hoffe das dieser Thread ev. doch dazu führt das keine MonsterMP's mehr entstehen - Wünschen kann mann sich's ja wink
LG
Christian

Ich möchte christiank61 voll zustimmen. Ganz so grasse Probleme habe ich zwar nicht.

ABER: Ein MP mit über den gesamten Forst des Osterzgebirges als ein einziges outer ist mit dem jetzigen genauen mappen nicht mehr editierbar. Es war von früher, um schnell Flächen zu erstellen sicher angebracht. Man sollte aber dazu übergehen, gerade den Forst (oder Riesen-Ackerland) aufzuteilen. Da bieten sich Forstbezirke, Revier an und wo das nicht bekannt ist, durchquerende Straßen, Eisenbahnlinien, Flüsse, ...

Warum sind denn so viele MP-Fehler entstanden?

Ich stehe nach wie vor dazu: landuse, natural, ... zu nutzen und wo es "Probleme" gibt dann ein MP (in ganz wenigen Fällen) zu erstellen.
Ist auch für Neumapper einfacher und wesentlich weniger fehleranfällig.

Weide · 2013-01-18 11:13:34

Hi,

ich finde auch, dass man:
1.: alle Flächen möglichst ohne MP mappen sollte (solange man dafür keine willkürlichen
selbstüberlappenden Linien konstruieren muss oder Inseln über dem Wasser schweben lässt).
2.: MPs mit mehreren getrennten outer-Flächen einen Grund brauchen. Gemeinsame Eigenschaften sind
m.E. kein Grund.

Weide

Weide · 2013-01-18 11:25:08

Hi,

christiank61 wrote:

Und da gibt es innerhalb der Mälaren die Insel Lovon (Lovön??) die auf allen Mapsforge Karten im See versinkt, ich möchte das gerne bereinigen.

Nur Lovön? Vielleicht ist das ein Anhaltspunkt für die Suche nach den Ursachen. Lovön sieht zur Zeit OK aus, war aber vom 3.-6.9.2012 kaputt. Das war nicht zufällig der Stand bei den Tests?

Die größere Nachbarinsel Färingsö ist kaputt (zwei nicht geschlossene Linien mit place=island), aber ohne das MP kaputt zu machen. Die wird richtig dargestellt?

Die noch weiter westlich liegende Insel Adelsö hat mehr Punkte. Sie wird richtig dargestellt?

Überschwemmungen werden sehr oft durch natural=coastline verursacht. Da kann jeder kleine Fehler enorm weitreichende Auswirkungen haben. Wenn Du nochmal einen Datensatz (nur Mälaren) testest, dann prüf doch bitte vorher, ob da ein natural=coastline drin steckt. Es darf da keines drin sein.

Weide

christiank61 · 2013-01-18 15:15:31

Weide wrote:

Nur Lovön? Vielleicht ist das ein Anhaltspunkt für die Suche nach den Ursachen. Lovön sieht zur Zeit OK aus, war aber vom 3.-6.9.2012 kaputt. Das war nicht zufällig der Stand bei den Tests?
Die größere Nachbarinsel Färingsö ist kaputt (zwei nicht geschlossene Linien mit place=island), aber ohne das MP kaputt zu machen. Die wird richtig dargestellt?
Weide

Hi,

Schweden habe ich das letzte mal im November gerendert, das Problem mit Lovon (in Mapsforge) existiert seit ich Karten rendere (ca. 1 jahr) und wurde vor ein paar Tagen erneut in der Mapsforge-Dev Gruppe zum Thema. Faringsö ist OK.
Dazu ist zu sagen die Implementierung von MPs in Mapsforge extrem unforgiving ist, was in Mapnik noch lange durchgeht (zB Wege die sich zwischen 2 Punkten 180° revers überdecken, ein Klassiker vor allen bei Coastlines) wird in Mapsforge geskippt. In Lovön gibt es zB eine kleine "outer" in einem "inner", das ist zwar OK aber ob Mapsforge das frisst? - sonst finde ich in Lovön auch keine Fehler obwohl ich schon mehrmals stundenlang gesucht habe.

Bevor ich Schweden das nächste mal rendere werde ich wohl etwas experimentieren...

Grüsse, Christian

Weide · 2013-01-18 18:04:41

Hi,

christiank61 wrote:

In Lovön gibt es zB eine kleine "outer" in einem "inner", das ist zwar OK aber ob Mapsforge das frisst?

Formal ist das in Ordnung ... Aber real war das nur ein U-förmiger Landungssteg und das bischen Wasser innen war als outer des Mälarsees getaggt. Ich hab den Mälar jetzt wieder größer gemacht und ein man_made=pier hinzugefügt. Den großen zweiten outer habe ich ebenfalls verbunden, da da ja nur eine Brücke übers Wasser geht und nicht der Mälar endet. Beim letzten zusätzlichen outer kann man im Luftbild eine wenn auch flache Verbindung sehen. Auch den habe ich verbunden und wir haben jetzt nur noch einen äußeren Rand.

Vor dem Editieren habe ich gesehen, dass da teilweise kein Wasser mehr im Mälarsee ist. Das sind aber hoffentlich nur Reste eines Editierfehlers, der vorher schon repariert wurde.

Weide

christiank61 · 2013-01-19 13:43:44

Ich habe mal aus den Ländern die beim Rendern Probleme bereiten die MP mit wood/forest/water gefiltert und die Anzahl der members=way ermittelt (nur direkte Members).

Jeweils als (relation-id / anzahl ways)
WERTE KORRIGIERT 19.1.2013 14:39

Canada/water:

1120169;1669
1205150;989
1206310;794
1834172;8968 !!!!!
1942868;2056
2365125;712
2379312;874
2468085;1500
2519267;1618
2566179;4026
2567622;673
2584711;675

Canada/wood

1101900;1072
1107111;738
1204611;880
1575612;1378
1622340;622
1643881;811
1998071;809

Japan/wood

945558;1383
949087;1453
959485;1021
961523;2090
964756;626
965719;1856
967915;621
969180;3037
1103869;679
1109350;854
1328589;940
1328622;1218
1328635;1774
1330957;1208
1333283;2574
1333455;696
1336890;639
1337911;722
1338469;1471
1340805;1362
1341460;740
1956189;630
1968525;650
1978268;873

Nur so als Info wenn jemand sich die Relationen mal ansehen möchte
Die Monster-Relation 1834172 mit Ihren fast 9000 Members verursacht sogar einen 500erter Error am OSM-Server....

Gibts ev. Scripte um solche Relationen zu zerlegen (am Heimrechner)?

Grüsse
Christian

Last edited by christiank61 (2013-01-19 14:39:43)

wambacher · 2013-01-19 14:20:27

ich hab mir mal eines diese "Monster" angesehen: 1575612;1956

a) Josm zeigt mir "nur" 1378 Elemente an. Ist deinen Berechnung eventuell ungenau?
b) Es ist das Grauen an sich: Ich sehe da im Luftbuild eigentlich nur EINE Waldfläche mit einigen Seen und Lichtungen. Die OSM-Daten stehen mMn in keinerlei Zusammenhang mit der (damaligen oder jetzigen) Realität. Hier könnte man glatt 1000 inner löschen ohne irgend einen Schaden anzurichten. Automatisch könnte/würde ich das aber nicht machen.

Gruss
Walter

christiank61 · 2013-01-19 14:30:05

wambacher wrote:

ich hab mir mal eines diese "Monster" angesehen: 1575612;1956
a) Josm zeigt mir "nur" 1378 Elemente an. Ist deinen Berechnung eventuell ungenau?

Hoppla, 1378 ist korrekt, ich schau' mir mein script nochmal an....
+++++
So, ich habe die Werte in meinem Beitrag korrigiert - danke für den Hinweis (kleine Klammer, grosse Wirkung), die Riesenrelationen bleiben aber bestehen...

Die 1575612er ist ein Import, wie Du richtig schreibst, stimmen die Daten noch nicht mal, die ganze Relation ist IMO einfach Quatsch!
Scheinbar gibt es hier mehrere Importer die einfach unkritisch Datensätze übernehmen, mir sind auch schon die gt. doppelt getaggten MPs/Ways in Georgia aufgefallen.

Grüsse
Christian

Last edited by christiank61 (2013-01-19 15:24:17)

christiank61 · 2013-01-19 17:29:09

Weide wrote:

Aber real war das nur ein U-förmiger Landungssteg und das bischen Wasser innen war als outer des Mälarsees getaggt. Ich hab den Mälar jetzt wieder größer gemacht und ein man_made=pier hinzugefügt. Den großen zweiten outer habe ich ebenfalls verbunden, da da ja nur eine Brücke übers Wasser geht und nicht der Mälar endet.

Halle Weide,

Was immer Du auch gezaubert hast, jetzt rendern die Mälaren auch in Mapsforge!

Besten Dank
Christian

Weide · 2013-01-19 19:26:58

Hi,

christiank61 wrote:

Was immer Du auch gezaubert hast, jetzt rendern die Mälaren auch in Mapsforge!

Das freut mich. :-)

Hing die riesige Verarbeitungszeit auch daran? Oder ist dieses Problem immer noch offen?

MfG
Weide

PS: "Mälaren" ist Einzahl. Das "en" hinten dran ist im Schwedischen nicht die Mehrzahl, sondern der Artikel. "Mälaren" ist also wörtlich übersetzt "der Mälar".

christiank61 · 2013-01-19 20:06:38

Weide wrote:

Hing die riesige Verarbeitungszeit auch daran? Oder ist dieses Problem immer noch offen?

Lief immer noch 5h (nur die Relation) und zwar im RAM - leider.

LG
Christian

Weide · 2013-01-23 07:32:01

christiank61 wrote:

Lief immer noch 5h (nur die Relation) und zwar im RAM - leider.

Schade.

Ist es wirklich nur die Mälaren-Relation oder alles im Gebiet der Relation liegende?

Die Gegend ist nämlich nicht in einem guten Zustand; da gibt es sehr viele landuse-Überlappungen, über dem Wald schwebende Äcker und Wiesen, Multipolygone mit aneinandergrenzenden outern und vieles mehr. Wenn Verarbeitungsalgorithmen da in wenig effiziente Zweige geraten, ist das nicht schön aber doch verständlich.

Wenn es aber wirklich nur die Mälaren-Relation und ihre Mitglieder sind, dann ist 5 Stunden weit jenseits von Gut und Böse.

Weide

ulmtuelp · 2013-06-01 15:41:10

Hallo Gemeinde,
nicht das ich was gegen MPs habe, aber bis zu welcher Größe ist denn dass sinnvoll?
Bin letztens an der Oder gefahren, und da sind ganze Landstriche in diesem MP ertrunken.
Aufgrund der fehlenden Übersichtlichkeit wurden dann auch gleich weitere Äcker ins MP platziert.

morjak · 2013-06-01 16:22:53

Also ich würde das in mindestens 20 Teile zerhacken.

Announcement

#276 2012-12-23 15:00:35

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#277 2012-12-23 15:10:09

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#278 2012-12-23 16:34:20

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#279 2012-12-23 17:25:31

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#280 2012-12-23 18:02:30

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#281 2012-12-23 23:07:16

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#282 2012-12-24 00:18:06

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#283 2012-12-24 01:43:11

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#284 2013-01-17 18:31:23

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#285 2013-01-18 08:27:20

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#286 2013-01-18 08:53:58

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#287 2013-01-18 10:51:50

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#288 2013-01-18 11:13:34

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#289 2013-01-18 11:25:08

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#290 2013-01-18 15:15:31

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#291 2013-01-18 18:04:41

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#292 2013-01-19 13:43:44

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#293 2013-01-19 14:20:27

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#294 2013-01-19 14:30:05

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#295 2013-01-19 17:29:09

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#296 2013-01-19 19:26:58

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#297 2013-01-19 20:06:38

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#298 2013-01-23 07:32:01

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#299 2013-06-01 15:41:10

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#300 2013-06-01 16:22:53

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

Board footer