Talk:Tag:public transport=platform

Transport mode tags

Can I suggest that we recommend the use of 'mode' tags (train/bus etc) with platforms which will make it much easier to down-stream software to represent the data without getting into relations etc? PeterIto 11:06, 3 April 2012 (BST)

Do you mean bus=yes, tram=yes and so on? --Teddych 11:55, 3 April 2012 (BST)

If we do this, we will soon face inconsistencies with the mode of the associated stop_postion. Dont like the idea of perpedually fixing that manually. We schould not repeat the same piece of information. Nzara 12:29, 7 April 2012 (BST)

In the last version (9979) JOSM is asking me to add bus=yes platforms, though not mentioned here that should be so. Corecto what is it? Is not add or mode of transportation? AgusQui 25 March 2016

Typically, the bus is not allowed to drive over the platform but rather along the side of it on a way that includes the stop position. In my opinion, usage of e.g. "bus=yes" on a platform does not make sense. --Biff (talk) 02:42, 27 April 2016 (UTC)

Assume that closed way is always an area

As pointed in this mailing list thread, a linear platform on a closed way does not exist in real world. Either it is supplying several stop areas or stations, in which case the way has to be split, or it is an area. I think we can safely assume that a closed way tagged as platform is always an area and therefore the tag area=yes is unnecessary in a modeling point-of-view. But the tag might be added as a workaround until rendering tools like mapnik/osm2pqsql support the correct assumption. --Pieren 16:05, 7 May 2012 (BST)

I confirm this. --Teddych 17:28, 7 May 2012 (BST)

