Proposal:Simplified public transport scheme (2019)
| Simplified public transport scheme (2019) | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | SelfishSeahorse |
| Draft started: | 2019-09-09 |
The aim of this proposal is to make public transport mapping less complex and more efficient by defining a public transport scheme that doesn't use unnecessary, misnamed and duplicate tags.
Rationale
The current public transport scheme, PTv2, is rather complicated. Even for a simple bus stop, three elements are required: a public_transport=stop_position node, placed on the road, a public_transport=platform object, placed beside the road at the position where people wait for the vehicle, and a public_transport=stop_area relation connecting both elements. Both public_transport=stop_position and public_transport=platform need to be added to the route relations, which makes maintaining them cumbersome. However, to route passengers, only the waiting area of a stop is required. The stop position can be calculated from the waiting area, by projecting it onto the road or rail that is part of the same route relation. Therefore, this scheme doesn't use public_transport=stop_position.
A further problem of PTv2 is the misnamed public_transport=platform tag, which does not mean a platform, that is a raised structure facilitating boarding and alighting from public transport vehicles, but the waiting area of a stop. Consequently, this scheme doesn't use public_transport=platform.
Proposal
Stop/station
- A bus stop or a tram stop is tagged highway=bus_stop or railway=tram_stop respectively and is preferably mapped beside the road or rails, where people wait for the vehicle.
- A ferry terminal is tagged amenity=ferry_terminal.
- An aerial transport station is tagged aerialway=station.
public_transport=station is abandoned. Instead the more specific and well established tags amenity=bus_station, railway=station or railway=halt.
Platform
Stop relation
- public_transport=stop_area is required at stations, to connect waiting areas (highway=bus_stop, railway=tram_stop or railway=platform/railway=platform_edge for railways other than trams) and metro entrances (railway=subway_entrance) to the station. It isn't used for stops.
Route relation
- Each route direction and variant gets its own type=route relation.
- For non-hail and ride routes, the relation should consist of either stops or stations ordered from the departing stop or station to the terminus. It is recommended to also add the road or rail segments. If a route always serves the same waiting area (highway=bus_stop, railway=tram_stop or railway=platform/railway=platform_edge) at a station, the waiting area should be added the route relation instead of the station for a better passenger routing. (Don't forget to connect the waiting areas to the station using a public_transport=stop_area relation.)
- For hail and ride routes, the relation should consist of the departing stop or station, the terminus and the road segments.
Examples
will follow
Tagging
will follow
See also
- Proposed features/Simplified Public Transport Scheme from 2011 – The current scheme is almost identical except that it doesn't use
forward and backward roles for ways in route relations. (They are redundant if both directions get an own route relation.) - Proposed features/Refined Public Transport from 2018 – The current proposal is simpler because bus and tram stops are always mapped beside the road (they are mapped on the road or rails if there are platforms in the Refined Public Transport Proposal). Therefore, type=stop_area relations aren't needed at bus or tram stops (only at stations) and public_transport=stop_area_group relations are never needed at all.