User:Roland.olbricht/Simple Public transport

The aim is to get the public transport model as simple as possible (but not simpler). Things that must work are

• Rendering: putting something on the map that gives a clue
• Routing: getting people with no-nonsense directions from door-to-door, using only walking and public transport

I do not claim that the current data is sufficient for routing and rendering (the missing point is marked). I do not encourage to delete any other data. I do encourage to tell clearly which data is going to be used and should be asked-for and which is just there. Extra data can, for example, help to give a clue if the required data is credible or not.

This affects three categories: Passenger infrastructure, route relations, and vehicle infrastructure. Routing needs passenger infrastructure and route relations. Rendering gets better if in addition vehicle infrastructure is available.

Route relations

Passenger need to know which vehicle is the right one and realize when they have to get off (including changing vehicles). It is really that simple.

Most cities in the world send vehicles along recurring services, and usually a pair of those (one in each direction) forms a line. Hence, the thing you want to provide people with is a line number (sometimes a name, e.g. London tube, or a colour) and the displayed terminus.

Thus, the crucial tags are ref and to. Every other tag is irrelevant (but not forbidden).

Now, you also need to tell passengers when to get off. This is almost everywhere done by announcing stop names, sometimes people must look at each station for the name signs outside.

Thus, the crucial members are those with role stop. Every such member must have a name tag. For meaningful passenger routing this shall be the most precise object possible, in particular with respect to the requirements for passenger routing.

For rendering it is necessary to mark the itinerary the vehicle runs. Thus, there should be a block of relation members with empty role that designates the way the vehicle takes. Please note that this is neither required for nor used in passenger routing. A sincere validator should convey this message (routing works, rendering does not).

Remark: For no-nonsense routing, a router shall consider only services that are actually operating at the time the user likely wants to use them. There are reasons to map in addition all kind of peak hour services, school buses, leisure time, night, and other services. Such a tag is completely missing at the moment. The simplest solution would be a short list of - metro style: runs every few minutes (at least from breakfast to after dinner: 6 trips per hour Monday to Friday, at least 3 trips per hour on public holidays, no statement about late evenings) - all_day style: runs at least once per hour (at least from breakfast to after dinner), used with penalty of 20 minutes - special: other schedule, not used in routing unless a timetable is available There is an "interval" tag, but I deem it prone to misinterpretation; most services have wildly varying frequencies on different part of the day or on the weekend.

Remark: Another source of endless discussions is what to use as proper mode of transport. The difficult points are on the one hand the various shades of railway transport, tram, light rail, interurban, subway, commuter rail, and rail. There is no solution, because any taxonomy will unduely demote services somewhere in the world. The other problem are all modes of transport that are neither traditional rail nor simple buses (e.g. Translohr). I therefore suggest to use a shield tag instead of mode of transport that refers to a corresponding file on Commons or a simple fallback bus, tram, and rail where we have no particular shield. This also has the advantage to give a rendering that is close to what people see in the street and allows for a symbol locals often are proud of.

Route relation:
tags:
  ref = <Line number or name>
  to = <Announced destination>
members:
2..n  { role: "stop",
        <Ref to Object with Name> }
0..n  { role: "",
        <Ref to way used by the vehicle> }
[the stops are in the order as served by the vehicle]
[the ways used by the vehicle form a continuous line]
[other elements are ignored and do not harm]

Passenger infrastructure

Passenger infrastructure is the place where either a passenger arrives by foot and continues by public transport or vice versa.

Hence, the basic requirement of passenger infrastructure is

• to have a name (for telling the user where to get out)
• to be routable

Note that industrial grade routers are able to detect routing islands and to jump from the routing island to the nearest point of the routing graph. This affects platforms and poles. Otherwise we have to include the discussion about separated or not-separated sidewalks and this is off-focus. The other direction, jumping from the street on platforms is much harder: just because there is a platform, it is completely unclear if this is the platform used by the vehicle or the backside of a neighbouring platform, the platform of another mode of transport and so on.

Thus, the best place is the platform or the position of the sign off the vehicles street or rails.

Given that subway stations may be not mapped properly, it makes sense to use the indicative node "railway=station" in those places.

Remark: It is commonplace to have a middle platform serving two tracks. Some platform even serve more than two tracks: [1] A lot of mappers expressed the need to tell on which track of the platform the service calls. This is, beside operating_mode the other missing piece of information. I suggest a tag public_transport=platform_edge for this.

Remark: Not all subway stations have their platforms mapped, and it is nonetheless helpful to have route relations for the subways in those places.

Passenger infrastructure:

One and only one object per location the vehicle calls at:

node, way, or multipolygon with
  public_transport=platform
  name=<Name of the stop>
[other tags are ignored and do not harm]

or as a fallback if no platform is known:

relation
tags:
  public_transport=stop_area
  name=<Name of the station>
members:
1..n  { role: "entrance",
        <Ref to subway entrance> }
[contains all entrances from which walking to the unmapped platform is possible and reasonable]
[other elements are ignored and do not harm]