ÖPNV-Tagging Schema

caka1011 · 2015-07-17 14:42:14

Hallo,

als ich mich neulich mit dem ÖPNV-Tagging Schema in OSM auseinandergesetzt habe,
um zu sehen, wie beispielsweise einzelne Straßenbahnhaltestellen in OSM gepflegt werden,
habe ich gelesen, dass es bereits Änderungen ein paar Mal im Hinblick auf das Pflegeschema gab.

Früher hat man Straßenbahnhaltestellen mit railway = tram_stop angelegt. Nach dem neuen Schema (2014) verwendet
man stattdessen public_transport = stop_position.
Trotzdem ist nicht auszuschließen, dass es durchaus einige Haltestellen gibt, die immer noch mit dem alten tagging-Schema versehen sind.

Habe ich das so richtig verstanden?

Danke!

chris66 · 2015-07-17 14:48:00

Ja, wobei Du im neuen Schema noch das Verkehrsmittel angeben musst, also tram=yes.

Ergänzt wird die Stop-Position noch durch die Position des Wartebereichs (public_transport = platform).

Thoschi · 2015-07-17 15:09:36

caka1011 wrote:

Hallo,
als ich mich neulich mit dem ÖPNV-Tagging Schema in OSM auseinandergesetzt habe,
um zu sehen, wie beispielsweise einzelne Straßenbahnhaltestellen in OSM gepflegt werden,
habe ich gelesen, dass es bereits Änderungen ein paar Mal im Hinblick auf das Pflegeschema gab.
Früher hat man Straßenbahnhaltestellen mit railway = tram_stop angelegt. Nach dem neuen Schema (2014) verwendet
man stattdessen public_transport = stop_position.
Trotzdem ist nicht auszuschließen, dass es durchaus einige Haltestellen gibt, die immer noch mit dem alten tagging-Schema versehen sind.
Habe ich das so richtig verstanden?
Danke!

Ganz genau. Und je nachdem wo Du taggst (welcher Verkehrsverbund), gibt es ggf. noch weitere Besonderheiten, die auf den jeweiligen Wiki-Seiten für den betreffenden Verbund dokumentiert sein sollten.

Nakaner · 2015-07-17 16:29:47

caka1011 wrote:

Früher hat man Straßenbahnhaltestellen mit railway = tram_stop angelegt. Nach dem neuen Schema (2014) verwendet
man stattdessen public_transport = stop_position.
Trotzdem ist nicht auszuschließen, dass es durchaus einige Haltestellen gibt, die immer noch mit dem alten tagging-Schema versehen sind.

railway=tram_stop/halt/station/… ist kein veraltetes Tagging, sondern mittlerweile Teil des Eisenbahn-Infrastrukturtaggings. Idealerweise existiert pro Haltestelle nur ein Node mit diesem Tag. Bei Straßenbahnhaltestellen, bei denen die Bahnsteige/Haltestellenschilder beider Richtungen weit auseinander liegen, können es auch zwei Nodes sein. Dazu gibt es (bei allen schienengebundenen Verkehrsmitteln) railway=stop, welches in Ergänzung zu public_transport=stop_position Haltepositionen kennzeichnet.

jlcod · 2015-07-17 17:11:04

wo wir grad wieder bei PTv2 sind, ich traue mich ja fast nicht mehr dran, nur hier https://www.openstreetmap.org/relation/3060172 waren viele landuse=... in der pt-Relation, was ich so noch nie gesehen habe. daher habe ich etwas "aufgeräumt"... Stop positions der Bahn fehlen noch, aber die weiß ich nicht auswendig, und sie sind auch verschieden, je nachdem wie viele Fahrzeuge (1-3) aneinander gehängt sind. Fahrradparkplätze, Mülleimer etc. sind auch noch nicht drin, bekommen die ne role?
Frage, ist das halbwegs korrekt oder hab ich wieder Mist gemacht? Sind die landuses in der stop_area vll doch korrekt?
komme mit dem wiki nicht klar.

Thoschi · 2015-07-17 17:27:35

jlcod wrote:

Fahrradparkplätze, Mülleimer etc. sind auch noch nicht drin, bekommen die ne role?
Frage, ist das halbwegs korrekt oder hab ich wieder Mist gemacht? Sind die landuses in der stop_area vll doch korrekt?

Landuses gehören da m.E. nicht rein, habe ich noch nie von gehört.
Mülleimer, Fahrradparkplätze etc bekommen keine rolle.

