Proposal:Simpler public transport route relations
| PTv3 | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | Stereo |
| Draft started: | 2020-02-06 |
| RFC start: | 2020-03-06 |
Proposal
We propose a new schema for public transport route relations. Compared to PTv2, routes are a lot easier to create and maintain.
Definition of existing terms
(Just to make sure we're on the same page.)
- Route ways - highway, railway etc segments used in PTv1/2 to represent the route.
- Platforms - fixed places where passengers can board a PSV, irrespective of infrastructure. public_transport=platform, highway=bus_stop, railway=platform, etc. In most cases not part of route ways.
- Stations - public_transport=station, amenity=bus_station, railway=station, etc.
The central idea
The proposed relation is identical to PTv2 relations, except that it contains no route ways - the members are primarily platforms (with role 
platform). Using platforms, in most situations, a routing tool can accurately calculate the route.
Stations (with role station) can be used instead of platforms, in situations where it is not guaranteed which platform of a station will be served (e.g. big train stations in India and France, where trains may change platforms every day), or where the exact platform is not yet known.
If platforms aren't enough
If the router doesn't deduce the correct route from the platforms alone - that is, if there is some ambiguity - via points can be used to nudge it in the right direction. A via point can be any node (e.g. intersections, nodes of highway=* segments for bus routes) with a via role in the relation (similar to turn restrictions). Ways cannot be used in a via role.
public_transport=stop_position nodes with a stop_position role are similar to via points. A stop position overrides a platform's position, but only if it is before or after the platform in the relation, and the ref tags are empty or compatible.
It is only necessary to add a via point or stop position when the router gets the path wrong, for example if it routes the bus through an alley behind a main road. The route derived from the platforms alone will probably be correct in most cases.
Hail and ride, variable routes
If a route has no fixed stops, and passengers can hail a ride anywhere along the route - simply indicate the route using via points and (if required) stop positions, and add hail_and_ride=yes to the relation.
To only mark certain segments of a route as hail and ride, use via points with the roles hail_and_ride:begin and hail_and_ride:end.
For situations where routes are variable and only platforms/stations are constant, add a route:variable=yes to the relation, to inform routers and users that there is no fixed route. By "variable", we mean 'varying on a regular basis' - it does not refer to services that change their routes in response to exceptional, unusual circumstances (e.g. construction, road work, violence, or natural calamities).
Backward-compatibility
The schema is backward-compatible with PTv2 - any valid PTv2 relation is a technically valid PTv3 relation. The PTv2 ways simply get ignored, and the route calculated by the router might need to be overriden with via points.
Caveats
We recognize that this isn't perfect for all public transport situations yet. However, we are confident that this proposal can be adapted based on community feedback to cover local and edge cases.
Rationale
- Adding, verifying and maintaining ways takes a lot of manual time and effort, even with tools like PT Assistant. This stands out in particular with long distance train and coach routes, but is also significant with intra-city bus routes.
- Conventional ways-and-platforms relations are prone to breakage (e.g. changes to a road, or a new mapper erroneously converting roads to dual carriageway).
- The exact route a PSV takes is not usually the chief concern of passengers - they are mostly concerned with platforms, i.e. where they can board or deboard. When the exact route is wanted, it can, if necessary, be influenced with stop_position and via points.
- The route can easily be deduced by routers from a list of platforms. (cf. OsmAnd, which already supports routing this way)
- Relations using the proposed schema have the added benefit of being easy to update using GTFS data (where available), which contains only stops - indeed, they will permit the update process to be automated.
Examples
- Compare this line built only with stops with the path of that bus line as it is in OSM today
- Bus 440 in Delhi - 10313936
10313936 - Train Lucknow Mail in india - 10477123 10477123
Tagging
Applies to
Rendering
Features/Pages affected
FAQ
Does everyone who wants to make a map now need to have a router?
Not necessarily. We pre-calculate coastlines for rendering, and could also pre-calculate public transport routes.
What happens if my bus route serves one stop twice / goes past one stop it's stopped at before / does a loop?
You tag the stops ordered in the relation. The router will calculate the shortest stop-to-stop route from A to B, then from B to C, etc., independently of the route taken by other stop-to-stop pairs.
Do you have an example or a demo of how the routing would work?
Yes, more or less: https://stereo.lu/osrm2josm.html shows the principle. It takes the stop_position positions and routes the line through them.
Why not make ways optional?
- They add no value when routing
- They can't easily be used for routing (routers take points)
- They break often, and are tedious to maintain. Broken ways are the most common errors https://ptna.openstreetmap.de and the PT_Assistant JOSM plugin have to deal with.
Aren't nodes more fragile than ways?
We don't think so. Currently, both JOSM and Vespucci ask for confirmation if a node you're deleting is part of a relation. Moving of via nodes is a problem only in case of hail and ride segments. Editors could warn people if they're moving nodes which have hail_and_ride:begin/ hail_and_ride:end roles.
Won't different routers route the same relation differently?
Given road classification restrictions and platforms, we feel it is unlikely. Even if they do, there is no harm in adding a via point to fix a given router - it won't change anything for other routers which are already getting the route right without it.
External discussions
https://lists.openstreetmap.org/pipermail/tagging/2020-March/051442.html
Comments
Contrapunctus was crucial in turning this from a vague proposal to a proper wiki page.
Please comment on the discussion page.