Jetzt ist die Frage, liegt es an irgendwelchen Einstellungen bei mir oder ist das ein grundsätzliches Problem bei mkgmap? Andere MPs mit Inseln, z.B. Havel, Tegeler See funktionieren tadellos.
Folgendes habe ich beobachet:
Keinerlei Tags an der Relation → OK
Tags an der Relation, aber nicht am outer Way → OK
Identische Tags an Relation und outer → Problem
Mich würde ja interessieren, ob es jemand schafft, diese Problembereiche korrekt angezeigt zu bekommen.
Die Idee hatte ich auch schon, allerdings hatte ich hier mal gelesen, dass man nicht für Renderer taggen soll. Wie man sieht, kommt Mapnik damit ja klar. Und mkgmap sollte das doch dann auch schaffen, oder?
Das ist nicht Taggen für den Renderer, sondern korrektes Taggen.
Mal informall ausgedrückt: im jetzigen Zustand wird der See von den beiden Ways repräsentiert und gezeichnet, die das “natural=water” enthalten. Und Ways können nur geschlossene Flächen malen. Der Renderer macht also genau das, was die Datenbank ihm vorgibt: zwei geschlossene Flächen malen.
Flächen mit Löchern kann nur ein Relation/Multipolygon malen. Dann muss man der Relation aber auch sagen, dass sie ein See sein soll. Ergo: “natural=water” an die Relation, und schon malt die Relation sauber zwei Wasserflächen für die beiden Outer mit den durch die inner definierten Löchern.
Doch wenn die Relation den See repräsentiert, sind die beiden outer-Ways nur noch Geometrie-Komponenten der See-Relation, also weg mit allen Tags.
Die Verwirrung entsteht daraus, dass es einmal die Idee gab (ein Irrweg), eine Relation als “Lochstanze” für Way-Flächen zu missbrauchen. Dazu hat man Ways in eine ansonsten völlig nackte Relation aufgenommen, die dann die magische Wirkung erzielte, dass beim Zeichnen einer Way-Fläche die Inner-Ways der nackten Relation ausgespart wurden. Leider sind bis heute Reste dieses Irrwegs in der Datenbank, und die Renderer enthalten mehr oder weniger viel Legacy-Code, um diese Reste zu erkennen und vernünftig zu behandeln. Daher rendern in diesen Altlastfällen die Renderer unterschiedlich. Das “wenn A das kann, sollte auch B es können” trifft es also nicht.
In dieser Situation ist es also das schlaueste, einfach sauber zu taggen. Dann sieht das Ergebnis in allen Renderern vergleichbar aus unabhängig vom Umfang des Legacy-Codes. Ist wie bei Browsern und sauberem HTML
Tags, die eine MP-Relation beschreiben gehören an die Relation und nicht an den outer.
An den Inseln fehlt place=islet. natural=water gehören IMHO auch ins MP.
Im Zoo sind einige Flächen mit layer=1 getaggt, weshalb?
Nein, braucht man nicht. Die Dinger werden schon allein dadurch zu Inseln, das sie nicht zur Wasserfläche gehören und von Wasser umgeben sind.
Will man allerdings einen Namen dranschreiben, dann braucht man irgendein Tag auf das sich der Name bezieht – ansonsten würde man ja einfach einer eigenschaftslosen Linie und nicht der Insel einen Namen geben. Da braucht man dann place=islet oder place=island.
Das ist sicherlich alles richtig, aber die Diskussionen zum Thema Multipolygone hier im Forum zeigen ja, dass offenbar nicht allen klar ist, wie man die korrekt taggen muss. Diese zwei Problem-MPs sind mir nur deshalb aufgefallen, weil ich wusste, dass da was nicht stimmen kann. Die Datenbank ist ja offenbar noch voll von nicht korrekt getaggten MPs und wie soll man die alle aufspüren? mkgmap kommt zumindest mit den “nackten” MPs gut klar (im Gegensatz zum MapComposer, den ich früher benutzt hatte). Also ich fände es gut, wenn mkgmap auch Problem-MPs korrekt verarbeiten könnte, ohne in die Datenbank eingreifen zu müssen.
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.
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.
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.
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.
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.
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.
.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. )
:-))
Ü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).
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.