What about public_transport=platform mapped as an area and highway=footway ? I would in my opinion consider that public_transport=platform is always assumed to be accessible by foot, so highway=footway should be implicit. But we probably still have to add it until routing softwares got that thing. Then the problem is that if we don't add area=yes, the the highway=footway wont be considered as an area. What's the better option in that case? (sorry for my maybe inaccurate english, i'm french...) --Leptitmouton (talk) 21:20, 11 February 2017 (UTC)

Electronic information signs

I would like to be able to tag public transport platforms as to whether they have electronic information signs or not (e.g. the signs that give you the next X buses/trains/trams to arrive, with arrival time/route). Does anyone have a good idea for a tag? I was thinking something like digital_signage=yes Spark 22:40, 1 October 2012 (BST)

The most used tag at the moment is, apparently, ticker=yes/no. Others use departures_board=realtime/yes/no/*. Neither has yet been documented in the wiki, but both are in use and were discussed in 2010. Alv 09:26, 2 October 2012 (BST)

For now departures_board=realtime/yes/no/* is more common than ticker=* (and, I believe, more common in English). Ambush (talk) 05:49, 5 September 2017 (UTC)

Name tag

The name tag refers to the name of the station and not to the number or whatever of the platform. Look at the recommendation: it would be nonsense, if the comment were correct. —Preceding unsigned comment added by Weide (talk • contribs) 12:19, 17 June 2013 ‎(UTC)

I must admit that you have a very good point. I didn't notice until now that the other description of the name tag wasn't in the original documentation. It has recently been changed back.

However, I'm not completely convinced that ref= is the right place either. The NaPTAN import uses local_ref= for this purpose, and I've seen at least a few examples of ref= being used for a system-wide reference code that is specific to that platform. How do the larger consumers of OSM PT data (ÖPNVkarte etc) treat name=, ref= and local_ref=? Most of Sweden has been tagged under the assumption that name= means the platform number or letter, and if a retagging is needed, it would be good to clarify this first. (ping Nakaner, Johan Jönsson) //Essin (talk) 16:35, 6 August 2017 (UTC)

Why was the name tag changed? According to PT2 the platform should have the name of the Stop not the number of the platform. --FrankXF (talk) 22:27, 5 May 2019 (UTC)

It is neither, look at the original proposal text, quote: "The name by which the platform is known.". So it really is meant to be the platform name, neither station name or track numbers. I changed the article accordingly. Famosm (talk) 17:51, 7 May 2019 (UTC)

ref:IFOPT

For the public transport stops in Styria (Austria), we have received a file which, among other data, contains the IFOPT-number of the stop (see Wikipedia). As discussed on the talk-transit mailing list, they will be added as ref:IFOPT. Should this be added to this page, so others might use it in the same way?

Platforms as multipolygons

I have seen multiple instances of platforms being mapped as multipolygons (e.g. refer to 3181520 3181520, 3407289 3407289, 3407731 3407731). In my opinion, this makes sense if you see a platform as the area which is walkable by a human, and if there are e.g. buildings on the platform, these obviously don't belong to the platform area itself. The tag documentation however does not allow platforms to be mapped as a relation:

The platform can tagged as an or .

What's your view on this? Should the tag documentation allow include multipolygons? -- Rohieb (talk) 00:18, 11 October 2014 (UTC)

IMHO multipolygons are generic things that can be used on every area. If this has to be added to all the possible keys, I don't know.

What I would do (I refer to 3181520 3181520): I would map Bahnsteig 7 and Bahnsteig 8 as seperate platform-areas. Then the building or whatever is usually in the middle between the two platforms and a multipolygon is not needed. --Teddych (talk) 10:19, 13 October 2014 (UTC)

I see your point and have updated the page. --Teddych (talk) 10:30, 13 October 2014 (UTC)

Multipolygons count as areas instead of relations --Jgpacker (talk) 11:19, 13 October 2014 (UTC)

OK. Do you think it was correct before my last changes? Feel free to reverse. --Teddych (talk) 11:30, 13 October 2014 (UTC)

railway=platform duplicates public_transport=platform.

Why railway=platform is 'strongly suggested' without any explanation? It is redundant with public_transport=platform, and wiki page railway=platform says it should no longer be used. I propose to remove this line. --Oligo (talk) 18:16, 9 December 2015 (UTC)

I oppose your proposed removal. The tag railway=platform has not been replaced by public_transport=platform. PTv2 proposal does not declare old platform tags as "old". They are still valid and part of PTv2. Also, there usecases where a railway platform does not serve public transport purposes but still exists and is in use, e.g. non-public railway infrastructure, emergency stops inside tunnels (e.g. Gotthard Base Tunnel), rarely served stations (like Klötze which is only served at one day per year).

I will fix the wiki pages related to platforms in the following days. (The whole public transport section at the wiki is chaotic and sometimes outdated.) --Nakaner (talk) 18:27, 9 December 2015 (UTC)

So what definition are you suggesting? Set railway=platform for all railway platforms (public or privately owned, emergency, freight...) which may or may not be accessible to public? And add public_transport=platform to platforms currently used for receiving general public? --Oligo (talk) 21:06, 9 December 2015 (UTC)

Yes. --Nakaner (talk) 21:12, 9 December 2015 (UTC)

No. public_transport=platform is an alternative way of tagging railway=platform. Some renderers still do not display public_transport=platform, therefore it is suggested to also add railway=platform. If a platform is public or not or if it is used or not is not relevant. By the way, it is also useful to add highway=footway to the way, so a pedestrian router can route via a platform. --Teddych (talk) 11:21, 12 December 2015 (UTC)

Using highway=footway

The recommendation highway=footway on platforms (railway=platform) to use, is in my opinion, wrong. Instead, should be foot=yes used as a right of use and Possibility. If the router does not evaluate this, they would have to be programmed accordingly. At highway=platform it is anyway impossible highway=footway to use. Not only, therefore, this recommendation would have to be completely deleted.

The wiki page for highway=platform indicates that it should no longer be used. So I suppose that the intention is to change this tag to highway=footway when adding public_transport=platform. To prevent problems with routers, this footway should be connected with some other highway. --Biff (talk) 09:21, 20 June 2016 (UTC)

What's the difference between shelter and covered

I'm studying the complex world of how mapping public transport. I cannot distiguish what is the difference between covered and shelter. If a thing is shelter, it is covered. No? -- Santamariense (talk) 23:23, 28 November 2016 (UTC)

Shelter

A shelter is a structure that protects travelers from rain, storm, sun, etc. See picture. You can either just add shelter=yes to the platform or you can provide more detail by mapping the outline of the shelter and tagging it with amenity=shelter and shelter_type=public_transport. The tag covered=* has a different meaning. This tag is added to a way (e.g. a street, footway or platform) that is covered by a roof or similar structure. You might also be protected from the rain while standing on this way, but one important intent of this tag is to indicate to the renderer that the way is covered and not directly visible from above. Does this help? --Biff (talk) 07:26, 29 November 2016 (UTC)

What is to you these [1][2], shelter or covered? Genenally the structure has only the roof, and no wall. -- Santamariense (talk) 18:16, 29 November 2016 (UTC)

The first link doesn't work, but the second link leads to a picture showing a structure that I would definitely tag with amenity=shelter and shelter_type=public_transport when mapping with high detail. When mapping with less detail, I would just tag the platform with public_transport=platform and shelter=yes. The tag covered=* is used for a completely different situation. Here's an example: A typical petrol station has a large roof over the pumps. This roof would be tagged with building=roof and the ways under this roof would be tagged with highway=service and covered=yes. In a similar manner the platforms of a train station or major bus station could be located under a large roof and then the platforms would be tagged with public_transport=platform and covered=yes. --Biff (talk) 20:48, 29 November 2016 (UTC)

Ok. I'm thinking I was mapping the right way. But, I think this causes lots of confusing to some mappers. I have added in some cases, the covered=yes to highways, but never to platforms. I would say that is much more common the shelter case that the covered one. The covered=yes can be more frequently used to bus station. But I'm thinking that some people are using covered=yes where the correct would be shelter=yes, they are understanding covered=yes like the roof of a shelter. -- Santamariense (talk) 22:04, 29 November 2016 (UTC)

Example of covered=yes in bus_stop: [3] -- AgusQui

This (or a similar) example should be added to the description. For me covered means protected by a structure above (e.g. a bridge), but not a simple roof (which applies for shelter). Obviously covered and shelter are mutually exclusive: you will never find a rain protecting roof under a bridge. covered=* is misused almost everywhere, thus the description should be clarified. And why should these tags be mandatory? Isn't no simply the default anyway? --GerdHH (talk) 11:05, 3 February 2024 (UTC)

Bus stop without infrastructure

They are called: unmarked, unsigned, customary, informal. They exist in Australia, Nairobi, Kenya, Nassau County, New York, USA, Peru, UK, well, surely everywhere?

Existing tags and descriptions

On this page Tag:public transport=platform

"Nodes are used for locations where there is no physical infrastructure (for example a customary bus stop without infrastructure or with a pole)."

On the related page Tag:highway=bus_stop

"A bus stop is a place where passengers can board or alight from a bus. Its position may be marked by a shelter, pole, bus lay-by, or road markings. Some bus stops are unmarked and known only by word-of-mouth or from information provided on a timetables."

Key:physically_present and Key:customary_stop

"If a NaPTAN node is not physically present on the ground but you have knowledge that it is used as a stop then: Add physically_present=no + highway=bus_stop. These latter stops may already have a NaPTAN "CUS" tag which indicates its a customary stop. We might make that explicit by adding a customary_stop=yes tag."

Key:informal

"This key is used as an attribute to describe that a feature has not been intentionally established, but rather evolved. At the moment it is mainly used in conjunction with footways and paths, but it could also be used with any other kind of feature."

Previous questions

• help.openstreetmap.org: Bus route changes with unsigned stops
• talk-us/2015-March: Bus "flag" stops? on archive or nabble
• Related but different, tagging/2016-September: Minibus routes on archive or nabble

How to map?

Everything is …=no

There is no need to map the features that are not present, especially if they are not present on any other stops nearby and especially especially if the stop is informal anyway.

Add shelter=no

• bench=no
• bin=no
• tactile_paving=no
• sign=no
• …

unsigned=yes

~1000 uses, ~3 cities in South America only

physically_present=no

~600 uses, UK only

customary_stop=yes

~3 uses, UK only

informal=yes

Not used.

Discussion

Please add and comment! --Althio (talk) 20:44, 2 May 2017 (UTC)

For informal stops that don't have infrastructure of any kind we can simply use:

• public_transport=platform
• bus=yes
• highway=bus_stop (to get them rendered until such time the above combination renders)

No extra tag is really needed, but if you want to be explicit, you could use:

• physically_present=no

If you know which lines serve this stop, their refs could be added to:

• route_ref=1;2;20a;E;Terminal terrestre.

This can help to add route relations later on and to cross check, that all route relations are present. —Preceding unsigned comment added by Polyglot (talk • contribs) 15:58, 3 May 2017 ‎(UTC)

I think sign=no/unsigned=yes/physically_present=no/customary_stop=yes/etc is slightly different from shelter=no and the other =no tags. It shows that the bus stop is present even though it is only physically observable at the points in time when a bus actually stops there. This is especially important as a message to other mappers: if mapper A maps an unsigned stop from local knowledge of the bus network and then disappears from OSM, and mapper B passes through the area a few years later and finds no physical trace of a bus stop, mapper B might otherwise believe that the stop has been discontinued and delete it without anybody else noticing.

In rural Sweden, I've sometimes noticed stops which are only signed on one side of the road, but where the bus stops in both directions. So far, I've mapped only the position of the sign as public_transport=platform and put a public_transport=stop_position on the road, but that of course means that a platform is "missing" in one of the route relations. I'm willing to add another public_transport=platform if that will be the consensus here. //Essin (talk) 18:09, 3 May 2017 (UTC)

Point out the lack of infrastructure is useful for the consumer too, since if an application tells you that in a place there is a bus stop, but this one does not see any signal will think it is a mistake. --AgusQui (talk) 21:02, 3 May 2017 (UTC)

Duplicate names

What is the best practice to tag different names used by different companies (or networks) for the same platform? Two nodes, one for every company with the respective name? (Example: A local company might use "xy street", while a regional company would use "zz quarter".) --GerdHH (talk) 14:28, 8 October 2019 (UTC)

name=* + alt_name=* if that is actually a single platform. Two separate objects if that is actually a separate platform would be optimal. Sadly, alt_name=* is likely to not be processed in many cases Mateusz Konieczny (talk) 15:08, 8 October 2019 (UTC)

I am now using duplicate nodes, one for each company. Hereby I can link the node with the correct name to the respective route.--GerdHH (talk) 17:26, 18 February 2021 (UTC)

"destination"

Sometimes it would be helpful to add the direction a bus stop serves. The two platforms of a pair might be some 100 m separated, and then this information would help the taggers (e.g. if the route comes later) as well as the users. On junctions there might be even four ore more different platforms. Only few operators bother about assigning a ref (like "A", "B", ...) to these platforms, thus mostly only the destination might be used as discrimination.

Sometimes direction=* is used, but IMHO this is wrong. The tag destination=* is defined be used with compass directions, but also location names are allowed. I feel both could apply here, e.g. destination=N or destination=North Pole.--GerdHH (talk)

Connect to footways

Should platforms be connected to footways/paths or not? Martianfreeloader (talk) 17:01, 19 March 2021 (UTC)

I think platforms shouldn't be connected to paths. I've never seen them connected in areas I map. maro21 21:59, 19 March 2021 (UTC)

I think that if platform is a separate piece of footway it should be mapped as one - see https://www.openstreetmap.org/?mlat=50.05776&mlon=19.91379#map=19/50.05776/19.91379 https://www.openstreetmap.org/?mlat=50.06649&mlon=19.97049#map=19/50.06649/19.97049 (possibly also with extra tags like public_transport=platform) Mateusz Konieczny (talk) 10:29, 20 March 2021 (UTC)

In both situation, the platforms are not part of the sidewalks and the real purpose of the short ways seem to be the platform. Therfore I would use highway=platform instead of footway, at least for some part of them. --Skyper (talk) 15:45, 21 March 2021 (UTC)

In both situations it is a footway section used also as platform. highway=platform is just making things annoying for anyone who wants to process data Mateusz Konieczny (talk) 17:55, 21 March 2021 (UTC)

But it's ultimately supposed to be upgraded to area=yes. ---- Kovposch (talk) 07:02, 22 March 2021 (UTC)

Sorry, I wasn't specific enough. I was thinking of situations where the platform is mapped as an unclosed way. Sometimes, I see them connected to the pedestrian infrastructure, like here [4] and sometimes they aren't, like here [5]. I'm assuming it's helpful for routing software if they are connected, but first want to check if there are community standards which discourage doing this. Martianfreeloader (talk) 10:57, 20 March 2021 (UTC)

I would say, it depends on the situation. If the sidewalk is mapped as separate object next to its highway and the platform is in between these two ways, then I would connect it to the sidewalk. If the sidewalk is not mapped as separate object but as tags on the highway, I would not connect the platform. If the sidewalk is mapped separately and the platform is only part of the sidewalk, I would split the sidewalk and add the platform tags to the part of the sidewalk or only use a node for the platform. --Skyper (talk) 15:33, 21 March 2021 (UTC)

Surveillance tagging

@Plamen: suggested man_made=surveillance in their latest edit. I suggest changing this to surveillance=yes instead.

Grounds:

• It describes a property, and not the object itself. The tagged object has surveillance, but it is not a surveillance device. In my opinion, man_made=surveillance would (only) be correct if the surveillance camera were mapped as a separate OSM object, not as a property of the platform.
• Using man_made=surveillance on a platform would create conflicts if another user suggests to also tag other properties with the same key, e. g. man_made=telephone_box or man_made=bridge (hypothetical examples). Martianfreeloader (talk) 11:47, 12 January 2022 (UTC)

+1 Fully agree with Martianfreeloader. --Nw520 (talk) 11:54, 12 January 2022 (UTC)

+1 Mateusz Konieczny (talk) 13:35, 12 January 2022 (UTC)

I also prefer surveillance=yes, the proposal was copied from amenity=atm--Plamen (talk) 20:04, 12 January 2022 (UTC)

OK, I've just applied this to the article. Martianfreeloader (talk) 20:39, 12 January 2022 (UTC)