Proposal talk:Metro Mapping

Tag for underground features

Instead of using layer=*, might be interesting to use instead level=*, as there are efforts around the world for mapping indoors subways stations following Simple Indoor Tagging scheme. For example we have lot of underground train stations mapped in Paris. --PanierAvide (talk) 07:54, 25 September 2017 (UTC)

Thanks, added a comment about that. --Zverik (talk) 08:13, 25 September 2017 (UTC)

I think that comment is not enough. We are working to phase out layer on subway stations in all parts of (Western) Europe. If you care about having a consent I urge you to replace layer with level in the list of mandatory tags. The relationship between the two is as follows: if the operator of the building (or station in that case) has decided to signpost levels (in elevators almost always present) then they should go in the level tag. The layer tag, by contrast, is a non-binding hint for the renderer. Even the definition discourages its use on subway stations. Therefore, if you want consent then make the level mandatory. It is mandatory in public transport taggging coordinated with Simple Indoor everywhere else. --Roland

The definition describes the tag as a hint to renderer, and then discourages its use? I fail to see why it should not be used: some editors (like JOSM) even check for intersecting features and prompt to add a layer tag. I am not against using level, but only if a mapper knows its value. I doubt you can know it for most underground stations: in Russia these are not posted anywhere. I cannot add a tag with mostly unknown values to a list of mandatory tags. --Zverik (talk) 13:32, 7 October 2017 (UTC)

Stop Area

Why include railway=station in relation stop_area?

Imagine a properly mapped PT subway route. It includes rails, platforms and stop positions. It does not include railway=station nodes, that contain all the information about the station. How do I get an ordered list of station nodes in this case? --Zverik (talk) 14:01, 25 September 2017 (UTC)

I think this can be retrieved using stop_area relations, which may contain the station as one of its member. And the stop_area relation can be retrieved using stop_position node, which is part of route relation. --PanierAvide (talk) 14:22, 25 September 2017 (UTC)

Exactly! And that is the answer to the freeExec's question. --Zverik (talk) 14:48, 25 September 2017 (UTC)

Didn't saw that it was a rethorical question. However my answer underlines that it is already standardized :-) --PanierAvide (talk) 15:08, 25 September 2017 (UTC)

In fact, now information about the station is stored in the stop_position, (I mean the railway routes). Although it can be stored in public_transport=station or in stop_area. Railway=station does not have any unique information. At this moment it is a beautiful mark for rendering. The ordered list of the station is obtained in the order of the stop_position order in the relation. freeExec 18:48, 25 September 2017 (UTC)

You think it's better to store it in a stop position, somebody would prefer a platform. I have seen station tags on any of these, and that was fine. What I want is uniformity: to know that all the information can be gathered from a single object. In most cities (I am considering not only your city, but more than 150 of them) data has been put on station nodes, and I don't aim to challenge that. --Zverik (talk) 19:50, 25 September 2017 (UTC)

Stop position

Placing the stop position in the middle of the train seems like it would be difficult to determine and verify; one would have to wait for a train to come in and count carriages. The front of the train is a more obvious feature and can often be mapped without waiting for a train, as many systems have signs showing the driver where to position the front of the train.

Also, it's implicit (and obvious from the diagram) that the stop position should be a node on the rail way, but perhaps this should be documented explicitly? --Ecatmur (talk) 17:14, 29 September 2017 (UTC)

I am merely compiling different pages on metro / railway mapping. As you can see here, here, here and in some other places, the consensus is placing the stop_position in the middle of a vehicle. As for the node on a way, added that, thanks. --Zverik (talk) 13:55, 29 September 2017 (UTC)

As I wrote on the Tagging mailing list, you can have a look at the stop signs and an additional text on them which indicates either the number of EMUs or the length of the vehicle or a term like "short train"/"long train". Most operators have multiple classes of vehicles in their rolling stock but the length of an EMU does not vary much between the classes. The lengths of the vehicles are available from many sources: Wikipedia, books about the vehicles or even the websites or advertisments of the operator itself. --Nakaner (talk) 20:08, 1 October 2017 (UTC)

Not directly relevant here (trains in most metros are fixed length), but a stop position in the middle of the train is meaningless for a platform where train lengths may be 2,3,4,6,8 or more. This is a pretty common occurrence on the suburban lines serving London, and during the day train length may vary considerably even on a single route. So most stations will have 3-4 signed positions telling drivers where to stop. So the suggested (common?) practice, which is probably sensible, as most pragmatic, is not truly the stop position and not readily verifiable. SK53 (talk) 12:46, 3 October 2017 (UTC)

Oh OSM, where there is no consensus on anything. Added a comment in the section, thanks. --Zverik (talk) 13:01, 3 October 2017 (UTC)

