Es kommt manchmal vor, dass eine Grenze mit einer Fluss- oder
Straßenmitte identisch ist.
Das wird dann in OSM entsprechend an einem Weg eingetragen.
Für die Behandlung solcher Situationen muss man für die Kombination
boundary-waterway, boundary-highway oder highway=* + railway=tram
entsprechende Regeln erstellen. Ohne diese zusätzlichen Regeln hängt es
vom internen Ablauf von mkgmap ab, welche Darstellung gewinnt.
Der Fluss ist durch den Verlauf der Linie mit waterway=river definiert.
Durch waterway=riverbank kann man die Ufer und damit auch die
Breite / Wasserfläche beschreiben.
PS: Statt der Koordinaten wäre ein Permalink auf den entsprechenden
Bereich in der OSM-Karte leichter nachzuvollziehen.
Für meine Karte habe ich keine Regeln für boundary in den mkgmap Styles (denke das ist damit gemeint) erstellt. Habe es eben mit einer älteren mkgmap-Version (1625) probiert. Alles i.O. Liegt dann wohl an mkgmap?
Der Fluss, genauer sein Verlauf ist nur einmal als OSM-Weg eingetragen
(waterway=river). Das andere ist die Wasserfläche, die durch den Fluss
gebildet wird. Dafür wird die Wasserfläche als beidseitige Uferlinie
eingetragen (waterway=riverbank).
Das verhält sich ähnlich wie mit Straßen (linearer Weg) und Straßen-
flächen. Das wird auch getrennt eingetragen und getaggt.
Dort steht unter anderem:
*Zusätzlich sollte ein Way mit waterway=river (Way 4 im Beispiel unten) in
Richtung des Wasserflusses gezeichnet werden (z.B. von der Quelle in die See). *
ja, solche entscheidenden Informationen werden gerne überlesen …
edit: waterway(river) und boundary sind hier getrennt erfasst.
Deshalb ist der waterway=river wie auch der name=Rhein an diesem kurzen Stück boundary überflüssig, also habe ich beide gelöscht.
Gruß
Georg
PS:
Mit Permalink schauen sich die Leute die Situation anscheinend eher mal in Potlach an, als wenn sie die ID aus dem Post mit JOSM herunterladen müssen …
Tut mir leid, das hat sich mir aus deinen bisherigen Beiträgen
so nicht erschlossen. Wir haben dadurch an einander vorbei
geredet. Mangels Permalink konnte ich die konkrete Situation
leider nicht selber erforschen.
Wenn der Fluss und die Grenze zwei getrennte Wege mit
gegebenfalls identischen Knoten sind, dann ist ein zweites
waterway=river an der Grenze überflüssig/falsch.
Also weg damit, wie es GeorgFausB bereits gemacht hat.
Bei Straßen (lineare Struktur) ist das weitgehend Konsens.
Bei Plätzen leider nicht.
Für Routenrelationen sind Flächen natürlich ein Problem.
Bei deinem Beispiel führt das Fehlen direkter Wege über die
Domplatte leider dazu, dass beim Fußgänger-Routing die
Domplatte manchmal ignoriert wird, obwohl sie die kürzere /
angenehmere (ohne Autos) Verbindung bietet.
Hintergrund ist, dass Routingalgorithmen oft nur über die
Kanten eines Platzes routen, sprich nicht in der Lage sind
den meist kürzeren Weg quer über eine Fläche zu nehmen.
Danke an beide. Da waren noch einige zu bereinigen.
Den beschriebenen Fehler (Pseudoflüsse) habe ich auch noch an anderen Stellen (z.B. Mosel) festgestellt, wo kein doppelter Tag vorhanden ist. Fehler muß also an mkgmap liegen. Habe dies mal auf der mkgmap-Mailingliste kundgetan.
Wenn zwei Wege wie in deinem Beispiel einmal mit
waterway=river und einmal mit boundary=administrative
übereinanderliegen, kommt es auf die Reihenfolge der
Renderregeln an, welche Darstellung letzlich gewinnt.
Die Reihenfolge kann durch die Standard-Regeln von
mkgmap oder durch deine Änderungen daran definiert
sein. Es kann ohne weiteres sein, dass sich die Standard-
Regeln von einer Version zur nächsten geändert haben
und damit ein anderes, eventuell nicht erwartetes /
bedachtes Ergebnis liefern.
Dieses Verhalten auf der mkgmap-Mailingliste zur Sprache
zu bringen ist sicher der richtige Weg, die Situation zu klären.
Hier einen Ausug aus einer Antwort der MAilingliste:
From your screenshot I can now guess, what you mean: There are also other ways
in the map, which are dislpayed as river, although they are only tagged as
boundary AND NOT as river at the same time?
If this is the case, I would guess, that the complete boundary is made up out of
a multipolygon.
In this case the multipolygon tagging seems to be faulty. Either all outer ways
must be tagged the same (this can not be, since one part is tagged as a river,
while other parts shouldn’t be rivers), or the tag values for the multipolygon
must be placed on the relation instead of the outer ways (this is also not done
in the example, since the boundary tag is on the way and not on the relation).
Dies sagt mir als Einsteiger recht wenig. Habe aber trotzdem zwei Boundaries verglichen, wovon eine als river angezeigt wird:
Das ist hier der Fall beim Weg 54643302 südlich Brodenbach.
Merkwürdigerweise ist das aber beim Weg 54643298 nördlich Brodenbach nicht der Fall,
obwohl für ihn die gleichen Rand-Bedingungen gelten (s. u.).
Auch das ist hier der Fall - in beiden Fällen.
Aussage:
Entweder müssen alle Außen-Wege eines Boundary-Polygons gleich getaggt sein - geht hier nicht, da die Land-Grenzen nicht den Tag waterway=river bekommen können, sie sollen ja gerade nicht als river erscheinen.
Oder der Boundary-Tag darf nur in der Relation stehen, aber nicht auf den Außenwegen der Relation.
In meinen Augen hat mkgmap resp. der Entwickler hier die Bedingungen falsch ausgelegt:
Die Bedingung, das alle Außen-Wege absolut identisch getaggt sein müssen, gilt nur, wenn die Relation selbst keine Tags hat!
Die Relation hat Tags - also sollen bei ihrem Rendern die Tags der Wege ignoriert werden!
Stattdessen rendern sie -manchmal-alle Einzel-Tags der Outer-Ways an alle alle Outer-Ways.
Das ist hier definitiv falsch!
Wenn die Relation selber aber bereits als boundary gekennzeichnet ist, dann hat an den outer-ways das boundary Tag nichts mehr zu suchen. Gerade durch so unsauberes Tagging wird es fuer ein Programm halt schwer zu erkennen, was eigentlich gemeint ist.
Da ist mkgmap z.Z. sicherlich noch nicht ganz sauber (ein bekanntes Problem) trotzdem sollte man bei der Relation mal aufraeumen, damit man besser erkennen kann, womit genau mkgmap nicht zurecht kommt.
PS: Man kann fuer die Grenze und den Fluss auch zwei eigene Ways benutzen, die entlang der selben Nodes verlaufen. Ob ein gemeinsamer Way oder zwei getrennte Ways geschickter sind, da gehen OSM-typisch mal wieder die Meinungen auseinander.
Hier nochmals die gefundenen Boundaries, damit mit dem Aufräumen begonnen werden kann. Würde es ja selbst tun. Dafür fehlen mir aber die Kenntnisse bzw. eine genaue Anleitung.
Da kann man dann sich auch gleich zu den Relationen bzw. zu den Mitgliedern durchklicken, und man kann sich auch die Vergangenheit des Elementes angucken.
Aufgrund von de_muur’s Posting habe ich die Links mal quer gecheckt und festgestellt, daß diese nur in Merkaartor funktionieren. Bin stillschweigend davon ausgegangen, daß sie in JOSM, nutze ich so gut wie nie, ebenfalls funktionieren.