- 1 Transport mode tags
- 2 Assume that closed way is always an area
- 3 Electronic information signs
- 4 Name tag
- 5 ref:IFOPT
- 6 Platforms as multipolygons
- 7 railway=platform duplicates public_transport=platform.
- 8 Using highway=footway
- 9 What's the difference between shelter and covered
- 10 Bus stop without infrastructure
- 10.1 Existing tags and descriptions
- 10.2 Previous questions
- 10.3 How to map?
- 10.4 Discussion
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
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)
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)
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, , ). 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:
- 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 Teddych (talk) 10:19, 13 October 2014 (UTC)
): 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. --
- I see your point and have updated the page. --Teddych (talk) 10: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)
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)
- 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)
- 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)
Bus stop without infrastructure
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)."
"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."
"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."
"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."
- 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?
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.
- For informal stops that don't have infrastructure of any kind we can simply use:
- highway=bus_stop (to get them rendered until such time the above combination renders)
- If you know which lines serve this stop, their refs could be added to:
- 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)