Nakaner · 2015-07-17 18:03:50

Hallo,

jlcod wrote:

wo wir grad wieder bei PTv2 sind, ich traue mich ja fast nicht mehr dran, nur hier https://www.openstreetmap.org/relation/3060172 waren viele landuse=... in der pt-Relation, was ich so noch nie gesehen habe.

Das ist gleichzeitig eine Betriebsstellenrelation (wegen railway=facility), die darf dann auch landuse=railway-Flächen referenzieren. Dadurch gibt man an, wie weit der betreibliche Bahnhof reicht (bis zum Einfahrsignal). Signale sind auf der Kraichtal- und Katzbachbahn gemappt.

In Ubstadt Ort hatte rayquaza damals noch die Fläche der Ausweichanschlussstelle Ubstadt Mülldeponie als Mitglied mit der Rolle "part" in die Relation aufgenommen, da diese ein Teil des betrieblichen Bahnhofs Ubstadt Ort ist (Ausfahrtsignal P1 von Ubstadt Ort Richtung Bruchsal steht erst dort, die Signale am Bahnsteig sind Zwischensignale – aber das ist Hardcore-Signalmapping). Bezüglich des Mappens von Bahnhofsteilen (Ubstadt Mülldeponie ist ein Bahnhofsteil von Ubstadt Ort) gibt es noch keinen Konsens, rayquaza hat es vermutlich irgendwie gemappt – er ist gelegentlich seiner Zeit allgemein etwas voraus (z.B. railway=axle_counter ).

Bei "normalen" Bahnhöfen, die keine Bahnhofsteile haben, ist die Vereinigung von Betreibsstellen- und Stop-Area-Relation in meinen Augen in Ordnung, da man sich so das doppelte Führen der Relation sparen kann. Bei "komplizierteren" Bahnhöfen (also z.B. Ubstadt Ort mit Bhf.-Teil Ubstadt Mülldeponie, Bretten Bahnhof mit Bahnhofsteil Bretten Rechberg und Diedelsheim oder Köln Hbf mit Bahnhofsteilen Köln Messe/Deutz (S-Bahn), Köln Betriebsbahnhof und Köln Hansaring) ist das doppelte Führen (getrennte Relationen jedoch sinnvoller). Außerdem enthält die Stop-Area-Relation von Ubstadt Ort auch eine Bushaltestelle.

Ich habe diese Trennung jetzt in Ubstadt Ort vollzogen und auch sonst ein klein wenig aufgeräumt (railway=station/halt/service_station/freight_station/spur_junction/junction taggen wir nicht mehr an Flächen – rayquaza sieht das mittlerweile auch so).

Die Haltepositionen habe ich jetzt in Ubstadt Ort auf Basis der schon vorhandenen Ne5-Tafeln gemappt. Welche Routenrelation welches Gleis benutzt, kann ich nicht sagen, da ich keine Ortskenntnis habe (in den nächsten 1 1/2 Wochen habe ich nicht die Zeit, um kurz einen Ausflug mit dem Semesterticket nach Ubstadt zu machen).

jlcod wrote:

daher habe ich etwas "aufgeräumt"... Stop positions der Bahn fehlen noch, aber die weiß ich nicht auswendig, und sie sind auch verschieden, je nachdem wie viele Fahrzeuge (1-3) aneinander gehängt sind.

Die Halteposition setzt man gewöhnlicherweise an die Mitte des kürzesten eingesetzten Zuges. In Ubstadt sind auch die Haltetafeln (Signal Ne5) erfasst. Das sind die H-Tafeln, die die Position der Zugspitze angeben. Du kannst in JOSM den Mappaint-Stil (Einstellungen -> Koordinatengitter-Symbol -> Mappaint-Style, dann "OpenRailwayMap signalling layer" zu deinen Stylen hinzufügen und aktivieren), dann wird in JOSM ein Icon dafür gerendert. Anhand der H-Tafeln kann man die Halteposition ableiten. Manchmal gibt es mehrere Tafeln (für verschiedene Zuglängen), dann wird mit railway:signal:stop:caption=* der Zusatztext (bei der AVG meist "1", "2", "GT8+GT6") getaggt.

jlcod wrote:

Fahrradparkplätze, Mülleimer etc. sind auch noch nicht drin, bekommen die ne role?

