Proposed features/Metro Mapping

From OpenStreetMap Wiki
Jump to: navigation, search
Clarification of tagging Metro objects
Status: Proposed (under way)
Proposed by: Zverik
Drafted on: 2017-09-23

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. Having all metro systems tagged in a uniform and complete way would allow for making metro schemes and for proper routing.

All metro systems in Russia and in some other countries are already mapped as this document proposes.

Overview

Stop area group.jpg

Tagging Stations

Of these objects, only the station node is mandatory for each station. Also, if possible, mark the subway entrance points, so routers won't bring people to an overground location of an underground station.

Station Node

Use only a single node Node for marking a subway station. No ways, no multipolygons. Three mandatory tags on it are:

You are welcome to add more useful tags, like:

The location of the node is irrelevant. Most often it is placed in the middle of a platform, be it underground or not. This sometimes causes controversies, since the station node is displayed very prominently on most maps, and people mistake it for the overground entrance. There is nothing wrong with putting the node near its entrance: it does not affect routing or anything else.

You may also use the public_transport=station tag along with subway=yes or light_rail=yes.

Entrance

Please map station entrances and exits as nodes: it helps with the pedestrian routing. There is a single mandatory tag for subway entrances and exits:

But a lot of optional and highly recommended tags:

  • ref=* if subway entrances are numbered and you know the number for this one.
  • wheelchair=*
  • entrance=entrance if you cannot exit the station here, and entrance=exit if you cannot enter here. See also roles in stop_area relations. Oneway footways cannot be processed by all software, so please add this tag where known.

Platform

If you know the location and length of a platform for a subway station, map it as a way Way. If you know the dimensions, you can draw an area or a multipolygon. You can see an example of such thoroughly drawn platforms here.

Use these mandatory tags on a platform:

Also recommended: level=-N for when the exact level of the platform is known.

Footways

If you want to map underground passages connecting entrances to platforms and platforms to other platforms, knock yourself out. Do not forget to use layer=-N and tunnel=yes.

For more complex underground mapping, please consider using level=-N and Simple Indoor Tagging schema.

Stop Position

The modern public transport tagging schema introduces stop positions: points on rails where trains actually stop. These nodes should be placed on railway=subway/light_rail either in the front or in the middle of a hypothetical train (there is no consensus on that, do as you like), which is usually near the center of the platform. Sometimes you might need different stopping points for different route variants. The point should have at least these two tags:

Please refrain from using the same node for both a stop_position and a station. That would prevent a possible interchange from being mapped correctly.

Stop Area

To link a subway station, a platform, stop positions and entrances, put these into a public_transport=stop_area relation. For a subway station, a stop area relation should have only objects that are directly related to the station. No taxi stops, no other stations. Only objects with these tags:

You can add other POIs for the station infrastructure, like barrier=turnstile and shop=ticket. You should not add any footways or bus stops. Use a station name for the stop_area relation name.

Interchange

Interchange types.jpg

An interchange is a station or a group of stations where you can change lines or direction of travel. Technically by this description, most metro stations are interchanges. There are three types of interchanges, pictured above (A and B are lines, not stations):

  1. First is when to change a line, you have to wait for the next train on the same platform, or walk a few meters to another nearby platform. You usually can see all tracks and platforms in this interchange from any platform. An island platform between opposite directions of a route is a simple example of such interchange.
    You map such interchanges with a single stop_area relation.
  2. Second type is when you have to walk a reasonable time to get to another platform or a set of platforms. Sometimes even to switch directions for a single route you have to go down via an underpass. A rule of thumb is that when you need more than a minute to get from one platform to another, this is most likely a type 2 interchange.
    You map such interchanges with several stop_area relations. After that, create a public_transport=stop_area_group relation and add these stop_area relations (not station nodes!) in it.
  3. Third type requires you to leave a metro station to enter another one. It can take five minutes or more to switch lines, and you would need to use on-the-ground pedestrian routing to find another entrance. This is not unlike moving between stations of the same line by leaving at one and entering at another. The line between type 2 and type 3 is blurred: please use your judgment and official maps.
    You still create stop_area relations for these stations or platforms, but do not group these in a stop_area_group relation.

It does not matter whether an interchange is between differently-named stations or within a single big station. When a group of stations is formally a single station on all of the maps, it is okay to use a single station node, including it into all relevant stop_area relations.

If a station is mapped only with a station node, to create a stop area group, you would still need to create stop_area relations, even if just for a single node. Stop_area_groups collect only stop_area relations, stop_areas collect everything station-related.

Multimodal Interchange

When stations for buses, trains, trams or other modes of transportation are located near a metro station, especially when they are named similarly, do create stop_area relations for these stations (one for each mode) and add these along with the stop_area for a metro station in a public_transport=stop_area_group relation.

Do not add e.g. bus stations into a subway station's stop_area. Make two stop_areas and group these instead.

Tagging Lines

Tracks

If you don't know how the underground tracks go, that is okay: just skip this. Tracks are optional.

To make the map a bit more complete, try connecting the stations and doing smooth turns. See railway=subway for a list of tags that go on the tracks. For a light rail tracks, switch subway for light_rail. The railway=light_rail page is not as descriptive, but provides some hints for distinction of subway, light rail and regular tracks.

To simplify future mapping, it is best to draw a pair of parallel tracks. Do not use oneway=yes on these, even if you know in which directions trains usually go. If you want, look at designated_direction=* or railway:preferred_direction keys. But do set track numbers in railway:track_ref=* values if you know these.

Route Relations

For each of the subway and light rail lines, there should be at least one route=subway or route=light_rail relation. Usually there are two, one in each direction. Sometimes more, when certain trips end earlier to be redirected to depots. When there are many route relations for a subway line, there should be at least one that contains all the stations in the line.

These tags are mandatory for a route relation:

  • type=route obviously
  • route=subway (or light_rail)
  • ref=* with a line number or short reference.
  • colour=* with an official line colour, preferably as a hexadecimal value, e.g. #FFEEDD. Get it from an official metro map. If there isn't one, skip this tag.
  • network=* is mandatory when there are more than one network in the city (e.g. New York has three).

Also recommended:

  • operator=*, which should be the same for all lines of that operator.
  • name=* with a full name of the line.

Relation Members

If rails are included, they should be sorted from the first to the last stop, and should form a single line without gaps.

If a relation contains both stops and platforms (even if just one stop or one platform), these should belong to stop_area relations, so an algorithm could find duplicates.

Grouping Routes

All ref=* values for variants of a single route should be equal. That is enough to group these relations. But you can create type=route_master relations, as per the public transport schema.

What This Affects

Mostly this compiles mapping practices already in use. And improves or clarifies in these ways:

  • Stop Area relations are mandatory for linking entrances to stations to stop positions.
  • For that reason, stop_area relations should not contain anything not directly related to the station.
  • To tell exits from entrances, use entry_only and exit_only roles in stop_area relations.
  • Linking stations to other stations and other modes, and platforms within an interchange, is done through the stop_area_group relation.
  • Minimal mapped route: route=subway relation that contains just station=subway nodes.
  • ref and colour are mandatory tags for a route relation. name and operator are not.

Practical Use

All of the world's metro systems are validated against this schema, and the results are published on this web page. Networks built this way can be integrated into any application to be used for displaying and routing. Source code will be published shortly.

Comments

Please comment on the discussion page.

See Also