Broadly speaking it's why I've never mapped stop positions on railways. If you are a frequent tube traveller choice of carriage is much more determined by where the most effective exit from the platform will be. I no longer have the instinctive knowledge of when to walk up a platform to get a speedier exit, but much of this is still relevant (for instance routes for step-free access may be very different from regular ones). As I say, the issue is largely moot for metros/subways anyway. SK53 (talk) 13:23, 3 October 2017 (UTC)

I agree, I don't map stop positions either — cannot see a reason for these. --Zverik (talk) 14:28, 3 October 2017 (UTC)

Direction, track number and platform ref

According to OpenRailwayMap: For the direction of the trains one must use railway:preferred_direction=forward/backward.

Could you please point me in the direction of a wiki page on that tag, so I could replace the link? --Zverik (talk) 16:26, 30 September 2017 (UTC)

https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Tracks --AgusQui (talk) 22:31, 30 September 2017 (UTC)

For the number of a track inside railway station railway:track_ref=*

rail + ref — 200 thousand ways, rail + railway:track_ref — 50 thousand. What is the reason for such complex name and where it was discussed/proposed? --Zverik (talk) 16:26, 30 September 2017 (UTC)

railway:track_ref is specifically to indicate the number of track in a station, instead ref is used for all tracks in general (In a station can be both tags together, the ref will indicate the reference code of the tracks that pass by.).--AgusQui (talk) 22:31, 30 September 2017 (UTC)

Okay, this is a good point. Changed the tag. Still not sure about the railway:preferred_direction: google gives nothing, so that's the only page that mentions the tag, unlike the other one. Left both of these. --Zverik (talk) 12:08, 1 October 2017 (UTC)

There is no requirement to write a proposal in order to introduce a tag. railway:track_ref=* was invented by railway mappers a few years ago and was never proposed formally. Please keep our You can tag what you want rule in mind. --Nakaner (talk) 20:27, 1 October 2017 (UTC)

Please keep in mind that railway:track_ref=* is used to indicate the operational number of a track in a station while the numbers used for passengers on the edges of the platforms might be different. I do not know an example of a subway station where both numbering schemes differ but I know a handful of train stations.
Numbers for passengers are only used on platforms (ref=*), stop positions (some use ref=*, some local_ref=*) and platform edges. --Nakaner (talk) 20:27, 1 October 2017 (UTC)

For the numbers of platforms, use ref=* in railway=platform, and local_ref=* in the stop_position --AgusQui (talk) 04:04, 30 September 2017 (UTC)

Thanks, though it is outside of the scope for this proposal. Subways usually have a single platform. --Zverik (talk) 16:26, 30 September 2017 (UTC)

I do not understand the difference in having 1 or more platforms, this information can also be added. --AgusQui (talk) 22:31, 30 September 2017 (UTC)

For subways, this is usually a non-public information. Also, this complicated things: I could also write about gauge and voltage, but decided to leave it to other wiki pages. --Zverik (talk) 12:08, 1 October 2017 (UTC)

Ilya, I suggest you to visit Berlin, Brussels or Rome. These three cities have stations where subways have side platforms. Subway station Theodor-Heuss-Platz in Berlin is an example.

Thanks for the invitation. We have some of these in Moscow. What I meant, you are free to tag platform numbers, but for the sake of simplicity I decided to omit the obvious ref=* tagging from the document. One can (probably) find it in wiki pages for platforms and stop positions. --Zverik (talk) 14:56, 2 October 2017 (UTC)

public_transport=station

Why not use the public_transport=station tag? --AgusQui (talk) 04:12, 30 September 2017 (UTC)

Because it marks the area for a station. Underground / subway stations consist or multiple disconnected parts: platforms, entrances etc. on different levels. Because of that, marking an area is useless. This tag is not for points, as you can read on its page. --Zverik (talk) 16:20, 30 September 2017 (UTC)

The wiki say: If a station outline is not known, the station can be mapped as a node, leaving the details to others. and is enabled for use in nodes. I do not see any problem using the public_transport=station along with railway=station. --AgusQui (talk) 22:37, 30 September 2017 (UTC)

Subway stations are most often different from railway stations. You cannot use the same tagging for these. It's not like the station outline is not known — it cannot be mapped at all. Also, why do you insist on this extra tag, while railway=station is mostly enough for mapping a station? It is required by some software? --Zverik (talk) 12:02, 1 October 2017 (UTC)

The public_transport=station was originally created to replace railway=station and amenity=bus_station. More back in history amenity=bus_station and railway=station were used when one single node was more on the map then what was before: nothing. These tags were created in a time where one never was thinking about mapping every single track or every stairs and platforms. These two long living tags have been used more and more as an area. And also public_transport=station was designed to be used as an area OR as a node. And it was designed to be used for every public transport vehicle, buses, trains, ships, planes - and subways (that is basicaly also a train). Also an underground trainstation (also called subway station), has a geographically expansion that can be mapped - for example with public_transport=station and subway=yes. It can be mapped simply as node, or more exactly as an area.

