Multipolygone bei mkgmap

Nahmd,

hapega wrote:

nach einiger Bastelei habe ich mit der Erstellung von Garmin img-karten mit mkgmap gute Ergebnisse erzielt. Allerdings gibt es immer noch Darstellungsprobleme bei einigen Multipolygonen, z.B in Berlin fehlen die Inseln hier: http://www.openstreetmap.org/?relation=26993 und hier http://www.openstreetmap.org/?relation=5007.

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.

Ich denke, das Tagging ist falsch:

ergänze ein "natural=water" an der Relation und tilge es an den beiden outer-Ways. Dann sollten die Löcher auch gerendert werden.

Gruß Wolf

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?

Nahmd,

hapega wrote:

Die Idee hatte ich auch schon, allerdings hatte ich hier mal gelesen, dass man nicht für Renderer taggen soll.

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.

Wie man sieht, kommt Mapnik damit ja klar. Und mkgmap sollte das doch dann auch schaffen, oder?

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 🙂

Gruß Wolf

hapega wrote:

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?

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?

Hi,

Radeln wrote:

An den Inseln fehlt place=islet.

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.

Weide

Weide wrote:

Hi,

Radeln wrote:

An den Inseln fehlt place=islet.

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.

Weide

Nachvollziehbar, ergibt sich aber so nicht aus dem Wiki. Sehe gerade, dass es im Englischen Wiki besser beschrieben ist.

Netzwolf wrote:

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

Radeln wrote:

Tags, die eine MP-Relation beschreiben gehören an die Relation und nicht an den outer.

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.

Grüße, hapega

hapega wrote:

Netzwolf wrote:

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

Radeln wrote:

Tags, die eine MP-Relation beschreiben gehören an die Relation und nicht an den outer.

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.

Grüße, hapega

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,

hapega wrote:

Also ich fände es gut, wenn mkgmap auch Problem-MPs korrekt verarbeiten könnte, ohne in die Datenbank eingreifen zu müssen.

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

hapega wrote:

Netzwolf wrote:

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

Radeln wrote:

Tags, die eine MP-Relation beschreiben gehören an die Relation und nicht an den outer.

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.

Grüße, hapega

Gerade Mapnik bügelt IMHO viele MP-Fehler aus. Siehe Tiergarten.

toc-rox wrote:

Wie sieht denn das Suchschema aus um die inkorrekten MPs zu finden ?

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.

toc-rox wrote:

Wie sieht denn das Suchschema aus um die inkorrekten MPs zu finden ?

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)

1. 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,

hapega wrote:

nach einiger Bastelei habe ich mit der Erstellung von Garmin img-karten mit mkgmap gute Ergebnisse erzielt. Allerdings gibt es immer noch Darstellungsprobleme bei einigen Multipolygonen, z.B in Berlin fehlen die Inseln hier: http://www.openstreetmap.org/?relation=26993 und hier http://www.openstreetmap.org/?relation=5007.

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. )

hapega wrote:

Hallo,

nach einiger Bastelei habe ich mit der Erstellung von Garmin img-karten mit mkgmap gute Ergebnisse erzielt. Allerdings gibt es immer noch Darstellungsprobleme bei einigen Multipolygonen, z.B in Berlin fehlen die Inseln hier: http://www.openstreetmap.org/?relation=26993 und hier http://www.openstreetmap.org/?relation=5007.

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

WanMil wrote:

Fazit: Tagging-Fehler, der allerdings so häufig ist und eindeutig zu identifizieren ist, dass er von mkgmap toleriert werden soll.

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

Netzwolf wrote:

.oO( Und ER nannte das Trockene “inner”, und die Sammlung der Wasser nannte ER “outer”. Und ER sah, daß es gut war. )

.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

Weide wrote:

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.

Ü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

Netzwolf wrote:

Ich hab die beiden Multis gefixt.

Danke, dann ist ja erst mal sichergestellt, dass wir GPS-Freaks bei der nächsten Paddeltour aufm See nicht auf unbekannte Landmassen stoßen 😄.

@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?

Weide wrote:

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.

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

WanMil wrote:

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).

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

hapega wrote:

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?

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

hapega wrote:

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.

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

Netzwolf wrote:

Nahmd,

hapega wrote:

nach einiger Bastelei habe ich mit der Erstellung von Garmin img-karten mit mkgmap gute Ergebnisse erzielt. Allerdings gibt es immer noch Darstellungsprobleme bei einigen Multipolygonen, z.B in Berlin fehlen die Inseln hier: http://www.openstreetmap.org/?relation=26993 und hier http://www.openstreetmap.org/?relation=5007.

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. )

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.

Radeln wrote:

Muss Neuer See nichts als inner in die Wald-Relation?

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

hapega wrote:

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?

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.

viw wrote:

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 :-)) )