See in MS und BC nicht sichtbar

gpsfred · 2013-09-20 07:32:42

Hallo,

in Geldern gibt es den Holländersee, der aber in MapSource und BaseCamp nicht als See sichtbar ist.

http://www.openstreetmap.org/#map=17/51.50858/6.32679

Ich finde in OSM aber keinen Fehler.

Wer kann da helfen? Was ist falsch?

Last edited by gpsfred (2013-09-20 07:34:01)

maxbe · 2013-09-20 08:27:11

Da ist eine Relation 3179074, die keine Tags hat ausser dem Namen (daher das Label "Holländer See" 500m südlich des Sees). Da ist ein See drin (Weg 22987652) als "inner" und ein Wald (Weg 75698582) als "outer".

In dieser Konstruktion ist die ganze Fläche einschliesslich See ein grosser Wald, nämlich der 75698582. Der See ist Teil dieses Waldes und je nach Laune des Renderers wird der See dann als Wald oder See gemalt.

Richtig fände ich, die Relation mit "forest" zu taggen und den Weg 75698582 ganz ohne Labels zu lassen. Ob die Relation dann noch einen Namen braucht, musst Du wissen (z.B. weil das ganze Gebiet dort "Holländer See" heisst und nicht nur das Wasser).

Grüße, Max

PS: Warum das trotzdem manchmal funtioniert:

* Manche Renderer/Importprogramme vererben in diesem Fall das landuse des outer an die Relation. Dann passt wieder alles
* Manche Renderer malen die Flächen nach Grösse sortiert (kleine Seen liegen "über" grossen Wäldern)
* Manche Renderer malen erst Land, dann darüber die Gewässer
* Zufall

Aber verlassen würde ich mich nicht darauf.

PPS: Über http://www.stupidedia.org/stupi/Holl%C3%A4nder_See als website=* würde ich auch noch mal nachdenken, bei Stupidedia stimmt ja nicht immer alles

gormo · 2013-09-20 08:28:38

Falsch (gewesen) ist auf jeden Fall der Weblink zur stupipedia.

Sonst vllt. irgendwas mit dem Multipolygon? Ich versteh die Teile aber nicht, das muss wer anders sich angucken.

streckenkundler · 2013-09-20 09:00:28

Der Weg 187 783 851 ist eigentlich aber auch ein Inner des Polygons. Das Waldpolygon ist an der Westspitze der o.g. Linie ist eine Lücke.
Ungeachtet dessen sortiere in Relationen die Elemente so, daß das outer-Element im Relationseditor in JOSM ganz unten steht. Ob das einen Effekt im Rendering oder in der weiteren Verarbeitung hat, weiß ich nicht, ich finde es aber logisch.

Sven

EvanE · 2013-09-20 14:24:55

streckenkundler wrote:

Der Weg 187 783 851 ist eigentlich aber auch ein Inner des Polygons. Das Waldpolygon ist an der Westspitze der o.g. Linie ist eine Lücke.
Ungeachtet dessen sortiere in Relationen die Elemente so, daß das outer-Element im Relationseditor in JOSM ganz unten steht. Ob das einen Effekt im Rendering oder in der weiteren Verarbeitung hat, weiß ich nicht, ich finde es aber logisch.

Hallo Sven

Logisch wäre die Outer als bestimmende Elemente zuerst und dann erst die Inner zu sortieren. Fürs Rendering hat das jedoch (zumindest bei Mapnik) keine Auswirkungen. Da man nicht von einer Sortierung ausgehen kann, müssen Renderer in dem Punkt flexibel sein. Lediglich ein Inner, dass jedoch nicht in einem Outer liegt, macht Probleme, da das dann bei Mapnik als Outer dargestellt wird.

Bei mehreren Outer-Ringen kann man auch abschnittsweise sortieren, also Outer und Inner von Outer-Ring 1, dann die von Outer-Ring 2 usw.

Wie auch immer dient die Sortierung vor allem dem menschlichen Bearbeiter und ist/sollte für die Auswertungen unerheblich sein.

JM2C
Edbert (EvanE)

gpsfred · 2013-09-20 17:26:08

streckenkundler wrote:

Der Weg 187 783 851 ist eigentlich aber auch ein Inner des Polygons. Das Waldpolygon ist an der Westspitze der o.g. Linie ist eine Lücke. .
Sven

Ja, sehe ich auch so. Wird in MS aber trotzdem richtig angezeigt!!

maxbe · 2013-09-20 18:02:49

Alles irgendwie verwirrend: Der 187783851 ist deckungsgleich zu 238699018, welcher wiederum neuerdings ein "outer" von 3179074 ist.

GeorgFausB · 2013-09-21 09:42:31

Moin,

rein formal ist es gar nicht so verkehrt, ein Multipolygon-Objekt mit ganz neutralen outer und inner Wegen zu definieren - wenn man denn die inner auch als inner definiert.
Bei zwei veschiedenen inner-Flächen nebeneinander wäre es ja sogar notwendig sinnvoll, wenn man sich an üblichen Standards orientiert.
Auf diese Weise ist das Multipolygon "forest" völlig unabhängig davon, wie der Innenbereich gemappt wird.

Das man einem einzelnen inner gleich auch dessen Inhalt zuweisen kann, ist ja eher der "Sonderfall" und eine Vereinfachung.

Guß
Georg

Announcement

#1 2013-09-20 07:32:42

See in MS und BC nicht sichtbar

#2 2013-09-20 08:27:11

Re: See in MS und BC nicht sichtbar

#3 2013-09-20 08:28:38

Re: See in MS und BC nicht sichtbar

#4 2013-09-20 09:00:28

Re: See in MS und BC nicht sichtbar

#5 2013-09-20 14:24:55

Re: See in MS und BC nicht sichtbar

#6 2013-09-20 17:26:08

Re: See in MS und BC nicht sichtbar

#7 2013-09-20 18:02:49

Re: See in MS und BC nicht sichtbar

#8 2013-09-21 09:42:31

Re: See in MS und BC nicht sichtbar

Board footer