Zverik: Everyone is free to use that tag public_transport=station or even not to use. For those they want to use you should say how it is "correct" (and I would recommend equal to the already existing public transport schema). Those they do not want should simply not use the tag. If you do not say anything about the tag public_transport=station, everyone is using it a bit different. --Teddych (talk) 19:42, 2 October 2017 (UTC)

Okay, thanks for the explanation. I removed words about not using the tag. --Zverik (talk) 20:43, 2 October 2017 (UTC)

We should just make areas useable for subways. We need to define a tagging to filter which contained objects are considered to belong to the area feature. The filtering might be based on level and/or layer. And we need a relation to combine multiple areaes, maybe we can use a site relation.

Subways do conflict with considering all objects in a area to belong to the area feature anyway. For example a subway which is below a school does typically not belong to the school. Therefore, we need such filtering independent of using the station areas for the subway mapping.--Slhh (talk) 23:10, 7 October 2017 (UTC)

That would be smart, but think about data consumers. Will they have to filter all the objects on the map by station geometry and station tags? Think about mappers: will they have to be taught applying geometry + tagging filters for a station? It is easier to use a grouping method that's been invented for cases like this: relations. --Zverik (talk) 12:05, 9 October 2017 (UTC)

Island platforms

Zverik, are island platforms mapped as one area or two? In Hong Kong I've used two areas for each island platform since each side has a separate ref=* (and moreover, some of them are basically two side platforms with a few connecting passageways). Jc86035 (talk) 03:48, 1 October 2017 (UTC)

The solution is with this tag [1] (although very complicated). I prefer ref=1;2 on the platform and add local_ref=1 (and local_ref=2) to the stop_position.--AgusQui (talk) 04:00, 1 October 2017 (UTC)

I'm with Jc86035. Splitting the platform in the middle is simple, puts the ref on the right part of the platform. It doesn't tell the side on which trains stop, but this can be covered by either the platform-edge tag or by geometrically searching for the track. --Mueschel (talk) 10:34, 1 October 2017 (UTC)

There is a single platform, so I don't see a reason why it should be mapped with two objects. If you need to add refs somewhere, use a different virtual object or put both of these on the platform, like User:AgusQui suggests. --Zverik (talk) 12:12, 1 October 2017 (UTC)

Entrances

The proposal says: "entrance=yes if you cannot exit the station here, and entrance=exit if you cannot enter here." "entrance = yes" on buildings is usually not used with this entrance-only meaning. I propose to change to "entrance = only". --Mueschel (talk) 10:34, 1 October 2017 (UTC)

Good idea, thanks. Though I would choose entrance=entrance, since it has 500 usages as opposed to just one for entrance=only. --Zverik (talk) 11:19, 1 October 2017 (UTC)

An entrance might serve as an entrance for one station (or stop area) and as an exit for another station (or stop area). Therefore, tagging the exit/entrance property on the entrance feature doesn't make sense. We do either need to put this information in the role, or we need to rely on the oneway properties of the footways. For sparsely mapped stations we might think about drawing a virtual footway (or steps) directly from the station or platform node to the entrance node. --Slhh (talk) 23:47, 9 October 2017 (UTC)

You are right, and I should have done it from the start. The planet has only 3 entrance=entrance tags on subway_entrances, and only 28 entrance=exit. So making relation roles mandatory would be better. Using oneway footways is way too hard for processing. --Zverik (talk) 15:25, 10 October 2017 (UTC)

I wouldn't agree on the latter. The only application seems to be pedestrian routing, and such a router should be able to route on footways and observe their tags. It can simply route to the station or platform node, and the part of the route from the passed entrance to the station or platform node can be discarded afterwards if desired.

A reasonable router must not ignore the internal walking distances of the station anyway. A station might have far away entrances, which are are still beneficial to use when approching the station from a specific direction. Therefore, we can't omit these entrances in the stop area, but the router should not use this entrace when approching from other direction.--Slhh (talk) 01:03, 11 October 2017 (UTC)

You are thinking about the metro network in your city, I consider all 150 of these. Very few have tunnels mapped. Not all mappers would agree on "temporary" footways for connections. Overground and underground pedestrian routing are different things. Discarding things after routing looks hacky. This needs a better solution, taking in account that not all metro mappers in all the cities can or would map underground passages, at least not in 10 years. --Zverik (talk) 20:01, 12 October 2017 (UTC)

Freely accessible parts of subway stations can be a reasonable part of pedestrian routes, even of non public transport related ones. Therefore, the router needs to support underground routing anyway.