Die bekommen keine Rolle, ich würde sie auch gar nicht in die Relation aufnehmen. Wenn die Stop-Area-Relation eine Betriebsstellenrelation ist, ist es legitim (sehr empfohlen) auch den railway=station/halt-Node mit aufzunehmen (leere Rolle). Ansonsten braucht der nicht in der Stop-Area-Relation zu sein.

Viele Grüße

Michael

jlcod · 2015-07-17 18:25:49

Hallo Michael,

Danke für die Erklärung, da hab ich mir wohl wie komplizierteste Relation zum Bearbeiten gesucht...
und hab mit meinem letzten Changeset aus versehen vielleicht deine Änderungen nochmal geändert, sorry! da waren wir wohl gleichzeitig am Bearbeiten. Kannst du bei Bedarf revertieren.

Edit:

Nakaner wrote:

Welche Routenrelation welches Gleis benutzt, kann ich nicht sagen

Die Gleisbenutzung ist nicht-trivial. Bin dort vor einigen Jahren noch täglich gependelt und jetzt noch manchmal dort, konnte aber keine Regelmäßigkeit erkennen. Mal hält eine ankommende Bahn auf dem einen, mal auf dem anderen Gleis, scheinbar unabhängig von Richtung und Linie. Lediglich zeitlich gibts Regelmäßigkeiten, die Bahn um 08:xx hält dann immer an Bahnsteig y. Nur die Platform an der Bushaltestelle wird meines Erachtens nicht benutzt, außer während bestimmten Baustellensituationen, etc.

Last edited by jlcod (2015-07-17 18:38:36)

JanTH · 2015-07-17 19:27:08

Theoretisch sollte normalerweise Gleis 1 Richtung Menzingen/Odenheim und Gleis 2 Richtung Karlsruhe genutzt werden, die Standanforderungen für den Selbststellbetrieb sind auch darauf ausgelegt. In der Praxis möchte man vielleicht noch vermeiden, dass sich S31 und S32 am anderen Bahnhofsende nochmal gegenseitig behindern, und vertauscht dann die Gleisbelegung.

Weide · 2015-07-18 08:47:00

caka1011 wrote:

Früher hat man Straßenbahnhaltestellen mit railway = tram_stop angelegt. Nach dem neuen Schema (2014)...

2011

caka1011 wrote:

...verwendet
man stattdessen public_transport = stop_position.

Nicht "statt dessen". Bei Haltestellen akzeptiert das neue System die alten Tags als voll und ganz gültig! Sie können auch in Relationen des neuen Systems problemlos benutzt werden. Man darf also ohne Probleme einen Node neben der Straße mit highway=bus_stop als "platform" oder einen Node der Straße als "stop" in eine PTv2-Route eintragen.

jlcod wrote:

...hier https://www.openstreetmap.org/relation/3060172

Was mir da zuerst auffällt, ist die falsche Nutzung von "public_transport=station". Damit wird die Bahnhofsfläche aus Passagiersicht angegeben. Mit "building" gibt man dabei nur an, ob die Fläche mit der Bahnhofsgebäudefläche übereinstimmt -- Werte sind daher "yes" oder "no". Mit Dächern auf einzelnen Bahnsteigen oder -- leider sehr häufig -- mit "railway=station"-Nodes hat das überhaupt nichts zu tun.

Nakaner wrote:

Bei "normalen" Bahnhöfen, die keine Bahnhofsteile haben, ist die Vereinigung von Betreibsstellen- und Stop-Area-Relation in meinen Augen in Ordnung, da man sich so das doppelte Führen der Relation sparen kann.

Das würde ich nicht tun. Es ist besser, wenn Fehler gemeldet werden. Jede Rolle außer "stop", "platform" und "" in einer stop_area-Relation ist ein Fehler und sollte vom Editor gemeldet werden.

jlcod wrote:

Mal hält eine ankommende Bahn auf dem einen, mal auf dem anderen Gleis, scheinbar unabhängig von Richtung und Linie. Lediglich zeitlich gibts Regelmäßigkeiten, die Bahn um 08:xx hält dann immer an Bahnsteig y. Nur die Platform an der Bushaltestelle wird

Ich würde lokale Gleiszuordnungsvarianten nicht erfassen. PTv2 ermöglicht das nur, wenn man jede Routen-Variante als extra Relation erfasst. Bei drei Gleisen verdreifacht man so die Anzahl der Relationen. Wenn das bei einem anderen Bahnhof der Strecke ebenfalls so ist, dann haben wir dann neunmal so viele Relationen usw.! PTv2 ist für lokale Varianten einfach ungeeignet. (Das war einer der Gründe für meinen Vorschlag eines Nachfolgesystems.)

