[PT] Bahnsteige Hamm

Mit service=paved ist vermutlich surface=paved gemeint, oder?

https://www.openstreetmap.org/way/227356793

Grüße
Chris

Ja, so richtig viel hat FrauHoth nicht gemacht, da ist ein Verdreher ziemlich wahrscheinlich, aber sie hat mir JOSM gearbeitet.

Das Tag service=paved ist 275 mal weltweit eingesetzt worden, immer gerne mit highway= in Kombination.

Christoph

Ok, dann tagg ich mal um.
Hätte ja sein können dass es irgend sonn Spezialtag von PublicTransport V2.0.16 ist.
:sunglasses:

Zwei Fragen:

  1. Seit wann werden denn die Bahnsteige geteilt? Habe ich vorher noch nie gesehen :smiley:
  2. Ich dachte, wir taggen nur positive Dinge, wenn diese zusätzlich vorhanden sind: tactile_paving = no

zu 1. Mich hatte da mal jemand aus Leipzig angesprochen und gemeint das wäre eine gute Lösung. Aber 2012 war wohl jemand anderer Meinung und hat dort Bahnsteige neu erfasst.
In Dresden sind die Bahnsteige als Multipolygon erfasst, damit klar ist welche Seite welche Nummer hat. Wenn man das wie in Leipzig Hbf erfassen würde, wäre unklar auf welcher Seite welcher Bahnsteig wäre.
zu 2. Schon oneway=no wäre da ja eine Ausnahme!

Ein fehlendes tactile_paving kann auch bedeuten, dass diese Eigenschaft noch nicht gemappt wurde. tactile_paving=no sagt dagegen, dass sie gemappt wurde und nicht vorhanden ist.

Ein Blinden-Navi kann so eine Warnung ausgeben.

Hallo,

Das war so ca. 2012 mal arg in Mode. Ich habe das auch (z.B. in Dessau Hbf) gemacht. Mittlerweile schäme ich mich fast dafür. Es spricht meistens nichts für eine Trennung, da die Bahnsteige nicht baulich getrennt sind.

Mentz DV wollte anfangs (könnt ihr auf talk-de nachlesen) auch die Bahnsteige in der Mitte spalten. Man hat Mentz DV dann aber von dieser Idee abgebracht.

Anders als Einbahnstraßen und Durchfahrtsverbote ist der Anteil der Bahnsteige ohne taktilem Pflaster oder Unterstand (shelter=*) deutlich höher.

Dresden ist derzeit kein Vorbild.

  1. An den Multipolygonen steht ref=“11, 12”. ref=“11;12” wäre richtig.
  2. Die Bahnsteigkanten (gleisseitig) sind nur mit name=“Dresden Hbf, Bahnsteig 14” getaggt. Das ist kein guter Stil. Besser wäre ref=14 + railway=platform_edge. Letzeres ist nirgendwo definiert. Das Schema nenne ich “Euskirchener Schema”, da ich es nach dem OpenRailwayMap-Mappingwochenende in Köln im Juli 2014 dort zuerst angewendet habe. Das Schema habe ich auch in Schwerin Hbf angewendet.

Das Schema ist mit den Mentz’schen Bahnsteig-Multipolygonen (zu bewundern in Stuttgart und anderswo) kompatibel.

Gleisnummern finden Datennutzer übrigens auch noch an anderen Stellen:

  • auf dem Gleis als railway:track_number=* (im OpenRailwayMap-Schema dokumentiert)

  • auf der Halteposition als local_ref=* an public_transport=stop_position + railway=stop (nicht dokumentiert, in Stuttgart gebräuchlich)

Das Schema lässt sich um Bahnsteigabschnitte (A, B, C, …) erweitern, indem man einfach Nodes mit entsprechenden Tags auf die Bahnsteigkante setzt.

Falls jetzt noch jemand fragt, wie man die genaue Trennstelle zwischen Gleis 4a und 4b ermittelt. Das kann man sehr gut. An dieser Stelle stehen Rangiersignale, die Halt (ein oder zwei rote Lichter) zeigen, wenn der Zug nur zur Hälfte ins Gleis einfährt, weil es doppelt belegt ist.

Viele Grüße

Michael

Antwort akzeptiert :slight_smile:

Und wie soll man jetzt vorgehen? Ich lese immer wieder, dass die Bahnsteigkante die Information tragen soll?

Ja. Wenn du keine Lust hast, taggst du wie bisher den gesamten Bahnsteig als Fläche, der ref=* usw. trägt. Wenn du mehr Zeit hast, dann mappst du ihn als Multipolygon. Das Multipolygon trägt dann zur Abwärtskompatibilität ref=*, welches noch einmal an den Bahnsteigkanten zu finden ist.

Sorry für die Nachfrage:
a) virtuell in der Mitte trennen, beiden Seiten einen Ref-Tag geben, einzeln komplett durchtaggen und den gleisseitigen Bahnsteigkanten einen Ref-Tag geben,
b) virtuell in der Mitte trennen, beiden Seiten einen Ref-Tag geben, dem Multipolgyon die Eigenschaften geben und die Bahnsteigkkanten wie a behandeln,
c) den Bahnsteigkörper zerlegen, die Bahnsteigkanten mit einem Ref-Tag versehen und als outer-Multipolygon zusammenbauen?

Im Endeffekt müssten ja alle 3 Varianten ein outer-Multipolygon ergeben? Ich dachte immer, das wäre ungewollt?