If all entraces of a station are unconnected, the pedestrian router might assume that these are equally useable for the whole station. Therefore, only exceptions (mainly interchanges) from this assumed rule need to be fully mapped including footways, and an application using the information is a good motivation for mapping the underground structure.

In addition a reasonable pedestrian router should not fail on a station mapped with footways just because the entrance node is missing.--Slhh (talk) 00:08, 18 October 2017 (UTC)

Making colour mandatory is too simple

I think that the assumption that every line has an official colour and therefore making that a "mandatory" field (not that such fields even exist in OSM) is perhaps a little short-sighted. Are we sure that official colours even exist for transit systems everywhere? --Woodpeck (talk) 19:02, 5 October 2017 (UTC)

I assume yes, because official transit systems have official maps, which usually have consistent colours. Do you know of an exception? --Zverik (talk) 08:55, 7 October 2017 (UTC)

I agree with Woodpeck. Transit systems with a single line only don't really have a need for an official colour. In addition I wouldn't consider it an offical colour just because of a map. I think an official colour should be used for identification of the line in reality too.--Slhh (talk) 00:08, 8 October 2017 (UTC)

I agree with the latter: the official colour is usually used not only for maps, but also in station and navigation design. Even with a single line, knowing the official colour would allow for making an official-looking map from OSM data. --Zverik (talk) 11:51, 9 October 2017 (UTC)

In case an official colour exist, we should tag it, even with a single line. What I have meant is that the system might not have assigned an official colour because it isn't required for identification of the single line. There, we can assumme that some lines in the world don't have an official colour. WE might use a "none" value in such cases, which would allow to make colour "mandatory".--Slhh (talk) 21:19, 9 October 2017 (UTC)

I agree — and added "If there isn't one, skip this tag." comment to the tag. --Zverik (talk) 13:52, 10 October 2017 (UTC)

Entrance name

The name tag should contain the name of the exit (and not the name of the station). This is what the wiki already describes : railway=subway_entrance
You can get the name of the station by using the stop_area relation.
Singing-Poppy (talk) 19:40, 6 October 2017 (UTC)

I was going to bring up the same. In many cities, subway entrances have names (e.g. the name of the street they lead to). The name tag on the entrance node is the logical place to put those, and the relation already carries the name of the station. Saintam1 (talk) 20:03, 6 October 2017 (UTC)

Thanks, fixed this. --Zverik (talk) 08:49, 7 October 2017 (UTC)

The poposal says:"name=* name of the exit. If absent, use names of the stations accessible from this entrance, separated with semicolons."

It doesn't make sense to mix different kinds of names using a single key. Stations are often named after streets and the same applies to exits too. It is quite likely that an exit name equals the station name, but according to the proposal an unnamed exit would typically have the same name tag. Therefore, a router can't decide if name tag can be used to instruct the user to use that exit.--Slhh (talk) 23:02, 22 October 2017 (UTC)

I removed the name tag for entrances altogether. After a few weeks mapping subway stations, it doesn't seem useful. --Zverik (talk) 15:27, 23 October 2017 (UTC)

Interchange and stop_area_group

Quoting the wiki page public_transport=stop_area :

 The public_transport=stop_area tag is used as part of a relation to identify all of the features associated with a public transport interchange or part of one. (...)
 For larger interchanges it is often appropriate to organise stop areas into a hierarchy. Heathrow Airport would for example consist of 5 terminals, a coach station and two underground stations with many associated facilities. A single stop area may include elements for many transport modes, including train, subway, monorail, tram, bus, trolleybus, aerialway and ferry

So the public_transport=stop_area_group should instead be tagged as public_transport=stop_area. Is there a need to change this behaviour ?
Singing-Poppy (talk) 19:40, 6 October 2017 (UTC)

Yes, that is exactly the purpose of this proposal, to separate stop_area and stop_area_group for subway stations. Because these mean different things: grouping all objects related to a station and grouping stations. It'd be great if this extended to other modes of transportation, but for subways this is absolutely needed. I'm speaking as a person who tries to use OSM data for presentation and routing. If you put all the entrances in a single stop_area relation, how do you know which entrance leads to which platform? --Zverik (talk) 08:54, 7 October 2017 (UTC)

I understand your concern, but not your solution. You can already organize stop_areas relations in hierarchy : so you can already create a stop_area for one station, another stop_area for the other station, another one for the bus station, and put your 3 relations in yet another stop_area relation.

Is there really a need for the bigger relation to be a stop_area_group instead of stop_area ?

Singing-Poppy (talk) 13:07, 7 October 2017 (UTC)

This looks like an attempt to not introduce a stop_area_group relation for grouping stop_areas. Why not a separate type, why stop_area inside a stop_area? Is there a limit to that — what if people start grouping all the stop_areas with stop_areas in more stop_areas? --Zverik (talk) 13:18, 7 October 2017 (UTC)

