Proposal:Metro Mapping

Clarification of tagging Metro objects
Proposal status:	Rejected (inactive)
Proposed by:	Zverik
Draft started:	2017-09-23
RFC start:	2017-09-24
Vote start:	2017-11-10
Vote end:	2017-11-24

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.

More than fifty metro networks all over the world have been already mapped as this document proposes.

If you know PTv2 schema by heart, head to the #What This Affects section for a short summary of proposed changes.

Overview

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 for marking a subway station. No ways, no multipolygons. Three mandatory tags on it are:

railway=station
station=subway (station=light_rail for light rail stations, or use subway=yes etc.)
name=*

You are welcome to add more useful tags, like:

wheelchair=*
opening_hours=*
wikipedia=* and wikidata=*
Localized names

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.

Overground light rail and train stations can be mapped with polygons. 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:

railway=subway_entrance

But a lot of optional and highly recommended tags:

ref=* if subway entrances are numbered and you know the number for this one.
highway=elevator if the entrance is an elevator.
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 . 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:

railway=platform
public_transport=platform
layer=-N if the platform is underground, so it is drawn underneath other features. N should be at least 3, varies by the city.
area=yes if the platform is drawn with an area.

Also recommended:

level=-M for when the exact level of the platform is known.
ref=* when a platform is numbered.
name=* with a name of a platform or a station, for easier route editing.

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). Sometimes you might need different stopping points for different route variants. The point should have at least these three tags:

public_transport=stop_position
subway=yes (or another tag for the proper mode of transportation)
name=* with a name of the station.

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:

railway=station — one and only one, with optional role 'station'
railway=platform (with role 'platform')
public_transport=stop_position (with role 'stop')
railway=subway_entrance (with optional role 'entrance', or mandatory 'entry_only' or 'exit_only', depending on whether you can use the entrance to entry or to exit the station)

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

