Mapnik rendert Parkplatz nicht

KaChing_Cacher · 2011-08-09T02:52:56.000Z

Kann sich jemand von euch erklären, warum Mapnik den Parkplatz unter der Beschriftung “Engelberg” nicht rendern will?
http://www.openstreetmap.org/?lat=48.808783&lon=9.048539&zoom=18&layers=M

Der Weg ist geschlossen und Fehler im Multipolygon hat’s auch keine.

Gruß, KaChing_Cacher

hurdygurdyman · 2011-08-09T03:13:58.000Z

KaChing_Cacher:

Kann sich jemand von euch erklären, warum Mapnik den Parkplatz unter der Beschriftung “Engelberg” nicht rendern will?
http://www.openstreetmap.org/?lat=48.808783&lon=9.048539&zoom=18&layers=M

Der Weg ist geschlossen und Fehler im Multipolygon hat’s auch keine.

Gruß, KaChing_Cacher

Osmarender zeigt ihn.
Ansonsten: keine Ahnung…

Radeln · 2011-08-09T05:24:29.000Z

KaChing_Cacher:

Kann sich jemand von euch erklären, warum Mapnik den Parkplatz unter der Beschriftung “Engelberg” nicht rendern will?
http://www.openstreetmap.org/?lat=48.808783&lon=9.048539&zoom=18&layers=M

Der Weg ist geschlossen und Fehler im Multipolygon hat’s auch keine.

Gruß, KaChing_Cacher

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.

Gruß

hurdygurdyman · 2011-08-09T06:13:24.000Z

hurdygurdyman:

KaChing_Cacher:

Kann sich jemand von euch erklären, warum Mapnik den Parkplatz unter der Beschriftung “Engelberg” nicht rendern will?
http://www.openstreetmap.org/?lat=48.808783&lon=9.048539&zoom=18&layers=M

Der Weg ist geschlossen und Fehler im Multipolygon hat’s auch keine.

Gruß, KaChing_Cacher

Osmarender zeigt ihn.
Ansonsten: keine Ahnung…

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…

aighes · 2011-08-09T07:07:52.000Z

Der Parkplatz gehört nunmal aber auch zur rest_area dazu. Von daher wäre ein MP falsch.

@Radeln: Ein geschlossener highway wird eben nicht automatisch zur Fläche, nur weil er geschlossen ist.

Radeln · 2011-08-09T07:21:20.000Z

aighes:

Der Parkplatz gehört nunmal aber auch zur rest_area dazu. Von daher wäre ein MP falsch.

@Radeln: Ein geschlossener highway wird eben nicht automatisch zur Fläche, nur weil er geschlossen ist.

Hast ja recht. Sorry.

wambacher · 2011-08-09T07:43:02.000Z

hurdygurdyman:

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

moin moin,

ein wenig bin ich in mapnik eingestiegen:

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.

hurdygurdyman · 2011-08-09T08:04:57.000Z

wambacher:

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

mdk · 2011-08-09T13:59:02.000Z

Hi,

ich habe hier ein ähnliches Problem:
http://www.openstreetmap.org/?lat=47.456859&lon=8.713111&zoom=18&layers=M
Diesmal gibt es Probleme mit Wald und Golfplatz. Je nach Zoomlevel und Anteil der beiden Flächen auf einem Tile gewinnt mal der eine, mal der andere

Viele Grüsse

mdk

Radeln · 2011-08-09T14:17:13.000Z

mdk:

Hi,

ich habe hier ein ähnliches Problem:
http://www.openstreetmap.org/?lat=47.456859&lon=8.713111&zoom=18&layers=M
Diesmal gibt es Probleme mit Wald und Golfplatz. Je nach Zoomlevel und Anteil der beiden Flächen auf einem Tile gewinnt mal der eine, mal der andere

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.

Gruß

hurdygurdyman · 2011-08-09T17:45:41.000Z

Radeln:

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

Gruß

Wenn der als inner getaggte Rossberg nicht zum Golfplatz gehört, ist das tagging aber nur am outer korrekt. Dann müsste es an der relation weg.

