Proposal:PTv2 Improvements wrt Rapid Transit

From OpenStreetMap Wiki
Jump to navigation Jump to search
PTv2 Improvements wrt Rapid Transit
Proposal status: Inactive (inactive)
Proposed by: Zverik
Draft started: 2017-12-06
RFC start: 2017-12-10

Proposal

This proposal aims to clarify tagging of metro stations and lines, in the light of the modern Public Transport schema, and to make the data usable to data consumers. It lists only proposed changes to the existing wiki pages.

Having all metro systems tagged in a uniform and complete way would allow for making metro schemes and for proper routing. More than 70 metro networks all over the world have been already mapped as this document proposes.

Applies to

All things written here apply to subway, light_rail, monorail and funicular routes and stations. Some parts of the proposal may apply to other modes of transportation (e.g. underground trams and trains), but the purpose is to tidy up rapid transit systems.

Changes

Subway Entrances and Exits

Every subway_entrance should be a member of one or more stop_area relation.

Reason: in most cases it is unclear where the entrance leads. Spatial relationships do not work in this case. Some entrances lead to more than one station.

Elevator entrances (not inner elevators between levels of a station) should have both railway=subway_entrance and highway=elevator tags. If an elevator is mapped as an area, use a node on its contour.

Reason: these elevators are entrances, and we need a way of differentiating between these and elevators between levels. The proposal page for elevators allows mapping these as ways: in case of subway entrances they should be remapped as nodes, or there should be a subway_entrance node on the contour.

To tell exits from entrances, either:

  • Use entry_only and exit_only roles in stop_area relations.
  • Add entrance=entrance if you cannot exit a station at the subway_entrance, or entrance=exit if you cannot enter there.
Reason: currently we have no way of tagging "one way" subway_entrances, except for connecting oneway footways. But using these footways in determining the mode of an entrance is too hard (you have to implement a full-fledged pedestrian router), and not all subway stations have footways mapped.

Stop Positions and Platforms

If there are separate public_transport=stop_position points or platforms mapped for a station, these should be added to a stop_area relation.

Reason: to link stops and platforms to a station object. There is no other way: these objects can be far from platforms, and there can be many stations nearby.

Restricting Stop Areas

For a subway station, a stop area relation should have only objects that are directly related to the station. Rule of thumb is, only objects with these tags (roles are optional, except for oneway subway entrances):

You should not add any tracks, footways, taxi stands, or bus stops.

Reason: let's use stop_area for public transport, and e.g. "site" relations for marking all the contents of a station. Tracks and footways get in the way of constructing a station model in applications, and make editing a station much harder. Imagine what happens if such station gets edited via iD editor later. The less objects in a stop_area, the better.

You can add other POIs for the station infrastructure, like barrier=turnstile and shop=ticket.

Reason: these points of interest are rare and play an important role in station navigation. Of course it would be better without these in a stop_area relation for PT routers, but such objects do not make using the relation harder.

Stop Area Groups

Stations, stops or platforms that are far enough from each other (e.g. more than a walking minute away), or belong to different modes of transportation (e.g. a bus station and a subway stop), should belong to separate stop_area relations.

Reason: otherwise they comprise a single station, and a data consumer will be suprised when "get off one train and enter another" suddenly includes a ten-minute walk, or a paid network change.

Multiple stop_area relations, that are both officially considered an interchange and feel like an interchange, should be grouped in a public_transport=stop_area_group relation.

Reason: with the above, there is no other way of tagging an interchange. Some people suggested using nested stop_area relations, but why complicate things, when we have a well-used and proposed in 2009 stop_area_group type.

For example, similarly named stops or stations close to each other, subway stations that are connected with underground tunnels, bus stops near exits from a subway station, subway and train stations on different levels.

For detailed recommendations for mapping stop area groups, see Proposed features/Metro Mapping#Interchange.

Railway Tracks Direction

When you map directions with separate ways, do not use oneway=yes on these. Instead, look at railway:preferred_direction or designated_direction=* keys.

Reason: "oneway" tag marks a legal restriction, and trains do not have these. An engineer won't be fined if he drives a train in an opposing direction. There are very few railway tracks that even have signs forbidding the reverse movement.

Stops Are Mandatory, Tracks Are Not

Tracks are optional for a route relation.

Reason: even on the ground, splitting roads and constructing a route is hard. Underground, tracing tracks is virtually impossible: GPS and imagery won't help you. One should not be penalized with a requirement to draw proper tracks for just wanting to add a route. From experience, many currently mapped subway networks do not have tracks in them.

Stops or platforms are mandatory for a route relation.

Reason: without these, a relation is virtually useless. When you have just stops, you can use a route relation for navigation, you can interpolate points into lines for displaying, and you know many properties of a route, including "from" and "to" stations. When you have just tracks, all you can do with the route is render it — but who would want route lines without knowing where to board a train?

Adding a platform for a stop in a route relation is highly recommended when there are two or more mapped platforms for that stop (e.g. side platforms for each direction).

Reason: because otherwise you won't have an idea which of the platforms to use, especially on big railway stations. This is not mandatory, since we don't want to make mapping routes harder that it is.

Mandatory Route Tags

These tags are mandatory for a route and route_master relations:

  • ref=* with a line number or short reference.
Reason: it is mandatory in GTFS and using a route is hard without a reference id. Also these group routes in absence of a route_master.
  • colour=* with an official line colour, either a hexadecimal value (#ffeedd) or a CSS3 colour name (red). Get it from an official metro map. Optional in case there is no official metro map.
Reason: it is very easy to acquire (just one google search away) and is highly useful in visualizing a route map.
Reason: switching between networks almost always imposes an extra fee, so the networks should be separate. In case there are no official network names, take one from wikipedia or from common knowledge.

When a line has an evident casing on the official map, especially when the line colour is white, put the main colour (of the casing) in colour=*, and the inner colour — in colour:infill=*. This way you won't have a dozen white lines in software that doesn't support infill. For example, colour=cyan + colour:infill=white for London DLR routes.

Reason: casing won't work, because with that most lines become "white", which is bad for consumers that do not understand casings. Other options sounded worse.

Service Interval

Introducing an optional route relation tag, proposed in 2014 and now used in some big cities:

Reason: while exact schedules are changing rapidly, intervals mostly stay the same over years. This value is highly useful to plan a better public transport route, to not prefer a train route with 1 hour intervals to a longer subway route, but with a 5 minute intervals.

Features/Pages affected

Comments

Please comment on the discussion page.

The previous version of the proposal was extensively discussed and may provide some answers.

See Also

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:PTv2_Improvements_wrt_Rapid_Transit&oldid=2516726"