Boundary wird teilweise als Fluß angezeigt

Radeln · 2010-10-04T09:18:49.000Z

Hi,

in Karten, erzeugt mit neueren mkgmap-Versionen (1707 u. 1708), werden in QLandkarte GT einige Boundaries als Fluß angezeigt.

Ursache könnte IMHO sein, daß die im Fluß verlaufende Boundary auch den Tag ‘waterway’ hat. Der Fluß selbst ist getrennt gemappt.

Beispiel: N50° 10.309 E007° 39.949

<?xml version="1.0"?>

EvanE · 2010-10-04T11:11:23.000Z

Radeln:

in Karten, erzeugt mit neueren mkgmap-Versionen (1707 u. 1708), werden in QLandkarte GT einige Boundaries als Fluß angezeigt.
Ursache könnte IMHO sein, daß die im Fluß verlaufende Boundary auch den Tag ‘waterway’ hat. Der Fluß selbst ist getrennt gemappt.
Beispiel: N50° 10.309 E007° 39.949

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.

Edbert (EvanE)

Radeln · 2010-10-04T12:48:34.000Z

EvanE:

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.

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?

EvanE:

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.

Weshalb ist dann der Fluß nochmals getagt?

EvanE · 2010-10-04T14:33:25.000Z

Radeln:

EvanE:

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.

Weshalb ist dann der Fluß nochmals getagt?

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.

Zum Unterschied Fluss und Wasserfläache des Flusses siehe
http://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Driverbank

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

HTH
Edbert (EvanE)

ajoessen · 2010-10-05T06:42:23.000Z

EvanE:

Das verhält sich ähnlich wie mit Straßen (linearer Weg) und Straßen-
flächen. Das wird auch getrennt eingetragen und getaggt.

Wäre ja schön, wenn das Konsens wäre. Wenn du versuchst, eine Wanderwegsroute quer über die Kölner Domplatte zu zeichnen, wirst du dafür gesteinigt

Gruß,
ajoessen

Radeln · 2010-10-05T07:49:52.000Z

EvanE:

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

Jetzt versteh ich gar nichts mehr.

waterway=river gibts doch zweimal. Einmal solo und einmal zusammen mit boundary.

GeorgFausB · 2010-10-05T08:43:04.000Z

Moin,

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 …

EvanE · 2010-10-05T12:57:15.000Z

Radeln:

EvanE:

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

Jetzt versteh ich gar nichts mehr.
waterway=river gibts doch zweimal. Einmal solo und einmal zusammen mit boundary.

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.

Edbert (EvanE)

EvanE · 2010-10-05T13:08:48.000Z

ajoessen:

EvanE:

Das verhält sich ähnlich wie mit Straßen (linearer Weg) und Straßen-
flächen. Das wird auch getrennt eingetragen und getaggt.

Wäre ja schön, wenn das Konsens wäre. Wenn du versuchst, eine Wanderwegsroute quer über die Kölner Domplatte zu zeichnen, wirst du dafür gesteinigt

Hallo ajoessen

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.

Edbert (EvanE)

Radeln · 2010-10-05T14:16:33.000Z

EvanE:

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.

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.

Gruß

EvanE · 2010-10-05T14:45:51.000Z

Radeln:

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.

Hallo Radeln

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.

Edbert (EvanE)

Radeln · 2010-10-08T06:42:17.000Z

EvanE:

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:

http://www.openstreetmap.org/?lat=50.2292&lon=7.4422&zoom=15

Boundary (way_54643302) südlich Brodenbach → river
Boundary (way_54643298) nördlich Brodenbach → kein river

Das Tagging in den zugehörigen Relationen scheint gleich zu sein, oder?

GeorgFausB · 2010-10-08T11:53:53.000Z

Moin,

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?

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

If this is the case, I would guess, that the complete boundary is made up out of
a multipolygon.

Auch das ist hier der Fall - in beiden Fällen.

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

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!

Das Tagging in den zugehörigen Relationen scheint gleich zu sein, oder?

Ja - und kann so bleiben.

Gruß
Georg

chris66 · 2010-10-08T12:10:49.000Z

Moin,
in V1694 gab es einen größeren Umbau bzgl. Multipolygonhandling:

mkgmap-list:

Version 1694 was commited by steve on 2010-09-15 14:11:45 +0100 (Wed, 15 Sep 2010)

This patch enables mkgmap to make use of real multipolygons and of multipolygons where only the members should be tagged (e.g. country boundaries) without any change on the style rules.

It adds a copy of each original line of a multipolygon with an outer role, tags them with the mp tags and an additional mkgmap:stylefilter=polyline. The generated polygon elements are tagged with mkgmap:stylefilter=polygon. The style system evaluates the mkgmap:stylefilter tag and processes such tagged elements only with the appropriate style rules.

The --process-boundary-relations option is no longer neccessary and has been removed.

WanMil

Chris

de_muur · 2010-10-08T12:20:41.000Z

GeorgFausB:

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!

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.

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!

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.

Radeln · 2010-10-08T14:13:23.000Z

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.

http://www.openstreetmap.org/?lat=50.2509&lon=7.4284&zoom=12
→ Relation Gemeinde Hatzenport rel_546634
→ Relation Gemeinde Löf rel_546642
→ Relation Gemeinde Lehmen rel_546640

Neu:
http://www.openstreetmap.org/?lat=50.7548&lon=7.3343&zoom=12
→ Relation Hennef (Sieg) rel_36042

de_muur · 2010-10-08T14:21:22.000Z

Radeln:

http://www.openstreetmap.org/?lat=50.2509&lon=7.4284&zoom=12
→ Relation Gemeinde Hatzenport rel_546634

Nur so nebenbei:
Man kann solche Relationen auch direkt als Link angeben:
http://www.openstreetmap.org/browse/relation/546634

Das funktioniert genauso auch fuer Ways (z.B. http://www.openstreetmap.org/browse/way/54643350)) und Nodes (z.B. http://www.openstreetmap.org/browse/node/323461583)).

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.

Gruss
Torsten

Radeln · 2010-10-08T17:14:46.000Z

Radeln:

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.

http://www.openstreetmap.org/?lat=50.2509&lon=7.4284&zoom=12
→ Relation Gemeinde Hatzenport rel_546634
→ Relation Gemeinde Löf rel_546642
→ Relation Gemeinde Lehmen rel_546640

Neu:
http://www.openstreetmap.org/?lat=50.7548&lon=7.3343&zoom=12
→ Relation Hennef (Sieg) rel_36042

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.

Sorry
Josef

Radeln · 2010-10-08T17:21:38.000Z

de_muur:

Radeln:

http://www.openstreetmap.org/?lat=50.2509&lon=7.4284&zoom=12
→ Relation Gemeinde Hatzenport rel_546634

Nur so nebenbei:
Man kann solche Relationen auch direkt als Link angeben:
http://www.openstreetmap.org/browse/relation/546634

Das funktioniert genauso auch fuer Ways (z.B. http://www.openstreetmap.org/browse/way/54643350)) und Nodes (z.B. http://www.openstreetmap.org/browse/node/323461583)).

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.

Man lernt halt nie aus.
Wo kann man so was nachlesen? Habe im OSM-Wiki auf die Schnelle mal nach ‘Browse’ gesucht und nichts in der Richtung gefunden.

Danke
Josef

Radeln · 2010-10-09T06:13:11.000Z

Problem ist in mkgmap-r1712 behoben.

Gruß
Josef