Radeln · 2011-08-09T17:57:53.000Z

hurdygurdyman:

Radeln:

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

Gruß

Wenn der als inner getaggte Rossberg nicht zum Golfplatz gehört, ist das tagging aber nur am outer korrekt. Dann müsste es an der relation weg.

Hä? Der Roßberg ist doch der 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?

Gruß

MattGPS · 2011-08-09T22:04:44.000Z

Mapnik scheint auch ein Brücklein nicht rendern zu wollen: http://www.openstreetmap.org/?lat=48.820673&lon=9.94086&zoom=18

KaChing_Cacher · 2011-08-10T00:26:30.000Z

MattGPS:

Mapnik scheint auch ein Brücklein nicht rendern zu wollen: http://www.openstreetmap.org/?lat=48.820673&lon=9.94086&zoom=18

Da stand ja auch tracktype=3, was tracktype=grade3 heißen muss. Deshalb wird’s wohl nicht gerendert haben.
Hab’s gleich mal korrigiert.

MattGPS · 2011-08-10T05:44:29.000Z

KaChing_Cacher:

Da stand ja auch tracktype=3, was tracktype=grade3 heißen muss. Deshalb wird’s wohl nicht gerendert haben.
Hab’s gleich mal korrigiert.

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.

mdk · 2011-08-10T06:51:14.000Z

@Radeln
Autsch - dass mit den zwei identischen Wegen hätte ich auch sehen sollen. Habe gerade gestern einen solchen Fehler wo anders behoben.

Aber einen hätte ich noch. Da habe ich gestern einige Zeit drüber gebrütet und dann aufgegeben:
OSM Inspector meldet einen inner_outer_mismatch: http://tools.geofabrik.de/osmi/?view=multipolygon&lon=7.06444&lat=46.15066&zoom=16&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags
Wobei aber der inner Way (ebenso wie im Relation Editor von JOSM) geschlossen dargestellt wird.
Der Relation Browser von OSM zeigt jedoch eine Lücke im inner Way: http://www.openstreetmap.org/browse/relation/1274433
Wobei aber der fehlende Path Teil der Relation mit Rolle inner ist: http://www.openstreetmap.org/browse/way/61649011

Warum meckert der OSM Inspector hier?

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?

Grüsse

mdk

chris66 · 2011-08-10T06:59:11.000Z

Radeln:

Was mich da noch stört: natural=beach für golfbunker. Könnte man da nicht surface=sand nehmen?

Könnte man, wird aber nicht gerendert.

Mein Vorschlag: natural=sand + golf=bunker

Chris

Radeln · 2011-08-10T08:55:52.000Z

mdk:

@Radeln
Autsch - dass mit den zwei identischen Wegen hätte ich auch sehen sollen. Habe gerade gestern einen solchen Fehler wo anders behoben.

Aber einen hätte ich noch. Da habe ich gestern einige Zeit drüber gebrütet und dann aufgegeben:
OSM Inspector meldet einen inner_outer_mismatch: http://tools.geofabrik.de/osmi/?view=multipolygon&lon=7.06444&lat=46.15066&zoom=16&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags
Wobei aber der inner Way (ebenso wie im Relation Editor von JOSM) geschlossen dargestellt wird.
Der Relation Browser von OSM zeigt jedoch eine Lücke im inner Way: http://www.openstreetmap.org/browse/relation/1274433
Wobei aber der fehlende Path Teil der Relation mit Rolle inner ist: http://www.openstreetmap.org/browse/way/61649011

Warum meckert der OSM Inspector hier?

Was ich auf die Schnelle festgestellt habe:

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?

Jetzt geh ich erst mal Radeln.

Gruß

Radeln · 2011-08-10T08:56:44.000Z

chris66:

Radeln:

Was mich da noch stört: natural=beach für golfbunker. Könnte man da nicht surface=sand nehmen?

Könnte man, wird aber nicht gerendert.

Mein Vorschlag: natural=sand + golf=bunker

Chris

+1
Manchmal sieht den Wald vot lauter Bäumen sicht mehr.