I'm not sure to understand. Does your proposal forbid the hierarchy concept in stop_area relations ?

In the example of the stop_area wiki page (an airport with 5 terminals, a coach station and two underground stations), what do you expect ?

I would say

- one stop_area for each station/terminal

- a stop_area_group for the 2 underground stations

- a stop_area[_group] for the airport terminals

- a stop_area_[group] to group them all (stop_area of coach station, stop_area[_group] of terminals, and stop_area_group of underground stations)

If so, how does the stop_area_group improve the data usability ?

Interchanges and stop areas are very abstract objects. If you want that we all use the same way of mapping, you may need to be more specific.

And I'm not opposed at the concept of stop_area_group (although I think the tag is very unclear. Why not interchange ?) but I have not figure it out what it is supposed to mean and when I should use it instead of a stop_area. Singing-Poppy (talk) 17:39, 7 October 2017 (UTC)

I'd say, stop_area for each station/terminal and one stop_area_group that includes all of these. No need for more than two layers. The reason for using a different type is that it is inherently validable: stop_areas group stop elements, stop_area_group groups stop_areas. No need to check a relation's members to know the type of the relation. --Zverik (talk) 11:47, 9 October 2017 (UTC)

Ok, this is clearer, although I still think interchange would be a better name.

You may want to clarify and add a few rules of thumb in your proposal - such as "stop_areas group stop elements, stop_area_group groups stop_areas." and be aware that this may conflict with how we usually map other transport modes. Singing-Poppy (talk) 19:15, 9 October 2017 (UTC)

Agreed, at first I wanted to introduce public_transport=interchange relations, but then remembered stop_area_groups that were introduced in the original proposal, and decided to use these. Added a clarification to the proposal, thanks. --Zverik (talk) 13:47, 10 October 2017 (UTC)

One entrance, many platforms

Sometimes, a subway entrance gets you to an underground room where you can reach many platforms from many subway lines.
The proposal does not describe what to do : add both platforms and entrances in the same stop_area relation ? add the entrance to all stop_area relations ? add the entrance to one stop_area relation (nearest platform ?) ? add the entrance to the stop_area_group relation ?
Singing-Poppy (talk) 19:40, 6 October 2017 (UTC)

The idea is to mark separate stations (platforms + stop_positions for each intersecting route) as separate railway=station, thus making a stop_area for each of the platforms. See this post for an example. I'd like to hear your thoughts on this. --Zverik (talk) 08:52, 7 October 2017 (UTC)

I would say 4 stop_areas, but I really do not know about where to put some of the entrances (the Tube ticket hall one for instance, or the one in the center of the picture) Singing-Poppy (talk) 19:15, 9 October 2017 (UTC)

Stations with side platforms

How to map a station with side platforms, which might have separate entrances per direction?--Slhh (talk) 00:29, 8 October 2017 (UTC)

Thanks for the case, forgot about that kind of stations. If you have to leave the station to change direction, I'd map it with two stop_area relations, each including a side platform and entrances for it. Both would include the same station node. And then group these relations in a stop_area_group. --Zverik (talk) 11:59, 9 October 2017 (UTC)

And how about such a station with separate entrances on one end of the platforms and shared entrances on the other end of the platform. In case of using a single stop area, a router can't assume that every entrance of the stop area is reasonable usable.--Slhh (talk) 00:25, 10 October 2017 (UTC)

Well, you can get from one side to another by going the full length of a platform and switching there. Still, you can map it as two stop_areas with one entrance shared between these. --Zverik (talk) 13:55, 10 October 2017 (UTC)

Spanish Solution

How to map the Spanish solution? This might also have separate entrances per platform.--Slhh (talk) 00:41, 8 October 2017 (UTC)

Thanks for the link, did not know it's got a name :) This actually depends on whether you can switch directions without leaving the station area, that is, without paying for entrance. If you can, all this is a single station — this also covers the previous example. If not, it's technically two stations with the same name, so it's two stop_areas, each including the middle exit platform, inside a stop_area_group. The station node need not be duplicated, though. --Zverik (talk) 12:02, 9 October 2017 (UTC)

There is also an issue with the current public transport scheme not supporting multiple platforms per stop. The Spanish solution is used for very important station. Therefore, we shouldn't ignore it, and should modify the public transport scheme.--Slhh (talk) 22:11, 22 October 2017 (UTC)

How to map partially covered platforms

One end of a station might be in a tunnel and the other end overground. How to map this situation? The same issue with the current public transport scheme not supporting multiple platforms seems to apply here too.--Slhh (talk) 22:11, 22 October 2017 (UTC)

Many compatibilty problems

