defektes Multipolygon- See als residential

hallo peter,

um den starnberger see herum sind anscheinend noch so einige multipolygone mit fehlerchen.

beim vergleich der verschiedenen online-karten, die reit- u. wanderkarte mit eingeschlossen,
sieht man zumindest ri. ammersee noch einige nichtgerenderte flächen,
östlich bzw. mit josm habe ich noch nicht weiter geschaut…

vielleicht kannst du dich da auch etwas drum kümmern?

das ein- oder andere polygon sollte man vielleicht auch mal etwas “stubsen”, soll heißen, einzelnen knötchen
ein winziges stückchen verschieben, um die renderer zur arbeit zu motivieren. allein eine änderung innerhalb
eines multipolygons wird anscheinend noch nicht (von allen renderern) als eine änderung erkannt.

(sonst hätten die drei hier veränderten flächenpolygone mit der letzten aktualisierung der ruw-karte am 30.01.
schon mitgerendert werden müssen)

gemeinsame wege solltest du aber nicht auflösen, daran liegt es meiner meinung nach sicher nicht. an anderen
stellen / anderen flächenpolygonen ist das hier auch der fall u. diese werden korrekt gerendert.

schöne zeit u.
grüße,
georg

Wartet mal den nächsten Update ab - ich habe auch was im Renderer geändert. Evtl. sieht das dann wieder gut aus. Oder der See ist ganz weg. :slight_smile:

bye
Nop

Da bin ich etwas anderer Meinung. Eigentliich wollte ich dazu erstmal noch im stillen Kämmerlein etwas mehr Hirnschmalz investieren, aber ich habe da einige Erkenntnisse gesammelt (und mit tippeltappel ausgetauscht), um deren Prüfung und Kommentierung ich hier ausdrücklich bitte.

Mir bekannte betroffene Seen:
 Bodensee (Besonderheit Überlinger See)
 Starnberger See
 Lac de Neuchatel
 Genfer See
 Lago maggiore
 Comer See
 Gardasee

Gemeinsamkeiten:
 natural=water ist als Multioplygon ausgebildet, dessen einzelne ways in der Regel keine tags enthalten
 Alle betroffenen Seen werden mindestens in folgenden Karten und Tools nicht dargestellt