Weide

Last edited by Weide (2015-07-18 08:47:27)

jlcod · 2015-07-18 18:33:14

Weide wrote:

Was mir da zuerst auffällt, ist die falsche Nutzung von "public_transport=station". Damit wird die Bahnhofsfläche aus Passagiersicht angegeben. Mit "building" gibt man dabei nur an, ob die Fläche mit der Bahnhofsgebäudefläche übereinstimmt -- Werte sind daher "yes" oder "no". Mit Dächern auf einzelnen Bahnsteigen oder -- leider sehr häufig -- mit "railway=station"-Nodes hat das überhaupt nichts zu tun.

okay, danke, die public_transport=station hatte ich reingemacht, weil JOSM gemeckert hat (Warnung: Problem bei Rollenprüfung, Rollenmitglied stimmt nicht mit dem Ausdruck amenity || public_transport=station in der Vorlage Stop Area überein).
Um es zu beheben würde ich die public_transport=station an der railway=station node und am building=roof löschen. Ich gehe davon aus, dass das bulding=roof trotz Warnung in der relation bleibt? Für eine amenity=shelter, shelter_type=public_transport wäre es etwas groß.

Weide · 2015-07-19 07:43:45

jlcod wrote:

Ich gehe davon aus, dass das bulding=roof trotz Warnung in der relation bleibt?

Nach PTv2 gehört es nicht rein. (Andererseits entspricht es natürlich dem shelter=yes am Steig und gehört im Gegensatz zum Bäcker im Bahnhof eigentlich dazu...)

Wir haben aber eigentlich auch nichts davon, wenn es drin ist: Die Frage, ob man da bei Regen nass wird, kann man so oder so nicht aus den miteinander verknüpften Daten beantworten. Stop_areas sind optional und shelter=yes an Einzelobjekten entfallen, wenn das Ding selbst gemappt wird. Man muss so oder so auf der Karte die Umgebung ansehen.

Weide

rayquaza · 2015-07-20 15:33:56

Nakaner wrote:

[Bft] rayquaza hat es vermutlich irgendwie gemappt – er ist gelegentlich seiner Zeit allgemein etwas voraus

Ja, leider

Nakaner wrote:

Die bekommen keine Rolle, ich würde sie auch gar nicht in die Relation aufnehmen.

Weide wrote:

Nach PTv2 gehört es nicht rein.

Dito. Bei diversen Hauptbahnhöfen wären die Relationen sonst *sehr* unübersichtlich Ich habe an RUO nochmal etwas "herumgepfuscht", diese Objekte aber erstmal dringelassen. Im Proposal steht shelter und bench auch als Beispiel…

Nakaner wrote:

Wenn die Stop-Area-Relation eine Betriebsstellenrelation ist, ist es legitim (sehr empfohlen) auch den railway=station/halt-Node mit aufzunehmen (leere Rolle). Ansonsten braucht der nicht in der Stop-Area-Relation zu sein.

Wie würde man dann zur Betriebsstelle die Verkehrsstation finden oder andersrum?

Announcement

#1 2015-07-17 14:42:14

ÖPNV-Tagging Schema

#2 2015-07-17 14:48:00

Re: ÖPNV-Tagging Schema

#3 2015-07-17 15:09:36

Re: ÖPNV-Tagging Schema

#4 2015-07-17 16:29:47

Re: ÖPNV-Tagging Schema

#5 2015-07-17 17:11:04

Re: ÖPNV-Tagging Schema

#6 2015-07-17 17:27:35

Re: ÖPNV-Tagging Schema

#7 2015-07-17 18:03:50

Re: ÖPNV-Tagging Schema

#8 2015-07-17 18:25:49

Re: ÖPNV-Tagging Schema

#9 2015-07-17 19:27:08

Re: ÖPNV-Tagging Schema

#10 2015-07-18 08:47:00

Re: ÖPNV-Tagging Schema

#11 2015-07-18 18:33:14

Re: ÖPNV-Tagging Schema

#12 2015-07-19 07:43:45

Re: ÖPNV-Tagging Schema

#13 2015-07-20 15:33:56

Re: ÖPNV-Tagging Schema

Board footer