All this proposal breaks existing practices, and is even incompatible with what was approved. This proposal is not a "clarification", but really a diverging model. What is worse is that it is theoretically a proposal, but has been studied only for the current state of mappioçng in Russia, but already being enforced by an active online tool that says that any divergence with this model is an "error" when in fact it is not: this proposal is jsut a limited point of view based on supposed simplification, but actually needing more radical changes and introducing new tags almost undiscussed and not approved anywhere. Two very problematic sections are below. — Verdy_p ^(talk) 01:31, 13 October 2017 (UTC)

Station Node

Use only a single node for marking a subway station. No ways, no multipolygons

Why? A "station" is much larger and includes all platforms and stops in "stop areas", buildings, entrances, and related services such as ticket sales, parkings, access controls, information panels; it was meant for interchange including intermodal. Only very basic stations are representable as nodes ! You are breaking the rules on all existing stations, that are not errors, and stations are not "stop areas" which associate only stop positions and access platforms where travelers can wait, enter or exit a transport line, so ways or relations defining a large complex surface or building with "holes" are accurate). — Verdy_p ^(talk) 01:31, 13 October 2017 (UTC)

[...]

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.

Why? the location is relevant and accurately representable if you do not restrict it to just a node, where it has never been so limited for stations. — Verdy_p ^(talk) 01:31, 13 October 2017 (UTC)

You are mixing public_transport=station and railway=station. The taginfo shows that less than 6% of subway stations are mapped as polygons. Most of these try to be several things at once, always different: stations and station buildings, or stations and platforms, or stations and station areas. Many times you can see obvious errors in tagging, like absence of a platform tag for a platform. Using a node would prevent such errors and separate platforms from stations from station buildings etc. See also the discussion about station areas above. --Zverik (talk) 09:55, 13 October 2017 (UTC)

Interchange

When it is possible to go from a station to another station without leaving the metro system, that is, without passing a railway=subway_entrance node, these stations are considered to be in an interchange. To mark it, create a public_transport=stop_area_group relation, and add stop_area relations (not station nodes!) of all stations that are part of the interchange.

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.

When a group of stations is formally a single station on all of the maps, it is okay to use a single station node. But you would still have to create multiple stop_areas, one for each of the platforms (a set of side platforms counts as one). A rule of thumb is that when you need more than a minute to get from the center of one platform to the center of another, these platforms should belong to different stop_area relations, regardless of naming.

All this is a radical change. "Stations" are already used for multimodal interchanges. — Verdy_p ^(talk) 01:31, 13 October 2017 (UTC)

Thanks to Siberiano, I understood your issue. Of course, this section needs to be rewritten: by stations I mean "virtual station" consisting of one or more platforms without interchanges. Will do it this week. --Zverik (talk) 09:57, 13 October 2017 (UTC)

Update: just did it. Now it should be understandable — please reply if you still have any issues with mapping interchanges. --Zverik (talk) 13:32, 13 October 2017 (UTC)

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 other than the station objects.

This breaks the agreed model: a "stop area" associates stop positions (on lines) and platforms, there are several stop areas per station !

That was an unfortunate wording on my part. Replaced it: "stop_area relations should not contain anything not directly related to the station". That of course includes stop positions, platforms etc. And the proposal has nothing against multiple stop_areas per station, providing a stop_area_group links these. --Zverik (talk) 10:25, 13 October 2017 (UTC)

• Linking stations to other stations and other modes is done through the stop_area_group relation.

This is your proposal, the grouping was made on "station". This changes the model radically!

No, there are examples when grouping is made on platforms, with a single station node for a whole interchange consisting of several platforms. See "Interchange" and "One entrance" sections above. --Zverik (talk) 10:25, 13 October 2017 (UTC)

• Minimal mapped route: route=subway relation that contains just station=subway nodes.

This is a radical incompatible change. Routes include distinct roles for stop positions and platforms but not stop areas. Stop positions (on lines) MUST be in routes and for the correct direction and in the correct order. They may include platforms. In fact this part of the proposal contradicts other parts of the same proposal. This just adds to the confusion, but does not correct things. In fact the online tool that attempts to implemetn this suggests that existing networks using the standar model are in "error" when they are not. It gives many false positives. So this is not just a proposal, but a practice being enforced without discussion by a published online "QA" tool providing global statistics with wrong reports, ignoring all other talks and works that are being done locally in each city or country and adapted to get progressively to public transport model v2, which is more "flexible" than this proposal and allows smoother transition from older practices where all was done locally with different goals in terms of precision. This proposal attempts in fact to reduce the precision and will introduce new incompatibilities.

This is not a change, and definitely not incompatible. Most subway routes in the world are already mapped like this. The proposal tells that you can go all the way — add stop_positions and platforms to a route relation, draw underground footways etc. — or just quickly sketch the subway route with a few stations and a route relation. This line motivates somebody who's struck by the complexity of PT schemas to map at least basic relation for subway routes in their city. It does not restrict anybody from improving such relations. The proposal itself tries to adhere to PTv2 schema as much as possible — the only exception are stop_area and stop_area_group relations. --Zverik (talk) 10:34, 13 October 2017 (UTC)

