woran kann es liegen, dass einige Eisenbahntunnel in der Gegend um Saverne im Elsass in Mapnik nicht korrekt dargestellt werden? Bspw. dieser hier. Sie erhalten alle die Darstellung einer normalen Bahnstrecke ohne Tunnel.
Das Tagging der Strecken scheint korrekt zu sein: tunnel=yes und layer=-1. Kann es daran liegen, dass der darüberliegende Wald Teil eines etwas (hust) komplexeren Multipolygons ist?
Oder woran könnte der Fehler sonst liegen?
Wie könnte man die Darstellung korrigieren? Einen Bug für die SlippyMap filen? (Wo?) Oder den Wald ausholzen?
Ich habe die gezeigte Gegend mit josm aufgerufen, den Ausschnitt gespeichert und diese Datei mit meinem eigenen Einstellungen mit mkgmap gerendert. Das Tunnel wird einwandfrei angezeigt. Ich halte es deshalb für wenig wahrscheinlich, daß hier ein Multipolygon stört. Wenn ich spekulieren darf: Ich könnte mir eher vorstellen, daß sich tunnel=yes und Layer=-1 beissen. Ich habe jedoch nicht die Werkzeuge, um das Verhalten in mapnik untersuxchen zu können.
mfg
Nach meinem Verständnis von Mapnik dürfte auch gar nicht interessant sein, ob das was da drüber liegt Wald, Wiese oder Nichts ist. Auch nicht, ob das in Form von Ways oder Multipolygonen gemappt ist. Nur die Tags des Weges bestimmen über dessen Aussehen.
Grüße, Max
PS: Ich hab auch gerade einen Node in den westlichen Tunnel eingefügt, auch nach neu rendern nicht besser geworden…
Das liegt mit ziemlicher Sicherheit an der Relation 1848416, die mit railway=rail, aber natürlich nicht tunnel=yes oder layer=-1 getaggt ist. Die Tags der Relation überschreiben die des Ways, das ist mir bei Bundesstraßen etc. auch schon aufgefallen. Meines Erachtens dürfte hier kein railway, voltage, electrified etc. an die Relation, sondern nur die type=route; route=railway; ref=* usw.
Ich bin aber kein Fachmann für Route-Relations.
An die Relation dürfen alle Tags, die alle Miglieder der Relation gemeinsam haben. Oft lässt man die Tags aber noch an den Membern, weil nicht alle Anwendungen sauber (oder überhaupt) mit Relationen umgehen können (hier railway=rail).
Wenn sich die Tags widersprechen, muss eines gewinnen. Da ist es nachvollziehbar, dass das Tag der “höherwertigen” Klasse Relation zum Zuge kommt.
Ein nicht vorhandener Tag der Relation darf aber niemals einen vorhandenen Tag eines members (tunnel=yes, layer=-1) in der Darstellung überschreiben (quasi löschen). Das ist mir bei Straßenrelationen noch nie aufgefallen. Wenn das bei Mapnik so wäre, wäre das ein eklatanter Bug.
Jup, ich denke das mit der Relation ist es. Ich hatte auch schon mal, das bei dieser Konstellation Bahnsteige mit Schienen als Umriss gerendert wurden, falls sie Mitglied einer railway=rail-Relation waren.
Das Problem liegt weiter unten, schon beim Import: osm2pgsql nimmt die manche Relationen von typ=route in seine Tabelle der Wege mit auf. Da liegt also dann wirklich ein Weg in der Tabelle mit “railway=rail, tunnel=null, layer=null”, der nur an der Id als ehemalige Relation erkennbar ist.
Grüße, Max
Edit: die Relationen —> manche Relationen. Ich bin mir nicht sicher, wovon das abhängt…
Die Vererbung von Eigenschaften ist nicht gemeint, sondern dass “erwachsene” Anwendungen nicht nur die Tags der nodes und ways auswerten, sondern auch noch die Relationen mit “ist Mitglied von”.
.
Das steht gar nicht in Frage, natürlich darf man das. Die “ref=*” von Straßen z.B. steht in der Regel an ways, an sub- und an Master-Relationen. Nur bei Widersprüchen muss sich die Anwendung entscheiden.
Ich kann mich an orange gerenderte highway=primary (die ja eigentlich rot sein sollten) auf osm.org erinnern, wo ein highway=secondary in der Streckenrelation (route=road) stand, was ich für ebenso unsinnig halte wie railway=rail. Die Strecke ist keine Straße, sondern eine übergeordnete Zusammenrottung.
Müsste in dem Fall nicht eher das Tag des “spezielleren” Elements gewinnen? Aber eigentlich sollten meiner Meinung nach nur Tags an die Relation die die Beziehung zwischen den Elementen an sich beschreiben, nicht die für die Eigenschaften der einzelnen Elemente.
An die Relation gehören die Tags, die für diese Gesamtheit charakteristisch sind und bei keinem Mitglied anders sein können (sprich sein sollten), Beispiel Straßen-ref. Nicht an die Relation gehören mMn Tags wie surface=asphalt, auch wenn es davon bei Bundesstraßen vermutlich keine Ausnahme gibt (in anderen Ländern sehr wohl).
In einer perfekten Welt ohne Redundanzen stünde der Tag nur an einer Objektklasse, dann kann es keine Widersprüche geben.
In der nicht ganz so perfekten Welt von OSM habe ich dafür Verständnis, dass jemand beim Klicken auf das Straßenstück sofort die ref sehen will und sich nicht erst die Relationen hochklicken will.
danke für eure Antworten. Da habe ich ja mal wieder was losgetreten…
D.h. wenn man an der Relation das railway=rail wegmacht, müsste es korrekt gerendert werden? (Unabhängig davon, ob dieses Verhalten von Mapnik logisch oder wünschenswert ist) Könnte das bitte mal jemand ausprobieren? Ich kenne mich mit Relationen nicht so aus, und fürchte, was kaputt zu machen…
Habs gemacht: http://www.openstreetmap.org/changeset/19887646
Rendern wird aber dauern, dazu müsste man auch die Geometrie der Gleise anfassen, vom Ändern einer Eigenschaft einer Relation fühlt sich Mapnik nicht betroffen.