Interchange

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):

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.
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.
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. Instead, look at railway:preferred_direction or designated_direction=* keys. Put track numbers in railway:track_ref=* tags 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, either a hexadecimal value (#ffeedd) or a CSS3 colour name (red). Get it from an official metro map. If there isn't one, skip this tag.
network=* is mandatory when there is 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.
interval=* with a service interval in minutes.

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.

Relation Members

A route should have all its stops included and ordered from the first to the last. The recommended way is adding stop positions with "stop" roles. Adding platforms for each station is recommended. In that case, platform objects (with "platform" roles) should follow stop objects. There should be only one stop object and at most two platform objects for each station.

If tracks are included, they should be sorted from the first to the last stop, and should form a single line without gaps. When a line branches, you should create a separate route relation for the alternative route.

If a relation contains stop positions or platforms, these should belong to stop_area relations, so an algorithm could match these to station objects. Also, each stop and platform should belong to a single stop_area relation, otherwise it would look like a train stops at two stations simultaneously. That means, on type 2 transfer stations that are denoted by a single station node, you would need to make stop positions or platforms for each metro line, and include these into routes instead of the station node.

On type 2 interchanges, adding a station node to routes will not do. Add stop_positions to lines, use them in route relations instead of the station, group each of stop_positions with the station using a stop_area relation, and group these stop_areas in a stop_area_group relation.

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 a grouping type=route_master relation, as per the public transport schema. In that case, you can put ref, colour and network tags on it instead.

What This Affects

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

Stop Area relations are mandatory for linking entrances, platforms and stop positions to stations.
No subway entrance should be without a stop area. To tell exits from entrances, use entry_only and exit_only roles in stop_area relations.
A stop area should have one and only one railway=station object, and should not contain any railway tracks or highways.
Stop Area Group relations are reintroduced for linking stations to other stations and other modes, and platforms within an interchange.
Railway tracks are optional for a route relation.

Note that you don't have to do full PTv2 from the start. Usually it's enough to make two route=subway relations that contain just station=subway nodes and no tracks, for both directions of every route variant.

Practical Use

All of the world's metro systems are validated against this schema, and the results are published on this web page. There are more then fifty that comply. Networks built this way can be integrated into any application to be used for displaying and routing. Source code is open and published on the github.

Comments

Please comment on the discussion page.

Voting

We are voting to copy this schema to the main namespace of the wiki and make it "official". Also to slightly adjust pages for route, stop_area and stop_area_group relations. See #What This Affects section for an overview of changes and the discussion page for some answers. The results of the voting affects only the wiki: the map is already becoming closer to this schema, since we have the validation website and a few mappers interested in this.

Instructions for voting

Log in to the wiki if you are not already logged in.
Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:

To get this output	you type	Description
I approve this proposal.	`{{vote\|yes}} --~~~~`	Feel free to also explain why you support proposal.
I oppose this proposal. reason	`{{vote\|no}} reason --~~~~`	Replace reason with your reason(s) for voting no.
I have comments but abstain from voting on this proposal. comments	`{{vote\|abstain}} comments --~~~~`	If you don't want to vote but have comments. Replace comments with your comments.

Note: The ~~~~ automatically inserts your name and the current date.
For full template documentation see Template:Vote. See also how vote outcome is processed.

I approve this proposal. Obviously. --Zverik (talk) 14:21, 10 November 2017 (UTC)

I oppose this proposal. I would encourage fixing issues mentioned here (like weird layer=-3) and try again Mateusz Konieczny (talk) 20:24, 10 November 2017 (UTC)

I approve this proposal. --Panoramedia (talk) 20:51, 10 November 2017 (UTC)

I oppose this proposal. This proposal would work pretty well on local level but it will cause to much confusion and problems if you cross borders or enter central Europe. In addition, it contradicts current mapping practice in some points:
- As Martin Koppenhoefer pointed out on the mailing list, there are lots of stations mapped as polygons. I don't see any benefit in deprecating them. (If you know my older opinion on that questions, please note that I have my mind since two years ago)
- Route relations must contain tracks. This proposal tries to change the existing schema without changing the version number. A best guess of the tracks is better than nothing.
- It is common mapping practice to group bus stops and stations having the same name or located next to each other (station called "A-Town Central Station", bus stop called "Station Square"). Stop area groups introduce an additional level of abstraction. I assume that they will not help to increase the motivation among "normal" mappers.
- "Adding platforms for each station is recommended." – This contradicts the accepted proposal which says that stop positions and platforms must be added to the route relation if they are mapped.
- area=yes is not necessary on multipolygons but your proposal suggests to add this tag to all polygonized platforms.
- The proposal does not mention railway=halt which is used if the station is small (in Germany: if it has no points). You could not form valid (according to this proposal) stop area relations if the station is mapped as railway=halt. There are lots of light rail halts which don't qualify for railway=station.
- The proposal allows only one railway=station but there are stations which look like one station but contain two or three: several stations between Berlin Westkreuz and Berlin Ostkreuz, several stations between Hamburg-Altona and Hamburg Hbf, Köln Messe/Deutz.
- Public transport is full of exceptions. I explained it to you, Ilya, a few days ago. You cannot expect that all routes which should be grouped in a master route relation have the same reference number. There might be reasons to group routes with different numbers. I only know an example of a tram system by heart: Bremen tram has lines with an S suffix. S means "schnell" (German word for fast) because they don't stop at every tram stop. That's why I suggest to rewrite that particular sentence to allow deviations if the local circumstances make it sensible to do so.
- The proposal suggest to add a network=* tag but does not describe its meaning. If the meaning of the tag is open, please write it. At least German mappers use it to describe the Verkehrsverbund (explanation on Wikivoyage) a line belongs to. A line can belong to multiple Verkehrsverbünde if it reaches beyond the borders of a Verkehrsverbund or runs through an area which belongs to multiple Verkehrsverbünde. network=* is just on ticket vending machines to describe the Verkehrsverbünde whose tickets you can buy at this machine.

This proposal relies on assumptions what can be legally mapped. There are already operators of subways and underground trams (e.g. Rheinbahn in Düsseldorf, Germany) which imported their tracks into OSM. You should not forget that there are some clever/strange people in OSM who either take lasers, measurement tapes, cameras, LiDaR devices or just there eyes into stations to map them. For example, I tried to improve the alignment of Brussel subway while I used it a lot during SotM 2016. In addition, there are lots of stations whose layout is simple because they are just one level below the street. And even deeper stations can be easy to map, e.g. Wilhelm-Leuschner-Platz in Leipzig. --Nakaner (talk) 21:05, 10 November 2017 (UTC)

I took the liberty to move the list of points to the discussion page and added my comments. Please keep long issues and answers there. --Zverik (talk) 08:13, 11 November 2017 (UTC)

I hate it if people think they can edit someone else's comments. Other users' comments in this voting refer to the issues I raised and it harms readability for future readers. That's why I reverted revision 1523793 by Zverik --Nakaner (talk) 11:01, 13 November 2017 (UTC)

I oppose this proposal. Too many problems unresolved. Invalid most detailed metro stations that currently exist. multiplies by 3 the number of mandatory relation for small stations. value layer <-3 mandatory without a reason. incompatible with applications that use POIs in relationships as documented in the stop_area page. The author talks about solving problems found but votes before their resolution. The proposal modifies the existing hierarchy of stop_area without explaining the problem he encounters with the current schema. the majority of "what 's affected" are not listed on the page. The proposal introduces a logic difference for stop_area depending on whether it concerns a bus/tram or a metro instead of common schema. Above all, the proposal gives no example of the problems they want to solve. --Marc CH (talk) 22:03, 10 November 2017 (UTC)

I oppose this proposal. As nicely summarised by Nakaner, this scheme relies on too many assumptions and is not exactly compatible with how PT tagging is set up in some places. Creating yet another scheme is not going to solve underlying PT tagging problems of OSM, but rather make the situation worse. Also disagree with some of the categorical language of the proposal. --Tohaklim (talk) 22:07, 10 November 2017 (UTC)

I oppose this proposal. Forcing subway stations to be mapped as nodes (no way no multipolygon) would stop mappers to represent the real world, and would introduce a major inconsistency in the PT model (polygons overground, nodes underground). This would also invalidate a lot of work that has already been done in some cities. Removing bus stops from stop_area relations introduces an incompatibily that would require to undo a lot of work done by mappers. This proposal is an attempt to force mappers to map for the router, a variant of mapping for the renderer. --Carto'Cité (talk) 10:15, 11 November 2017 (UTC)

I oppose this proposal. --JB (talk) 12:28, 11 November 2017 (UTC)
I oppose this proposal. Too difficult for most mappers --Miche101 (talk) 12:58, 11 November 2017 (UTC)
I approve this proposal. --Alexander-II (talk) 13:40, 11 November 2017 (UTC)
I approve this proposal. This proposal no more complicated than PT2 itself, and it's just extends PT2 to separate stop_area and stop_area_group. --Dkiselev (talk) 14:44, 11 November 2017 (UTC)
I approve this proposal. --Lcat ru (talk) 14:54, 11 November 2017 (UTC)
I oppose this proposal. See Carto'Cité's comment --PanierAvide (talk) 17:19, 11 November 2017 (UTC)
I oppose this proposal. I also agree with Carto'Cité Murcik (talk) 12:09, 12 November 2017 (UTC)
I oppose this proposal. This proposal introduces nices ideas to make the ptv2 schema easier to map and to use, but the interchange topic (stop_area/stop_area_group) is still quite unclear and has unlisted side effects and incompatibilities with the mapping of other transport modes. --Singing-Poppy (talk) 13:37, 12 November 2017 (UTC)
I oppose this proposal. See Carto'Cité's comment --Overflorian (talk) 08:24, 13 November 2017 (UTC)

I oppose this proposal. Both Nakaner and Carto'Cité have already listed important reasons. The proposal contradicts existing tagging schemes, exisiting coherent data, and exisiting tools. Probably most of that could have been avoided if the matter were discussed at the proper mailing list. --drolbr 07:35, 15 November 2017 (UTC)
I oppose this proposal. User:johnwhelan
I oppose this proposal. See Carto'Cité's comment --Raffael (talk) 13:54, 15 November 2017 (UTC)
I approve this proposal. This proposal makes a lot of sense. It pulls together a lot of other mapping practices into something that can be used to map (more or less) complicated stations and stops into a grand scheme --FredrikLindseth (talk) 22:48, 16 November 2017 (UTC)
I approve this proposal. --higa4 (talk) 00:44, 18 November 2017 (UTC)
I oppose this proposal. --Omegatherion (talk) 07:13, 18 November 2017 (UTC)

I oppose this proposal. because of only nodes for stations and because the proposal is not well structured (no clear listing what is new, what should be deprecated and what is already common practice. —Dieterdreist (talk) 14:05, 18 November 2017 (UTC)
I approve this proposal. --Sev (talk) 14:48, 18 November 2017 (UTC)
I approve this proposal. --darkonus (talk) 14:48, 18 November 2017 (UTC)
I approve this proposal. While I agree that some things have to be corrected, in general I agree with the proposed scheme. --AgusQui (talk) 21:50, 18 November 2017 (UTC)
I approve this proposal. Thanks for putting in the effort to normalise metro networks worldwide. The data will only be more usable. --Saintam1 (talk) 22:48, 18 November 2017 (UTC)
I oppose this proposal. I love the proposal and the addition of a stop_area_group is a great idea. However, I have never been a fan of station nodes (not for subways, not even for mainline railways) as I think they should follow from the stop_area. Then it's up to the renderer at where to place the name of the station. IIVQ (talk) 01:34, 19 November 2017 (UTC)
I oppose this proposal. I don't understand why a stations must be "only" a point in the stop_area. also in this proposal, probably for my poor English, I don't understand why you don't apply the station tag instead of "stop_area" and don't put the stop_area tag instead of "stop_area_group"...for the PT2 the stop_area "is used as part of a relation to identify all of the features associated with a public transport interchange or part of one" and so" may include elements for many transport modes, including train, subway, monorail, tram, bus, trolleybus, aerialway and ferry.". Also you say "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", so with stop area you are mapping a single "station"(saying something different from what PT2 says "Please note that more than one station can be member of one and the same stop area. Conversely, it can happen that one station belongs to more than one stop area - if the station contains stop areas (or parts of these) with different attributes, such as different networks.) and with your "stop_area_group" you are mapping what the PT2 considers a stop_area.so I don't understand why you need to change the PT2 scheme downgrading station/stop_area tags making necessary to add the stop_area_group tag to substitute what in PT2 is already marked with stop_area . I prefer this scheme plus applying the stop_area tag to an area including the station area and an eventually other adjacent public transport stations(talk) 18:00, 19 November 2017 (UTC)
I have comments but abstain from voting on this proposal. While eating breakfast I read this twice and didn't understand it. I have not mapped a metro, but figured it would be a number of nodes and lines like any transportation network (you got polygons in there!! Those should just be optional flair). I would vote yes if this was digestible for a new mapper to do just like a road network but it is not therefore i'm going to abstain until something better can become in place.--Jonwit (talk) 15:03, 19 November 2017 (UTC)
I oppose this proposal. because I fully agree with Dieterdreist --Bubix (talk) 12:05, 20 November 2017 (UTC)
I oppose this proposal. "Use only a single node for marking a subway station." 1) It changes railway=station definition. It allows area. 2) This change not listed in "What This Affects" section. Smollett (talk) 15:30, 20 November 2017 (UTC)

Proposal:Metro Mapping

Contents

Proposal

Overview