1.Reit- und Wanderkarte
2.Potlatch 2
3.OSM-Inspector (view:water; bodies of water)
4.navit (nicht selbst getestet, siehe http://forum.openstreetmap.org/viewtopic.php?id=9773

Auffälligkeiten:
 Einige ways des Multipolygons sind auch Teile anderer Multipolygone, deren Flächen-tag z.B. potlatch 2 auch nicht auswertet.
z.B.:
way 60256865 am Lac de Neuchatel gehört zu natural=water und landuse=forest jeweils als outer;
way 94599469 am Starnberger See gehört auch zu natural=wetland als outer; way;
way 54436444 am Bodensee-Obersee als inner ist auch landuse=residential als outer und hat Flächen-tags;
way 54129245 am Comer See gehört auch zu landuse=forest als outer
 Sobald ein way (nicht nur ohne tags) zu mehreren Flächen-Multipolygonen gehört, werden alle betroffenen Flächen-Multipolygone in einigen Karten und Tools nicht als Fläche dargestellt.

Mehr Beispiele habe ich dann nicht mehr gesucht. Als einzige Fehlerquelle erkenne ich momentan, dass die Zuordnung einzelner ways zu mehreren Flächen-Multipolygonen das Problem erzeugen. Ich werde das mal an zwei kleinen Baggerseen im Wald hier in der Nähe durchtesten.
(da merkt es hoffentlich keiner :wink:

Sollte jemand andere Fehler als Ursache reproduzierbar identifiziert haben oder meine Vermutungen ausschließen können, bitte ich um entsprechende Hinweise.

Auch die Nennung weiterer betroffener Tools und Anwendungen ist willkommen.

Ist korrekt. Derzeit gibt es keine Behandlung für solche Multipolygonzüge im Navit Maptool.

Ich sehe das Problem in einer etwas voreiligen Propagierung komplexer Polygonzüge bei OSM. Es ist nicht ausreichend, es in die 3 Haupttools (josm, osm2pgsql, mkgamp) einzubauen und anzunehmen man wäre fertig. Es gibt vermutlich Hunderte von anderen Anwendungen, Importen, Skripten Karten usw. die das alle nicht unterstützen und dementsprechend die See- und Waldflächen weglassen. Die Auswertung solcher Polygonzüge ist auch nur dann einfach, wenn man entweder so wenige Daten hat, daß sie gleichzeitig in den Speicher passen (JOSM, mkgmap) oder wenn man eine mächtige PostGIS Datenbank hat, die die Arbeit übernimmt. Für einen Kartenkonvertierer/importer ist es alles andere als einfach, das zu erkennen und umzusetzen ohne daß die Performance unterirdisch wird.

Zudem gibt es Tausende von Mappern, die diese Polygonzüge nicht kennen bzw. nicht erkennen - oder sie werden in ihrem Editor gar nicht erst angezeigt - und dann beim Versuch einer Änderung die Daten beschädigen. Insbesondere das Verlagern der Tags an die Relation sorgt dafür, daß alle alten Tools gar nix mehr zeigen und der Normalmapper die Tags ebenfalls nicht mehr findet.

Der bewohnbare Starnberger See ist richtig erkannt eine Fehlerinterpretation von doppelter Multipolygonzugehörigkeit. Die RWK sollte hoffentlich heute Nacht nachziehen und das Zeug richtig rendern - für alle anderen Karten, Tools und Mapper da draußen bleibt das Problem bestehen.

bye
Nop

@hurdygurdyman:

als weitere Anwendung, in der diese Seen nicht dargestellt werden bzw. wurden:
5. mapfactor Navigator 10 free

Mit dem neuseten Karten-Update vom 23.01.2011 sind die Seen und die Schlei dort wieder als Gewässerfläche sichtbar (s.a. hier #78)

Was dort genau beim Rendern/Erstellen der Karte geändert wurde, kann ich nicht sagen.
Dafür fehlen dort jetzt die Flüsse nahezu komplett (s.a. hier #77)

Vielleicht helfen diese Infos beim Eingrenzen des Problems
Gruß Jörg

Das Preprocessing ist doch mehr oder weniger einfach:

Gehe durch alle Relationen
Wenn type=multipolygon
Wenn interessante polygon-Tags in Relation
dupliziere alle Wege mit role=outer
füge diesen die Tags der relation hinzu (oder interne Alias-Tags)
lösche entsprechende Tags in Relation

Fertig sind die “alten” Multipolygone. Mapnik und Osmarender kommen mit den “neuen” Multipolygonen im übrigen auch klar.

Warum “interessante polygon-Tags in Relation”? Wenn man das sauber umsetzen will, dann muss man das fuer alle Tags machen (mal abgesehen vom type=multipolygon)

In deiner Liste fehlt ausserdem der Schritt, die alten Wege mit der role=outer aus der Relation zu entfernen.

Das Hauptproblem ist und bleibt aber, dass solche Konstrukte fuer Gelegenheitsmapper viel zu kompliziert sind.

Gruss
Torsten

Selbst für einen mit alten MP-Formen erfahrenen Mapper ist es nicht ganz einfach, die neuen Multipolygonstrukturen mit den aneinander gehängten Wegen auf Anhieb zu durchschauen. Das Prinzip habe ich verstanden. Doch als ich mir die Konstrukte in Potlach2 ansah, kam ich erst einmal sehr ins Grübeln.

Unabhängig davon:
Das Schwierige bei der Fehlersuche ist, daß es sehr mühsam ist, winzigen Linienüberschneidungen auf die Spur zu kommen.
Zumindest in Potlach. In JOSM hab ich das noch nicht ausgetestet und andere Editoren kenne ich nicht.
Wäre es eventuel machbar, in Potlach einen Fehlerhinweis an Multipolygonüberschneidungen einzubauen?
Für duplizierte Nodes gibt es ja diese “Blinker”.

So ein Fehlerhinweis würde beim “Aufräumen” sicherlich sehr helfen. Vor allem bei großen Objekten, wo das Punkt für Punkt Absuchen einen erheblichen Zeitaufwand mit sich bringt.

@ Nop
Würdest Du diesen Wunsch bei den “Potlachern” vortragen? Ich weiß nicht, wie ich denen das in Englisch vermitteln soll.

Viele Grüße
tippeltappel

hallo michael, nop etc.

schön dass ihr euch so viel mühe mit dem thema macht und an der diskussion hier beteiligt!

und gerade die beispiele von michael machen mich nun auch etwas nachdenklich…

explicit habe ich mir hier das beispiel des “Lac de Neuchatel” etwas genauer angeschaut und
konnte an den beiden flächenpolygonen selbst keinen fehler finden. ausser dem von michael angegebenen
und gemeinsam genutzen weg gibt es hier auch noch weitere doppelt genutzte wege…

ich habe dann gleich einige von mir selbst angelegte multipolygone in der ruw-karte betrachtet…
wo beispielsweise wald- auf wiesenpolygone treffen, scheint die welt in ordnung, acker- und wiesenflächen werden
aber anscheinend generell nicht gerendert… (?)

doch wasserflächen als multipolygon scheint echt ein problem zu sein…

so hatte ich vor einiger zeit einen teil des flusses “main” als multipolygon angelegt, einige inselchen eingezeichnet
und bis eben nur in mapnik, osmarender u. der cyclemap gecheckt. wie ich nun sehe, wird er in der ruw-karte nicht
mehr angezeigt…

der fluß ist als “waterway=riverbank” getaggt,
die tags sind auf dem einen geschlossenen äußeren weg als auch der multipolygonrelation selbst
es wird kein weg von angrenzenden flächen (solo oder mpg) gemeinsam genutzt, sondern diese liegen mit gemeinsamen
knoten aufeinander

dies scheint ja nun die theorie von michael (dass es an gemeinsam genutzten wegen liegen könnte) nicht direkt zu unterstützen
sondern eher vielleicht auf ein generelles problem mit wasserflächen-polygonen hinzuweisen. (?)

ist das so, nop? wie du schreibst hast du ja hier etwas geändert u. wir lassen uns da mal überraschen, vielleicht ist dann
das problem (zumindest in deiner karte) ja bereits gelöst.

danke vorab u.
grüße,
georg

zur verdeutlichung hier noch ein ausgeschnittener screenshot aus der ruw-karte:

und wer es sich sonst betrachten möchte, es ist die relation 1309724
hier noch mapnik: http://www.openstreetmap.org/?lat=49.76801&lon=9.34666&zoom=16&layers=M

Ja, die schließt Nop generell vom Rendern aus.
Ist bei der Fehlersuche zunächst etwas verwirrend.
Kennst Du diesen Thread? http://forum.openstreetmap.org/viewtopic.php?id=10554
Da findest Du Hinweise zu dieser Eigenheit der Wander-Reit-Karte.

Gruß
tippeltappel

Meinst Du wirklich Wasserflächen-Polygone?
Oder sprichst Du von Multipolygonen?

Ich habe da noch einen weiteren Verdacht und eine Theorie:
Tags, die für Flächen oder Punkte vorgesehen sind, sollte man nicht für ways verwenden, welche dann wieder per Multipolygon zur Fläche zusammengefügt werden.
waterway=riverbank ist auch laut wiki ein Flächen-tag. Dort steht auch ausdrücklich, dass man ausgedehnte Flächen in einzelne Flächen aufteilen soll. Diese Einzelflächen könnte man dan als Multipolygon zum Fluss zusammenbauen.

Wenn wir analog z.B. Seen und Wälder bei Bedarf in Teilflächen zerlegen würden, käme da wohl jeder Mapper und Renderer mit klar und wir hätten einfachere weniger fehleranfällige Verhältnisse ohne die hohe Kunst des Multipolygons (dessen Notwendigkeit ich nicht generell in Frage stelle).

Irgendwie werden wir doch eine Lösung finden, die allen gerecht wird, ohne dass ein Glaubenskrieg ausbricht.

Ich habe mir das mal angeschaut und vermute:
Der outer way ist in sich geschlossen und besteht nicht aus mehreren ways. Dann ist es nicht erforderlich, das natural=water auch noch auf dem Multipolygon zu taggen. Mach das mal weg und die RuW dürfte keine Probleme mehr haben. Die inner-Flächen werden ausgeschnitten und sichtbar.

Beim östlichen Nachbarn (Relation 1360139) ist es übrigens genauso gemacht (kein natural=water-tag auf dem MP).

Ich denke das Problem geht tiefer. Im Simple Mode von P2 wird ein Way durch ein Icon und eine Eingabemaske für Tags repräsentiert. Bei diesen Multipolys sind plötzlich gar keine Tags am way und das Aufhänger-Objekt ist eine Relation. Oder mehrere bei geteilten Ways.

Ich. Hab keine Idee wie man das mit den Mitteln von P2 darstellen will - das ist einfach nicht mehr “simple”. Ich würde eher alle Multipolys. Die nicht zu groß sind lieber als normale Multipolys mit einem einzigen outer und ohne Tags an der Relation einzutragen.

Meines Erachtens löst dies das Problem nicht. Sondern ist es nicht prinzipiell so, dass nie jeder alles verstehen wird und auch nicht muss? Und je mehr wir kartieren, je mehr Merkmale und Funktionen eingeführt werden umso mehr wird dies der Fall sein. So machen mir Multipolygone keine Probleme mehr seit ich mich mal richtig reingehängt habe. Anschließend konnte ich das englische und deutsche Wiki hierzu erweitern.

Aber es gibt viele andere Features in OSM von denen ich vielleicht mal etwas gelesen, aber zumindest zur Zeit keine Ahnung habe. Und was mache ich in dieser Situation? Ich respektiere die Beiträge und Methoden Anderer und lasse die Finger davon. Wenn ich irgendwo mit solch einer Konstruktion Probleme habe oder meine zu haben, kann ich den Mapper anschreiben, hier im Forum oder der Mailingliste nachfragen oder mir selbst die Materie aneignen. Dies ist wie im sonstigen Leben auch. Obwohl mein alter Führerschein mir gestattet, LKW bis 7,5 t und Motorräder jeglicher Größe zu fahren werde ich das nur tun wenn ich sicher bin, dass ich das Fahrzeug beherrsche.

Auch meine Meinung (und die anderer…). “keep it simple” oder zu deutsch etwa “weniger ist mehr” (für edwin) halte ich für das Beste.

Wenn wir bei waterway=riverbank mit Teilflächen gut klar kommen und uns vorstellen, dass ein See auch nur ein Fluss mit sehr weit auseinanderliegenden Ufern sei, dann kommen wir vielleicht darauf, dass man den See auch in Teilflächen zerlegen kann. Schaut Euch mal den Überlinger Teil des Bodensees auf der RuW an. Er hält tapfer die mit Wasser gefüllte Stellung, währen der östliche Rest trocken liegt (und die Schwaben bald kein Trinkwasser mehr haben :wink:
Warum allerdings die Mainau überschwemmt ist, muss ich mal checken :frowning:
Bis dann

Edit:
Auch bei der Relation “Bodensee-Überlinger See (74974)” liegt natural=water jeweils auf der Relation und dem geschlossenen way “Bodensee (Überlinger See) (48784977)” wie beim Mai-Teil (siehe oben). Muss m.E. einmal entfernt werden.

Wenn das so weitergeht, brauchen wir bald eine OSM-Putz- und Flickgruppe…

Für Gelegenheitsmapper könnte man an kritischen Stellen (wo es häufiger zu Fehlern kommt) einfach ein note an die ungetaggten Ways pappen, der darauf hinweist, dass das Objekt durch ein Multipolygon beschrieben wurde.

Letzlich ist es aber eine Frage des Editors und wie er den Mapper (ob nun Profi oder Anfänger) unterstützt. Die Flächen werden von JOSM ja schon erkannt und entsprechend gerendert. Evtl. könnte man noch an die entsprechenden Ways im Eigenschafts-Menüfenster eine neue Tabelle hinzufügen mit den geerbte Tags aus Multipoligonrelationen. In den aktuellen JOSM-Versionen ist es ja schon soweit umgesetzt, dass man solche Relationen direkt über die Presets für die jeweiligen Objekte erstellen kann. Hier fehlt lediglich noch das automatische setzen von type=multipolygon.

Wenn Potlatch das noch nicht kann, sollten die Entwickler daran Arbeiten. Aber meiner Meinung kann es nicht sein, dass sich ein Taging nach dem Können eines Editors richten muss.

@Willi: +1 Bus-Relationen sind für mich so ein Rotes Tuch…diese deshalb als überkompliziert und “sinnfrei” darzustellen würde ich mir aber nicht anmaßen.

hallo tippeltappel,

sorry wenn ich mich missverständlich ausdrücke…

mit “wasserflächen-polygon” meine ich natürlich ein multipolygon mit wasserflächen-eigenschaften,
also “natural=water” oder “waterway=riverbank”

ist das nicht korrekt? ich kürze das gerne mal ab, z.b. wenn ich den flächentyp mit angebe…

wobei ich mir über die wortherkunft als vieleck schon im klaren bin… (dies nur für die “schulmeisterle” hier!) :slight_smile:

und danke für den link zu dem anderem thread, bin hier noch am durchlesen…

grüße,
georg

nachtrag, eben erst gesehen, danke michael, werde das wasserMULTIpolygon noch mal checken, hatte eigentlich an
den unterschiedlichen namen-tag (auf weg, nicht in multipolygon) gedacht u. vorhin noch geändert, muss nun leider weg… bye

Soweit richtig. Allgemein sollte man grosse Flaechen in Teilflaechen unterteilen, da grosse Objekte erhebliche Nachteile mit sich bringen. Deshalb ist ja auch in der API ein Limit fuer die maximale Knotenanzahl eingefuehrt worden.

Und das ist nun nicht mehr richtig. Ein Multipolygon ist nicht dazu da, um aus Einzelstuecken ein uebermaessig grosses Objekt zusammen zu bauen. Denn sonst koennte man ja gleich das Riesenobjekt in die Datenbank eintragen und sich den Umweg ueber das Multipolygon sparen

Es reicht voellig, wenn die Teilflaechen aneinander Grenzen. Bei den Strassen brauchen wir ja auch keine Relationen, um anzugeben, dass die Strasse von einem Abschnitt zum naechsten geschlossen weiter verlaeuft.

Gruss
Torsten

Sorry, da war ich falsch (Denkfehler). Aber wie ist es, wenn man aus den einzelnen riverbank-Flächen eine Relation für den Fluss ahnlich wie bei langen Wanderwegen macht? Muss, glaube ich, auch nicht sein, weil die Fluss-Information ja schon am waterway=river hängt.

Und das Aneinandergrenzen der Flächen sollte doch über gemeinsame (mind.zwei) Knoten bei Flächen gehen, oder? Wenn ich das wieder auf die Seen als "breiten Fluss"übertrage, dürfte das auch zum routen eines Schiffes, das ja i.d.R. über Himmelrichtungen als direkte Peilung läuft, kein Problem sein, außer man hat Fahrrinnen, Untiefen oder Bojen zu beachten.

Was hindert uns also, die Teilflächenlösung weiterzudenken und uns von der Uferlinie als zusammengesetztes Multipolygon aus mehreren outer-ways für Seen zu verabschieden?