• ref and colour are mandatory tags for a route relation. name and operator are not.
• To tell exits from entrances, use the entrance=* tag. Here it is secondary to railway=subway_entrance.

This is the most problematic section. Lot of confusion and incompatibilities or unneeded additions such as "stop_area_group".

This proposal begin only targetting metro transport, is deviating from genetal public transport which was intended to be really multimodal. Metros, railways, guided buses, tramways, cable transports and various transportation mdoes are more and more integrated and part of the same networks and become completely complementary (and often work in concertation within the same line or as alternatives depending on time of day or on some events). They include other faciltiies, such as parkings, rent-a-bike, shared tarification, and often with the same operator locally, but multiple operators over a larger area in the same network. Here this is an attempt to respecilize things only for metro systems, and this is very limitative about what is a more general problem for "rapid transist systems" in public transport offers. In addition the legal status in various countries is different, and may require or oppose some different models with different requirements. Finally this model attmpts to reduce the complexity when some countries or cities have already developed mich more detailed specifications, that this model attempts to break. — Verdy_p ^(talk) 01:31, 13 October 2017 (UTC)

• • @Verdy p**: I asked Ilya about the issues you raised, and he says this proposal allows what you write about. Can you suggest 2-3 intermodal stations that are problematic with this proposal, please? I think, the best would be to try making an `.osm` file with them as a test, and to see if the proposal fits. Siberiano (talk) 10:07, 13 October 2017 (UTC)

How to map subway like railways

Some full railway systems like RER in Paris or S-Bahn in Germany might have subway like underground lines or sections. It doesn't make sense to map station infrastructure significantly different in this case, but the railway=subway_entrance tag seems to be too specific for subways.--Slhh (talk) 22:20, 22 October 2017 (UTC)

Mappers use railway=subway_entrance for all entrances of underground stations wether it is a railway=subway which stops there or a railway=tram ("Straßenbahn"/"Tram") or railway=light_rail ("S-Bahn" in Berlin and Hamburg, "Stadtbahn" elswhere) or railway=rail ("S-Bahn"). --Nakaner (talk) 18:04, 31 October 2017 (UTC)

There is nothing in the wiki page about subway_entrances being exclusive for subways. My validator only checks that all the entrances belong to stop_area relations (which they should). --Zverik (talk) 06:39, 3 November 2017 (UTC)

Casing colour as principal colour

In the example you gave (London DLR) the casing colour is the natural one for an application that only uses one colour. It is more natural in that case to have colour:infill for the secondary colour instead. --Andrew (talk) 13:00, 1 November 2017 (UTC) Andrew (talk) 13:00, 1 November 2017 (UTC)

Thanks for the comment, Andrew. I agree, but the "infill" word looks weird to me. Can you help me come up with alternatives? Given the infill in these cases is white, maybe something like "empty_inside=yes", or "casing_only", or "fill_mode=casing"? --Zverik (talk) 13:32, 1 November 2017 (UTC)

Just switched casing to infill, for a lack of better option. Thanks! --Zverik (talk) 06:38, 3 November 2017 (UTC)

Subway Stations as Nodes

There has been a controversy regarding the mapping of subway stations. The proposal does indeed recommend mapping these as nodes and not as polygons. Please see this mailing list post for the explanation and refer to station=subway that has been telling to map these as nodes since 2014. --Zverik (talk) 18:08, 10 November 2017 (UTC)

The mailing list post does mention that "subway stations are mostly underground", but looking at the validator page for UK the first few I looked at are the London underground stations that aren't underground and can be mapped as an area fine. The logic for using a node for stations that *are* under ground is sound, but the restriction of /only/ using a node when an area can be mapped seems unnecessary - though I do see the argument about how difficult it is to add relations to relations if the area has been mapped as a multipolygon rather than as a closed way --EdLoach (talk) 15:43, 13 November 2017 (UTC)

I am okay with stations being polygons, that is not an error that prevents any use case. Wiki does not establish strong rules, nor it can deprecate anything. The restriction serves more like a warning to new mappers. The relevant wiki pages for subway stations have been restricting object types to nodes since at least 2014. Also, given that 78% of polygon stations are buildings, that isn't compliant with One feature, one OSM element. That's why I think that part should stay. --Zverik (talk) 15:57, 13 November 2017 (UTC)

Questions from Nakaner

Copied from the voting section of the proposal, all questions are by Nakaner.

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)

And as I have shown in the reply, 78% of these are mapped badly, sharing their polygons with buildings. I am okay with mapping any object is OSM in any way — the wiki is never the strict rule — but by stating that stations should be mapped as points, we at least will avoid some of such shortcut mapping. --Zverik (talk) 08:07, 11 November 2017 (UTC)

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.

