Es gibt mehrere Gründe an Haltestellen zusätzlich zu den PTv2-Elementen auch den bus_stop aufzunehmen.
Alle Kombinationen haben irgendeine Unverträglichkeit, so dass einer der folgenden Kompromisse angewandt werden muss.
 |
PTv2 mit bus_stop an stop_position
- vormals VRR-Vorschlag von März 2014, wie in den meisten Vorschlägen der Verkehrsunternehmen wurde der bus_stop einfach der stop_position zugeordnet. Eben diese beiläufige Zuordnung ist inhaltlich Ursache der meisten kritischen Äußerungen zu public_transport.
- Muster: Central
- Vorteil: Nur ein node.
- Nachteil: Bussymbol liegt auf der Straße, ohne Fahrtrichtungserkennung,
Bussymbol ist bei breiten Straßen weit von der Haltestelle entfernt.
In der Regel unverträglich mit der alten Definition: Ein bus_stop auf dem Fahrweg repräsentiert zwei Haltestellen.
|
 |
PTv2 mit bus_stop an platform
- bus_stop an einem Knotenpunkt der platform. Die platform (hier als 2-Punkt-Linie dargestellt) kann ebenso ein area sein.
- Muster: Foche
- Vorteil: Bussymbol neben der Straße, Fahrtrichtung ist zu erkennen,
beste Vorbereitung auf eine Zeit nach bus_stop.
- Nachteil: Dritter name-tag,
Eigenschaften müssen konsequent der Platform zugeordnet werden.
|
 |
dualnode-Schema
- Der platform-node als Regelanwendung entspricht nicht dem public_transport-proposal. Trotz aller Probleme, die man sich damit ins Haus holt, ist er aber recht verbreitet.
- Aufbau mit zwei nodes, einem auf der Straße und einem neben der Straße.
- Es wird entweder die platform oder die stop_position in die Route eingebunden.
.
- Dies sollte nur ein Zwischenschritt bis zum richtigen Anlegen der platform als way oder area sein.
.
- Muster Zeile1: in Linie 50
Kleve van-den-Bergh-Straße
dto openptmap
Linie 50 sketch-line
- Muster Zeile2: fehlt
.
|
 |
island-Schema (nicht empfohlen) |
 |
tunnel-Schema (nicht empfohlen) |