[OSM-Dresden] ÖPNV Dresden: Bushaltestellen und Busrouten einheitlich laut public_transport Schema bearbeiten

[Michael Reichert]

Hallo Wolfgang,

Am 2015-02-12 um 11:50 schrieb Wolle DD:
> *1.2. Wartebereich*
> 
> Der Wartebereich kann sich von Haltestelle zu Haltestelle baulich sehr
> unterscheiden. Deswegen gibt es auch unterschiedliche Möglichkeiten ihn zu
> taggen. Als Punkt (node), als Linie (way) oder Fläche (area=yes). Ich bin
> kein Fan der "Flächenmalerei" (mehr), darum empfehle ich nur mit Punkt und
> Linie zu arbeiten.
> 
> Ein Punkt ist empfohlen, wenn NUR ein Haltestellenschild vorhanden ist. Ein
> Abfalleimer, eine Sitzbank oder ein Unterstand spielen keine Rolle. Er
> sollte auf den Fußweg in Höhe des Haltestellenschilds platziert werden.
> Eine Linie sollte unbedingt verwendet werden, wenn MINDESTENS eines der
> folgenden baulichen Merkmale erkennbar sind:
> 
> - vorhandenes "Busbord", also eine Erhöhung der Bordsteinkante für
> barrierefreien oder -armen Zugang (siehe
> http://de.wikipedia.org/wiki/Busbord )
> - sogenanntes "Blindenpflaster" (ertastbares, meist weißes Noppen- oder/und
> Streifenpflaster)
> - baulich abgesetzte Haltestellen (auch Einbuchtungen neben der Straße)
> 
> Die Linie sollte entlang der Straßen - Kante des Busbords / des
> Blindenpflasters gezogen werden.
> 
> für Wartebereich als Punkt:
> 
>    - public_transport = platform >> notwendig
>    - name = * >> nicht notwendig wenn eine Haltestellen - Relation
>    existiert oder erstellt wird (kann aber getaggt werden)
>    - waste_basket = yes / no >> bei Vorhandensein empfohlen, sonst möglich
>    - bench = yes / no >> bei Vorhandensein empfohlen, sonst möglich
>    - shelter = yes / no >> bei Vorhandensein empfohlen, sonst möglich
> 
> Teilweise wird an das veraltete und im public transport Schema nicht mehr
> verwendete highway=bus_stop festgehalten. Wenn gewünscht, kann es an den
> Punkt ergänzt werden. Der Name sollte dann auch getaggt werden.

In Deutschland hat sich das im April 2011 beschlossene Public Transport
Proposal (aka PTv2) durchgesetzt. highway=bus_stop wird noch verwendet,
um abwärtskompatibel zu sein, damit auch Datennutzer, die noch keine
PT-Tags auswerten, Bushaltestellen finden. Mit der Umstellung einer
Route auf PTv2 mappt man die alten Tags nur für Zwecke, bei denen man
keine Routenauswertung benötigt (Rendering, Standortanalyse, POI-Suche, …).

> Der Wartebereich als Linie:
> 
>    - public_transport = platform >> notwendig
>    - name = * >> nicht notwendig wenn eine Haltestellen - Relation
>    existiert oder erstellt wird (kann aber getaggt werden)
>    - foot = yes >> empfohlen
>    - wheelchair = yes / limited / no >> empfohlen
>    - tactile_paving = yes / no >> bei Vorhandensein vom Blindenpflaster
>    empfohlen, sonst möglich
>    - waste_basket = yes / no >> bei Vorhandensein empfohlen, sonst möglich
>    - bench = yes / no >> bei Vorhandensein empfohlen, sonst möglich
>    - shelter = yes / no >> bei Vorhandensein empfohlen, sonst möglich
> 
> Wenn highway=bus_stop verwendet wird, dann sollte der Tag als Punkt auf der
> Linie in Höhe des Haltestellenschilds platziert werden und in die Busroute
> eingebunden werden (siehe weiter unten).

In Routen, die nach PTv2 erfasst sind, wird werden nur die
Stop-Positions mit der Rolle stop und die Plattformen mit der Rolle
platform eingebunden. Wenn die Plattform als Linie gemappt ist, dann wir
die Linie in die Relation aufgenommen und nicht ein Punkt von ihr.

Einer PTv2-Route ist egal, wo Nodes mit highway=bus_stop existieren.

> *2. Haltestellen - Relation*
> 
> Der Haltepunkt und der Wartebereich aller Bestandteile der Bushaltestelle
> sollten in einer Relation zusammengefasst werden.
> 
>    - type = public_transport >> notwendig
>    - public_transport = stop_area >> notwendig
>    - name = * >> dringend empfohlen
>    - network = * >> (der Name des Verkehrsverbundes) empfohlen
>    - operator = * >> (der Betreiber der Haltestelle) empfohlen
> 
> Der Haltepunkt erhält in der Relation die Rolle "stop" und der
> Wartebereich, egal ob Punkt oder Linie, die Rolle "platform". Wenn
> highway=bus_stop verwendet wird, erhält dies auch "platform" als Rolle.

highway=bus_stop hat mit PTv2 nichts zu tun. Man kann ihn die
Stop-Area-Relation aufnehmen, wenn der Node gleichzeitig mit
public_transport=* getaggt ist (bitte aber deswegen nicht für ein und
denselben Halteplatz zwei Objekte mit public_transport=platform mappen!).

> *3. Busroute*
> 
> Der Hin- und Rückweg einer Buslinie sollte getrennt in einer Relation und
> dann in einer Masterroute - Relation zusammen gefasst werden.
> 
>    - type = route >> notwendig
>    - route = bus >> notwendig
>    - name = * >> notwendig in folgender Weise: "Verkehrsmittel Nr:
>    Startname => Ziel"; als Beispiel: "Bus 85: Löbtau => Striesen"
>    - ref = * >> (die Nummer der Linie) empfohlen
>    - from = * >> (die Starthaltestelle) empfohlen
>    - to = * >> (die Zielhaltestelle) empfohlen
>    - network = * >> (der allgemein bekannte Name (die Abkürzung) des
>    Verkehrsverbundes) empfohlen
>    - operator = * >> (der allgemein bekannte Name (die Abkürzung) des
>    Verkehrsbetriebes) empfohlen
> 
> Die Route sollte lückenlos erfasst werden. Sie sollte aus folgenden Teilen
> bestehen: Starthaltestelle - Weg - Haltestelle - Weg - ... - Weg -
> Zielhaltestelle

Das ist falsch. Richtig wäre:
Halteposition1
Wartebereich1
Halteposition2
Wartebereich2
Halteposition3
Wartebereich3
Halteposition4
Wartebereich4
Fahrweg1
Fahrweg2
Fahrweg3

Haltepositionen bekommen die Rolle stop, Wartebereiche die Rolle
platform und Fahrwege bekommen keine (also eine leere) Rolle. Ich weiß
nicht, wo du diese falsche Sortierreihenfolge her hast. Interessieren
würde es mich nämlich, damit ich die entsprechende Stelle im Wiki
aufräumen kann.

Bei Routen bitte zur Kennzeichnung noch public_transport:version=2
verwenden.

> Starthaltestelle (der Weg sollte an der stop_position getrennt sein):
> stop_position | Rolle: stop_entry_only
>      und ein Punkt des Wartebereichs / der Plattform (public_transport =
> platform) | Rolle: platform
> Weg / Straße | ohne Rolle

Mir sind bisher noch keine Starthaltestellen mit der Rolle
stop_entry_only begegnet. Dass man da nur einsteigen kann, ergibt sich
meistens von selbst. stop_entry_only ist z.B. für die ICE/IC von Hamburg
Richtung Bremen und Hannover gedacht, bei denen man in Hamburg-Harburg
nur einsteigen kann (Ausstieg fahrplanmäßig und tariflich nicht
vorgesehen, praktisch aber möglich).

Das originale Proposal trifft dazu keine Aussage und schreibt nur:
> If a stop is only for exiting or entering the vehicle (common for
> nightly services) the roles stop and platform should be replaced with
> stop_exit_only or stop_entry_only and platform_exit_only or
> platform_entry_only.

> Haltestelle (der Weg braucht nicht getrennt zu werden, auch wenn sich
> mehrere Haltestellen darauf befinden): stop_position | Rolle: stop
>                                                                    und ein
> Punkt des Wartebereichs / der Plattform (public_transport = platform) |
> Rolle: platform
> Weg / Straße | ohne Rolle
> Zielhaltestelle (der Weg sollte an der stop_position getrennt sein):
> stop_position | Rolle: stop_exit_only
>     und ein Punkt des Wartebereichs / der Plattform (public_transport =
> platform) | Rolle: platform

Es gilt dasselbe wie bei stop_entry_only.

> Zur Erläuterung von "ein Punkt des Wartebereichs / der Plattform":
> 
> Bei der bisherigen Verwendung von highway=bus_stop neben der Straße wurde
> dieser in die Route eingebunden, sodass der User genau wusste, an welcher
> Straßenseite er auf den Bus warten musste. Durch die Verwendung von der
> stop_position auf der Straße ist dies nicht mehr möglich. Daher ist
> vorgesehen die Plattform / der Wartebereich in die Route zu integrieren.
> Solange dies nur ein Punkt ist, ist dies auch ohne Nebenwirkungen möglich.
> Wenn es aber eine Linie (way) ist, meldet der Relation-Analyser sofort
> einen Fehler da die eingebundenen Wege nicht alle miteinander verbunden
> sind.

Na und? Wir mappen nicht für QA-Tools. Der Relation-Analyzer unterstütz
vermutlich kein PTv2 und geht davon aus, dass Routenrelationen nur
Fahrwege und Node-förmige Stationen enthalten.

> Daher ist mein Vorschlag, nur den Endpunkt der Linie/der Plattform, der der
> stop_position am nächsten liegt, in die Route einzubinden. Es kann auch ein
> zusätzlicher Punkt in die Linie auf Höhe des Haltestellenschilds in die
> Relation eingebunden werden. Dieser kann (wenn gewünscht) als
> highway=bus_stop getaggt werden.
> 
> Als Beispiel dafür hatte ich die Busline 85 entsprechend bearbeitet:
> https://www.openstreetmap.org/relation/356156 und
> http://www.openstreetmap.org/relation/4575211

Die von dir genannten Routen sind derzeit invalide. Erstens ist die
Reihenfolge falsch (siehe oben) und zweitens müssen die
platform-Mitglieder Plattformen sein und nicht irgendein Node, der (mehr
oder weniger zufällig) mit der Plattform verbunden ist.

Viele Grüße

Michael



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenomme)
I prefer GPG encryption of emails. (does not apply on mailing lists)

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.openstreetmap.de/pipermail/dresden/attachments/20150212/ef07cde1/signature.asc>