Diese "Problem-"polygone gehen auf ein veralteste tagging zurück. Daher wäre es sinnvoller diese in der Datenbank zu finden und zu bereinigen anstatt jedes Anwendungsprogramm mit der Fehlerbeseitigung zu behelligen.
Nahmd,
Du greifst nicht in die Datenbank ein, um ein bestimmtes Ergebnis zu erhalten.
Sondern Du greifst ein, weil der aktuelle Eintrag defekt ist.
Das ist so ähnlich, wie wenn du ein “shop=butcher; name=Bäckerei Roleber” findest. Da erwartest Du nicht, dass irgendein Programm aus dem Wort “Bäckerei” im “name=”-Tag ableitet, dass das “shop=”-Tag falsch ist und Dir eine Brezel statt einer Schweinshaxe rendert, sondert Du fixt den Eintrag. Dito hier.
Gruß Wolf
Wie sieht denn das Suchschema aus um die inkorrekten MPs zu finden ?
Gruß Klaus
Gerade Mapnik bügelt IMHO viele MP-Fehler aus. Siehe Tiergarten.
Klicken und schauen 
Im Ernst. Die Multipolygonsicht des OSMI, die ich öfters nutze (leider seit 10 Tagen nicht mehr aktualisiert), zeigt schon einige Fehler. Wegen der Überschaubarkeit habe ich die Overlays type=boundary und Context deaktiviert.
Da schau ich mir dann auch so einige andere Taggings/Mappings an.
Hmm, das ist nicht einfach.
Nehmen wir mal eine äußere geschlossene Linie A und eine darin befindliche geschlossene Linie B. Dann gibt es drei Flächen, die (außer in dem von Netzwolf genannten Irrweg) alle mit Eigenschaften versehen werden können (außer bei der von Netzwolf so treffend Irrweg genannten Taggingart):
1: Die komplette von der Linie A umschlossene Fläche. Sie hat Tags in A.
2: Die von der Linie B umschlossene Fläche. Sie hat Tags in B.
3. Die zwischen A und B liegende Fläche. Sie hat Tags im Multipolygon (outer A; inner B)
- und 2. sind ganz klassische OSM-Flächen, wie es sie schon lange vor Erfindung des Multipolygons gab. Nur der “Irrweg” hat versucht, das zu ändern … vernünftige Multipolygone sind total kompatibel mit der alten Regelung.
Erstmal muss man den “Irrweg” erkennen (leere MP-Relation und nur ein(?) outer). Es ist zwar ein Irrweg, aber er ist nicht illegal. Da muss man mit dem Ersteller reden oder so…
Ansonsten:
Fehlerhaft ist es vermutlich immer, wenn zwei von den o.g. drei gleiche Tagwerte haben. Na ja: falls diese Tags irgendwie wichtig sind – source=Bing wäre in diesem Sinne unwichtig.
Wenn A ein landuse hat, dürfen B und das MP kein landuse haben. Vielleicht gibt es noch mehr.
Na ja, ob das jetzt wirklich alles ist… Jedenfalls könnte man Verdächtiges raussieben und dann zufuß prüfen.
Weide
Nahmd,
Ich hab die beiden Multis gefixt.
Sobald Du aktuelle Daten hast, sollten die Inseln wieder aus dem See auftauchen.
Gruß Wolf
.oO( Und ER nannte das Trockene “inner”, und die Sammlung der Wasser nannte ER “outer”. Und ER sah, daß es gut war. )
Aus meiner Sicht sind da zwei unterschiedliche Probleme relevant:
Rel 5007: Die Relation ist getaggt mit
name=Spree
natural=water
type=multipolygon
Das erscheint mir erst mal soweit richtig. Allerdings ist der outer Way mit
natural = water
waterway = riverbank
getaggt. mkgmap erzeugt hierfür ein richtiges Multipolygon getaggt mit [name=Spree, natural=water]. Allerdings wird auch der outer Way noch gezeichnet mit [waterway=riverbank], da mkgmap nicht wissen kann, ob das waterway=riverbank Tag bereits durch das MP abgegolten sein soll. Das kann dazu führen, dass das riverbank Polygon die anderen Polygone überlagert.
Fazit: Eindeutiger Tagging-Fehler. Hier kann mkgmap nix machen.
Rel 26993: Die Relation ist getaggt mit
name=Neuer See
type=multipolygon
Da die Relation außer mit type noch mit einem anderen Tag versehen ist, lautet die Regel, dass die Tags des MP und nicht die Tags der outer Ways genommen werden. Daher ist dies auch hier ein Taggingfehler.
Allerdings ist der Fehler (MP nur mit name Tag) so häufig, dass er eigentlich von mkgmap akzeptiert werden soll. Das scheint aber bei irgendeiner anderen Änderung von mgkmap verloren gegangen sein. Ich werde das demnächst korrigieren.
Fazit: Tagging-Fehler, der allerdings so häufig ist und eindeutig zu identifizieren ist, dass er von mkgmap toleriert werden soll.
Grundsätzlich gilt für MPs die einfache Regel:
Die Tags entweder alle beim MP setzen **oder **die Tags auf **allen **outer Ways setzen.
WanMil
Sooo eindeutig ist das nicht. Wenn das Multipolygon einen unvollständigen Satz von Tags hat, dann kann man nicht einfach die Tags des/der outer nehmen. Sie könnten ja tatsächlich auf ganz klassische Art dort hin gehören.
Das ist übrigens keineswegs ein rein akademischer Fall. Nehmen wir die zumindest nicht abwegige Aussage, dass die Insel Mainau Teil des Bodensees ist(, aber natürlich nicht Teil der Wasserfläche). Dann würde (wenn der Bodensee einfach und Mainau die einzige Insel wäre) das natural=water ins MP kommen, das name=Bodensee ans outer (mit place=location) und das name=Mainau (mit place=island) ans inner.
Außerdem glaube ich nicht, dass das on-the-fly-reparieren von Fehlern beim Rendern irgendeinen Nutzen hat. Wenn wir damit endlich aufhören, dann wird erstmal einiges verschwinden … aber es wird schnell repariert und die Mapper machen viel weniger Fehler. Wenn jedes erkennbar kaputte MP garnicht gerendert wird, dann wird die Datenbank besser und die Karte wird (nach einer kurzen Übergangsphase) auch besser. Anfangen sollte man aber zugegebenermaßen mit sowas nicht bei mkgmap. Mapnik ist da zuerst gefragt.
Weide
.oO( Und ER nannte das Trockene “inner”, und die Sammlung der Wasser nannte ER “Multipolygon” und das Ende der Welt nannte ER “outer”. Und ER sah, daß es gut war. )
:-))
Weide
Über die Richtigkeit dieser Tagging-Variante möchte ich nicht urteilen, auch wenn ich die Sinnhaftigkeit bezweifle.
Bei meiner Aussage ging es um etwas anderes. Nämlich die häufige Variante das MP nur mit einem name-Tag zu versehen.
Laut Wiki müssten dann die Fläche des MPs nur anhand des Tags “name” gezeichnet werden. Dadurch wird sie nicht gezeichnet, da es für ein alleinstehendes name-Tag keine Zeichenregel gibt (macht auf jeden Fall bei mkgmap keinen Sinn).
WanMil
Danke, dann ist ja erst mal sichergestellt, dass wir GPS-Freaks bei der nächsten Paddeltour aufm See nicht auf unbekannte Landmassen stoßen :D.
@WanMil
Besten Dank für die Analyse und die Erläuterungen zur Funktionsweise von mkgmap. Jetzt wird mir einiges klar. Super auch, dass du die Fehler der Tagger ausbügeln willst. Da Wolf ja die beidn MPs gefixt hat, werde ich mir mal die alten Tiles aufheben, um das Verhalten der neuen Version demnächst zu testen (ich weiß ja nicht, wo sonst noch fehlerhafte MPs nur mit name Tag schlummern).
Die andere Sorte Fehler lässt sich nicht so leicht beheben? Die kommt doch sicherlich auch öfters vor. Könnte man da nicht mkgmap sagen, dass es die outer Tags komplett ignorieren soll, wenn das MP schon welche hat? Oder kann man das evtl. in eine Regel für die Relation einbauen?
Und wer soll die alle “reparieren”? Ich denke da nur an die zig building MPs, alle ohne Tags an der Relation. Im Übrigen zeigt(e) der OSMI keine Fehler an bei den 2 besagten Problem-MPs.
Grüße, hapega
Da stimme ich Dir zu. Aber woher bekommt man ein Tag mit Zeichenregel? Zu dem Thema wollte ich anmerken, dass man es nicht einfach aus dem outer nehmen kann, da es evtl. absichtlich im outer ist und mit dem MP nichts zu tun hat. Daher finde ich es nicht einfach, den “name-only”-Fehler zu korrigieren.
Weide
Ganz ignorieren darf man sie nicht. Wenn das MP Tags hat, dann beziehen sich die Tags an der outer-Linie auf diese Linie. Sie dürfen nicht ignoriert werden, sie haben nur nichts mit dem MP zu tun.
Weide
Das kann man nichts reparieren, denn es ist kein Fehler. Ich stimme Netzwolf voll und ganz zu, dass es ein Irrweg ist. Aber es ist nun einmal zulässig, es hat eine klare Bedeutung und muss so interpretiert werden.
Weide
Muss Neuer See nichts als inner in die Wald-Relation?
Oder besser: das Wald-MP sollte um den großen See herumgelegt werden, sonst produziert man intersections.
Ja, das sehe ich auch so. (Die beiden outer von Neuer See natürlich, nicht die Relation Neuer See)
Dann müsste man aber noch überlegen, ob man nicht die dadurch erzeugten touching inner vermeiden will.
Weide
Du hast dir jetzt einen Fall herausgegriffen, der ziemlich klar scheint. Aber wie sieht es denn mit einer Weide aus? Als Fläche hast du das Wiese/Weide und außenrum besitzt das Ding einen Weidezaun. Spätestens hier scheitern deine Versuche das eine zu ignorieren und das andere zu übertragen.
Aus meiner Sicht wird andersrum “ein Schuh draus”. Die (durchaus verbreitete) Praxis, Linien (hier fence) und Flaechen (hier Weide) gleichzeitig an einem geschlossenen Weg zu taggen macht es den Auswertern unnoetig schwer und sollte “verboten” werden.
Gruss christian
Hi,
ich denke, dass viw hier eine als MP dargestellte Weide meinte (MP, weil z.B. mittendrin noch eine Ruine steht). Dabei tritt das von Dir angesprochene Problem nicht auf, das die Tags der Weide dann im MP liegen und die Tags des Weidezauns dann im outer. Es ist ein Beispiel dafür, dass man die Tags im outer weder ignorieren noch ins MP übernehmen kann.
Das von Dir angesprochene Problemtagging ist m.E. schon “verboten”. Durch die Benutzung irgendeines Flächentags an einer geschlossenen Linie wird das Objekt die Fläche. Alle Tags beziehen sich auf das Objekt. Nicht für Flächen geeignete Tags sind dann also falsch.
Weide (der Mapper, nicht das o.g. Objekt :-)) )