Liegt vielleicht an dem area=yes, welches IMHO nicht notwendig ist. Eingeschlossener highway ist per default eine Fläche.
Das area=yes findet man oft auch an landuse amenity Tags.
Siehe Posting #5 und #6
Oder auch an der Relation. Verschiebe die Tags des outer mal an die Relation.
Jetzt sind meine Augen besser geöffnet.
Vielleicht liegt es daran: http://www.openstreetmap.org/browse/way/124468797
die highway=rest_area schließt die Parkplatz-Fläche mit ein. Bei überlagernden Flächen weiß der Renderer wohl nicht, was überdeckt, und das Ergebnis ist ein Zufallsprodukt. Beim kleineren westlichen Parkplatz sowie beim gegenüberliegenden Rastplatz hat es der Zufall gut gemeint.
Ist aber alles eine Vermutung, da ich die render-Regeln von mapnik nicht kenne. Warum z.B. aber die Grasflächen (auch die große nördliche) gezeichnet werden, obwohl sie auch überlagern, bleibt mir mapnik’s Geheimnis…
Lösungsvorschlag:
MP mit outer-inner-outer (letztes für die Grasinseln) oder Parkplatz aus MP rausnehmen und als inner deckungsgleiches “Loch mit nix” zeichnen.
Denkbar wäre auch für mich, eine site-Realition anzulegen, der man das rest_area zuordnet…
mapnik sortiert Flächen gleicher/ähnlicher Art nach deren Grösse. Dabei zeichnet er erst die grossen und dann die kleineren.
(order by …, way_area desc)
Das könnte einiges erklären.
Gruss
Walter
p.s. “Zufälle” gibt es bei Programmen in der Regel nicht. Das ist alles so programmiert.
Über diese Art des Sortierens gab es mal eine heftige Diskussion zur Vermeidung von MP’s. Die hatte ich vom Zaum gebrochen und will sie nicht mehr aufwärmen. Diese Logik ist für mich aber nachvollziehbar.
OT: Nur was passiert, wenn sich Flächen teilweise überlagern?
Da ist ja nur ein landuse Bestandteil der Relation alle anderen und auch die natural nicht. Den Parkplatz würde ich aus dem landuse=residential rausnehmen. Er braucht danach auch nicht der Relation zugefügt werden, IMHO.
Und weshalb sind die Tags für den Golfplatz am outer und an der Relation? Sollten grundsätzlich an der Relation sein. Aus Konsistenzgründen auch bei einem outer.
Sehe gerade in JOSM , was das Problem ist. Bisher hatte ich mir dies mit Merkaartor angeschaut.
Was Du als Roßberg beschreibst, ist laut Bing eine Waldfläche und die wird in Merkaartor auch als solche angezeigt. Deshalb auch mein Hä?
In JOSM dagegen zeigt ein Klick mit der mittleren Maustaste zwei Elemente. Einmal den Wald und dann die gleiche Fläche mit dem Golfplatztagging, was falsch ist. Habe letztere gelöscht.
Jetzt müßte man alles, wie schon angedeutet, in die Relation (1623941) packen. Momentan ist diese leer.
Was mich da noch stört: natural=beach für golfbunker. Könnte man da nicht surface=sand nehmen?
Ahja, vielen Dank. Allerdings wurden die ebenso bezeichneten Wege rechts und links der Brücke dargestellt, nur die Brücke nicht, was reichlich willkürlich ist. Osmarender zeigte beides.
Warnung: Die Gegend ist mit Multipolygonen der übelsten Sorte vermient. Meist 50 bis 100 Elemente. Teilweise bis zu 20 geschlossenen outer Ringe (die eigentlich jede eine eigene MP Relation benötigen würden) und dazu noch einige geschlossene inner Ringe, die jeder Auswerter erst mal dem richtigen outer Ring zuweisen muss. z.B. http://www.openstreetmap.org/browse/relation/1275313 Im JOSM Relation Editor sehen die einzelnen Relationen auf den ersten Blick korrekt aus. Man kann sich leider keinen richtigen Überblick verschaffen, da jeder Weg zu zwei Relationen gehört und JOSM bei der Selektion eines Ways jeweils beide MP-Flächen darstellt.
Wie geht man mit einer solchen Situation am betsten um?
Besagtes Teil ist einmal inner der Relation 1274433 und gleichzeitig ein outer der Relation 1275345, in der hauptsächlich mehrere outer zusammengefaßt sind. Ob dies letzteres glücklich ist?