No, they must not. Mapping something out of thin air instead of not mapping it is worse. What if I would imagine addresses for each mapped and unmapped building in your city, because "a best guess is better than nothing"? Tracks can easily be interpolated by software, without a help by a clueless mapper — that's what my subway processor does and that's what is done in maps.me (even better, since they do splines). --Zverik (talk) 08:07, 11 November 2017 (UTC)

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.

If you don't understand a tag, don't use it. Quite simple, in my opinion. The proposal is targeted at metro stations, but its principles can be used for other modes of transportation. In the case of bus stops, take a hint from the "Interchanges" section: use stop_area for grouping stops that can be reached in under one minute from each other, and use stop_area_groups for grouping groups of stops that are further away, but are named similarly or marked as a transfer on official maps. --Zverik (talk) 08:07, 11 November 2017 (UTC)

"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.

Again, this requirement, the same as the requirement for tracks, prevents mappers from adding their metro networks, because the whole thing becomes too complex. How does one know where a platform for every subway station is located? What if somebody does not want to add many elements for every stop in every route, to simplify managing route relations? I've seen quite a few multipolygon platforms while tidying up metro networks all over the world, and they are always more or less a problem. The proposal is not against platforms in route relations, but it aim at simplifying metro mapping by making non-important parts of relations optional. --Zverik (talk) 08:07, 11 November 2017 (UTC)

area=yes is not necessary on multipolygons but your proposal suggests to add this tag to all polygonized platforms.

I am sorry, I thought it was obvious. railway=platform page also does not mention that area=yes is optional when using a multipolygon. Certainly not a reason to fail the entire proposal — this clarification can be added later. --Zverik (talk) 08:07, 11 November 2017 (UTC)

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.

Railway=halt are okay. I simply forgot these, because at first the proposal was aimed only at subways. We should add this later. --Zverik (talk) 08:07, 11 November 2017 (UTC)

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.

Please read the "Interchange" section — it is devoted specifically to such cases. Interchanges in general were the reason I've started this proposal. Mapping them is covered in the relevant section of the proposal. Also, since yesterday Berlin (both U-Bahn and S-Bahn) passes the validation, and I did not create any extra station nodes for that. --Zverik (talk) 08:07, 11 November 2017 (UTC)

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.

I do not expect routes to have a same reference number, but the existence of an exception does not make the rule moot. --Zverik (talk) 08:07, 11 November 2017 (UTC)

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.

Why should I describe the meaning of the network tag in the proposal, when we have a long page with many examples at network=*? I understood your reasoning for the german networks and reverted my changes. For these networks I introduced a network:metro tag that is used only in my processor and does not interfere with any existing tags. That does not concern the proposal at all, it just says the network tag is mandatory when there are more than one network in the city. --Zverik (talk) 08:07, 11 November 2017 (UTC)

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)

In which ways the proposal relies on these assumptions? It does not restrict the PTv2 scheme in any way, on the contrary, it extends it to allow simpler mapping and to simplify using the data. Not preventing more complex and precise mapping. Thanks for improving the Brussels metro network: tidying it for the processor was easy, and I did not change any geometry. --Zverik (talk) 08:07, 11 November 2017 (UTC)

misuse of layer tag

"layer=-N if the platform is underground, so it is drawn underneath other features. N should be at least 3, varies by the city." - note that

• layer tag is not marking whatever something is underground
• for complex underground constructions, for example with 5 different levels it may be desirable to use -1, -2, -3. -4, -5 for underground layers
• there is nothing special about -3

Mateusz Konieczny (talk) 11:21, 11 November 2017 (UTC)

Uhhh...

Seriously, did you think I don't know what's the difference between "layer" and "level" and how they are used? Did you read the very first section on this page? Did you read this answer in tagging@ where I expain the reasoning behind -3? Spending months on making a proposal, making sure it fits the established practices, answering to dozens pages of text, just to again and again get "opposes" on the voting and such question in the discussion...

I never say or have said in the past that a negative value of "layer" tag means a feature is underground. But the suggestion to set a negative value to underground features is entirely correct, because the tag controls the order of features to be drawn, and you won't want to have an underground platform cover overground buildings or rivers. Obviously -3 is not fixed in the proposal, it just sais that it should not be higher, to not interfere with other features. For a proper underground mapping the proposal recommends to use "level" tags and the simple indoor schema. --Zverik (talk) 11:54, 11 November 2017 (UTC)

I know that typically -3 would be a good choice but making it part of tagging scheme seems to be a really poor idea Mateusz Konieczny (talk) 13:01, 11 November 2017 (UTC)

"Did you read the very first section on this page?", yes and it has no good reason to include -3 Mateusz Konieczny (talk) 13:01, 11 November 2017 (UTC)