Talk:Tag:highway=bus stop

Node beside the road or node in the Way itself?

A bus stop identifies a place where people can board a bus. There is a debate about how this should be encoded and whether the stop should be part of the Way or beside the Way.

Take a number of examples:

1. A single bus stop on one side of the road
2. Two bus stops, exactly opposite each other
3. Two bus stops or opposite sides of the road offset by a number of meters but still clearly a pair
4. A bus stop set back some distance from the road
5. A row of three bus stops close together on one side of the road where different services use different stops.

I propose that normally a discrete node should be placed in the position of the pole or the shelter to one side of the road and that the software should be expected to snap it to the nearest Road for routing purposes. In each of the above cases a point would be placed where the actual infrastructure is situated. If it is an some distance from the road a footpath can be added from outside the shelter to the road. PeterIto 08:30, 24 April 2008 (UTC)

Related Mailing list Threads:

First message in the threaded view of the archive linked below:

• http://lists.openstreetmap.org/pipermail/talk/2008-April/025598.html
• http://lists.openstreetmap.org/pipermail/talk/2008-April/025603.html
• http://lists.openstreetmap.org/pipermail/talk/2008-April/025614.html
• http://lists.openstreetmap.org/pipermail/talk/2008-April/025616.html

Smsm1 - 08:57, 24 April 2008

Yeah it has been discussed a lot. Positioning to one side of the way seems to be the most widely used approach though. I have written that on the page here. -- Harry Wood 12:00, 25 April 2008 (UTC)

Other discussion from way back. Should that be moved here? I tag as part of the Way myself, and use User:rjmunro's suggestion - linked above - for tagging the direction-of-travel of the bus stop. But tagging the position of the pole would be nicer because the hardware is the target for pedestrians wanting to become passengers. Nicer still would be making it not highway=*, and doing the routing part with relations or some other Way-oriented mechanism. --achadwick 09:59, 16 May 2008 (UTC)

I think it's time to change the description to reflect the (already mentioned) more widely accepted scheme ("the node with highway=bus_stop should be at the location of the bus stop pole or at the location of the shelter" ... "and the node a part of the way marking the sidewalk, where such ways are present.") and only refer to historic discussions in a way that tells that there are other ways (namely route relations and stop_site, or-what-was-it-called, relations) to handle the mentioned weaknesses, or claimed reasons to use the tag on the nodes on the road itself. Alv 07:49, 10 February 2010 (UTC)

Status

Regarding the common practice, users more fluent with shell scripting and awk came up with a way to check if the nodes tagged highway=bus_stop are part of any ways, in any given country extract. Probably this could be run against the whole planet.osm, too. Setting up a database and importing everything would possibly or likely be slower for this kind of task. The first task below, analysing the current 1 gigabyte germany.osm.bz2 took only 50 minutes on a recent laptop computer. Downloading it can be slower! The next command, grepping takes few seconds only. So copy the following snippet (one line!) into a file, say, under the name stop_analyze in the same directory you have your country extract, and set it runnable (chmod a+x stop_analyze). Naturally you'd set the correct filename at the beginning:

f=germany.osm.bz2; (bunzip2 -c -d $f || cat $f) | awk '/^[ \t]*<way / {ok=1; id=$2} /^[ \t]*<nd ref=/ {if (ok) {print $2 " " id}} /^[ \t]*<\/way/ {ok=0}' | sort -k 1b,1 | join -a 2 -o '2.1 1.2' -e 'NO WAY!' - <((bunzip2 -c -d $f || cat $f) | awk '/<node / {id=$2} /k="highway" v="bus_stop"/ {print id} /^[ \t]*<way / {exit}' | sed -e 's|id=|ref=|g' -e 's|$|/>|g' | sort -k 1b,1) | tee busstops

Next, invoke it.

./stop_analyze

Most likely the sort command in there requires temporary disk space, so you should have free disk space of at least roughly three times the size of the file being analyzed.

Now you have a file with a node id on each line, and the way id it is a part of - but it contains each node multiple times if it is a member of many ways. So the next lines give you the number of nodes that are, and are not, part of any ways, in that order:

grep -v 'NO' busstops | cut -d ' ' -f 1 | sort | uniq | wc -l
grep -c 'NO' busstops

Results 2010-10-27

Of the 625 726 nodes tagged with highway=bus_stop,

• 204 285 are in the UK; only 1 %, 2147 nodes are part of any ways. 99% of nodes are standalone, as in beside the road - where the pole is.
• Germany has 134 351 bus_stop nodes, of which 19 % (25 564) are on the road, or possibly on some other way. 81 % are standalone nodes.
• The Netherlands has 50394 bus_stop nodes, of which 4 % (2035) are on the road. 96 % are standalone nodes.
• Austria: 9535 total, 19 % (1832) on the road. 81 % standalone nodes.
• Czech Republic: 5557 total, 38 % (2088) on the road, 62 % standalone nodes.
• Italy: 14110 total, 4.7% (666) on the road, 95% standalone nodes.

Alv 17:37, 27 October 2010 (BST)

• Finland: 17688 total, 28% (4983) on the road, 72% standalone nodes.

  Actually, about 2000 of those "on the road" in Finland are on the sidewalk - a highway=footway way (sometimes cycleway/pedestrian/platform. That's the shortcoming of the script, so far. Correct percentages are then 16% and 84%. Alv 09:06, 28 October 2010 (BST)

• South America: 3772 total, 23% (858) on the road, 73% standalone nodes.
• Switzerland: 10279 total, 21% (2124) on the road, 79% standalone nodes.
• Spain: 6333 total, 12% (791) on the road, 88% standalone nodes.

Teddych 06:42, 28 October 2010 (BST)

coherently tagging bus_stop, tram_stop and others

From what I see, tram_stop is tagged ON TOP OF the railway without any mentioning the track side. bus_stop shall be tagged NEXT TO the highway with directions.

Proposal: Both are tagged AT the appropriate street/lane/railtrack. Similar to oneway streets we have some arrow in potlatch (don't know the other editors), which can is aligned 90° to the track where one can set the side the stop is on. Options are right, left, both with the default beeing both.

1. Just tagging a stop creates two stops at opposite sides (oneway probably just one)
2. Seperate locations for both sides are achieved by adding one stop to the right and one stop to the left at another position

Advantages: routing-friedly, consistent between tram and bus, no more work than now, easy to implement (at least in potlatch), better display possibilities (bus-symbol NEXT to the street, now sometimes displayed on top)

The Left/Right (or even Forward/Reverse) has the problem that this will be corrupted if the way if reversed at any time. Forward/Reverse has the addition problem in that the renderer must know which side of the road the buses drive on (left/right hand drive) --Mungewell 23:43, 15 May 2008 (UTC)

Couldn't the direction be reversed, whenever the direction of the way is reversed? I don't know if there it could be triggered on the server, otherwise potlatch/josm have to care for that. I see the Problem... --Itschytoo 11:39, 24 June 2008 (UTC)

What happened with this proposal? I agree that a bus_stop should be on the road not close to the road and I like to add some more ideas why this should be the case: First of all it is tagged "highway = bus_stop" and a far as I'm concerned, highway tags should be related directly to anything that is a road, street or anything like that. But that is just a definition so not such a big deal. Second, you have to admit, that a bus_stop is part of a bus route. So like a train it has to pass this bus stop because it is part of this route. This would make it not just a part of this route but also coherent to railways and anything similar. I think that this discussion has to come to an end. Right know I really don't know what to do with bus stops and I won't work on them any further until this question is fully discussed. I don't waste my spare time on something where nobody knows how to do it "right". --wer-ist-roger 01:51, 13 October 2008 (UTC)

The most widely accepted approach is to put the node off to one side of the way. This is stated on the page here Tag:highway=bus stop#Usage (node positioning). What that means is, there's a lot of people out there doing mapping, and putting their bus stop nodes off to one side. I suggest you do the same.

Proposals involving putting the node as part of the way, are unlikely to gain traction at this stage, because (aside from the fact that many people will not agree that this is better) it would involve changing a lot of existing map data.

The discussion has been raised over and over again. See above mailing list links, plus Talk:Buses. More recently there's been progress with Relation:route, which should help to make these nodes more machine readable/routeable.

-- Harry Wood 16:21, 13 October 2008 (UTC)

I worked out a scheme to coherently tag all kinds of public transport stops, with some added benefits. It has been discussed on the german mailinglist, but is still in some early stages. --Gerrit 00:18, 16 February 2009 (UTC)

Personal tagging schemes

People will have been doing this all sorts of ways, in the absence of any formal guidelines. Document your personal, private tagging scheme below!

User:MapDeliverer

How I do it:

• name
• operator=*
• direction=*
  • only if bus stop is a one way stop, else omit
  • 1 / -1 for in / against way direction (@Achadwick: This solution is better for routing software and inhibits inaccuracy)
• line=*
  • several split by ","

It can be useful, too, to say which lines goes in which direction. But for my taste, that would be going too far. This info can be very useful for finding bus directions. (bus_stop nodes are every time part of a way.)

User:Achadwick - older tagging scheme

Example stop

Example ID# plate

Largely described at NaPTAN/Local_schemes#Oxfordshire since the import; this stuff here is just for historical interest. I've struck through and replaced/updated anything that doesn't make sense any more. --achadwick 14:10, 22 October 2009 (UTC)

• Core tags:
  • All stops get highway=bus_stop on a node that's part of the Way. Anything else is bad data unless the node is part of a route relation. That's fine, and indeed a better approach.
  • direction=* contains one of {N,S,E,W}, and describes which direction the bus stop serves. I'll still use this for jotting stuff down, but there may be a more widely-used NaPTAN tag for this out there
  • If there's a paired bus stop on the other side of the Way within ~20m, and no intervening Nodes on the Way, then collapse the two to a single Node without a direction=*, and add a note=* explaining the fact. Better to use two nodes, because each might have its own ID, and for better integration with NaPTAN.
• More optional tags:
  • name=* is the name of the bus stop taken from the green box on the sign itself, e.g. "Rupert Road".
  • bus_routes=* or route_ref=* lately is a semicolon-separated list of bus route numbers, ideally taken from a photo of the sign itself, e.g. "10;U10". While this information is useful when constructing route relations, we don't use it for anything else. If all of the information is expressed through other means, feel free to drop it.
    • (snip discussion: use route relations kthx)
  • Into the realm of machine-readable identifiers and other people's databases: bus_stop_ref=* is the ID number, if any are visible on the sign. In the case of the city where I've been doing this, it happens to be an integer 'Mobile OxOnTime' reference number from a small pinkish-purple sign at eye level, e.g. "69328925". Not the short 5-digit one that's a phone-keypad rendition of the word "TIMES". If you can think of a better reference code to use, say so! As it happens, this number is the NaptanCode, a very handy UK-wide identifier. See NaPTAN/Local_schemes#Oxfordshire for the skinny

It's partly based on User:rjmunro's stuff on Buses, and partly on a scheme I saw used in the Sheffield area a while back. I'm very amenable to moving away from this to anything that both renders better and is better data. The direction=* thing is a total hack, mostly there for recording side-of-road information in a way that can cope with Way direction being flipped. Using relations for the numbered routes part - or something else that's Way-oriented - would satisfy my need for the stops being associated with the road they serve. And that's what we now do --achadwick 10:23, 16 May 2008 (UTC) updated --achadwick 14:10, 22 October 2009 (UTC)

User:Thomas Wood

Documented at Talk:London#Bus_stops. --achadwick 10:23, 16 May 2008 (UTC)

bus stops + relations

Resolved: We basically agreed to disagree, but relations are helpful beasties for routes. --achadwick 12:18, 30 November 2010 (UTC)

I'm new, but I still think I can make sense of this a bit. How about using the bus_stop node solely to represent the PHYSICAL aspect of the bus stop (its location, the presence of bench or shelters...), and deferring the rest to the relation? What I mean is, the route data is left on a node of the way (the one marked stop_x in the relation), of which the bus_stop tag represents the physical location, and from which it pulls the appropriate data for each route via the relations. Is that workable/sensical? Circeu 20:19, 26 September 2008 (UTC)

I'd be completely happy with this approach. I believe relations are ordered collections of objects, just like ways are ordered collections of nodes, so do we need the stop_N notation? --achadwick 12:32, 7 November 2008 (UTC)

Actually, no. I'm wrong; there's no guarantee of order within a relation, and no way of changing the a relations members' ordering within JOSM. So better rethink that. --achadwick 13:05, 7 November 2008 (UTC) Brief update: post API-0.6 there is a guarantee of order in relations. It's still tricky to know where in sequence to put a stop along a very long way with it on. I now tend to sequence the relation {..., for stop N, for stop N, ...} if that's any help --achadwick 12:18, 30 November 2010 (UTC)

Yeah, I actually ended up scrapping the use of separate bus stop location: if you direct somebody to a bus stop, you're unlikely to describe the exact location of the stop, but more likely to use the intersection it's at. In the end, it's not really necessary, and just saying the stop is "at Monroe and Dross" will allow somebody to find the physical stops just fine! I actually found a very different area to be massively impractical, see this discussion. Circeus 05:53, 8 November 2008 (UTC)

I see the utility of marking bus stop locations, so I'll be continuing to add them. The forward and backward scheme is indeed awful, so I'll be adding them with blank roles for now. We might get ordered Relations as part of API 0.6, apparently. For bus stops and bus stations, the fact that they're included in the relation implies that the bus (sometimes) stop there; the only thing that can't be rudely tagged and constructed right now is hail-and-ride segments (but there's an idea for this at QROTI) --achadwick 21:27, 8 November 2008 (UTC)

bus stops + relations 2

I'm usually adding the bus_stop tag to nodes of the street, since together with the bus route on the street, it should be quite clearly which bus stops there. So after all, it would be only necessary to mark busses that DON'T stop instead of the ones that do (which means usually a LOT less work to do). What's your oppinion about this matter? RalpH himself 12:57, 28 December 2008 (UTC)

It's a lot more logical IMHO to put the bus stops where a bus does stop in the relation rather than all other ones... --Eimai 17:18, 28 December 2008 (UTC)

note=routes

• There is, at present, no official method of labelling which routes stop at a particular stop. I have been using the note=Routes 4 32 convention. --Mungewell 23:34, 15 May 2008 (UTC)
  • Typically it is done rather by mapping routes as separate objects Mateusz Konieczny (talk) 18:33, 22 August 2019 (UTC)
  • And if you really want to list the routes, the appropriate tag is route_ref=* instead of note=*. This is optional because, as Mateusz points out, the best approach is with bus route relations. Bxl-forever (talk) 11:58, 1 February 2022 (UTC)

shelter=yes/no

At present there is not a way to denote whether there is a shelter located at the stop or not. Maybe shelter=[yes|no] can be used, in rural locations a single shelter might serve for stops in both directions. --Mungewell 23:44, 15 May 2008 (UTC)

shelter=yes seems to be well used now. Is it worth adding to the Tag:highway=bus stop page or does a proposal & voting need to take place first.--Pobice 00:40, 19 March 2009 (UTC)

Yup. That's been documented & linked now, and well used. (old discussion) -- Harry Wood (talk) 03:32, 14 April 2015 (UTC)

other keys using *=yes/no

• I plan to also use bench=yes/no and/or waste_basket=yes/no. These are often installed 'as part of' the bus_stop in Brisbane, Australia --Waldo000000 23:04, 7 September 2009 (UTC)
  • I definitely agree on bench=yes/no. The stop I am tagging this evening has only a pole. The stop up the street 4 blocks on the opposite side has a bench. A place to sit while waiting is important information for some passengers. ----turbodog 06:15, 13 November 2009 (UTC)
    • I'm agree too, bench and waste_basket are use full and there's no need to add need node to indicate this things --Yod4z 11:37, 12 September 2010 (BST)

Scripted list of missing bus stops

Resolved: Mateusz Konieczny (talk) 18:44, 22 August 2019 (UTC)

I create a script to generate a list of missing bus_stops for the city of Lübeck, Germany - see http://www.tappenbeck.net/osm/bus-verkehr/osm_busverkehr_luebeck.html. --Jan Tappenbeck 07:47, 7 November 2008 (UTC)

"Generate"? I guess you mean you're doing an "import" from some data source. Good stuff! but make sure you are following the Import/Guidelines -- Harry Wood 10:39, 7 November 2008 (UTC)

asset_ref vs. ref

I found few transit list messages regarding using asset_ref=* on bus stops ([1]), but to me it seems "what's on the ground/pole" should be in ref=*... Did the originators of that have anything else in mind for the ref=*? Alv 16:15, 30 March 2009 (UTC)

• I asked at Talk:Key:asset ref whatever anybody has any idea hiw it is different from normal ref Mateusz Konieczny (talk) 18:35, 22 August 2019 (UTC)

Alighting Only stops

Any suggestions for marking Alighting only stops? So far I've put it in the towards tag as that's how its marked on the stop. -- User:Pobice 20:54, 2 July 2009

I imagine it is possible that a stop can be alight-only for some routes, but also be a boarding point for others. So an alight-only tag, or applying an alight value to an existing tag, probably are not the best solution. But in London at least we encourage stops to be related to routes using "role=stop". Maybe create a new "role=alight-only" variant, allowing stops which serve multiple routes to be related as either stop or alight-only. -- User:harg 16:59, 4 April 2015

If it exists, then the role approach would work yes. But I've never seen one -- Harry Wood (talk) 03:34, 14 April 2015 (UTC)

The "role=stop" seems to exist -- it is mentioned at http://wiki.openstreetmap.org/wiki/Bus_routes_in_London

"Bus stops don't require tagged references to the routes they serve: bus route relations can now reference stops directly, under the role "stop""

.The "role=alight-only" variant is a suggestion -- User:harg 08:33, 14 April 2015

Zoom level

Resolved: this is not a good place to discuss possible improvements in various renderings - report it to place where given project receives feedback (issue tracker for many projects) Mateusz Konieczny (talk) 18:44, 22 August 2019 (UTC)

I think that having rendering of bus stops at zoom level 17 are to narrow. It should be in zoom level 16 and/or even in 15. I never download tiles at zoom level 17 for my phone because that would be way to much data for it to handle. --Startail 20:35, 7 July 2009 (UTC)

i agree that default zoom level for bus stops is too high - too small area of the map is visible once bus stops are rendered --Richlv 15:01, 8 July 2009 (UTC)

I found out today that if you now use zoom level 16 you can see a tiny blue dot for the bus stop on the OSM Maps. This is better, but I still think that they should be more visible, as the parking lots are.--Startail 12:06, 17 September 2009 (UTC)

kerb=raised

As brought up in the talk-gb mailing list, I think we should be marking the raised kerbs to aid accessibility as kerb=raised.

See http://www.flickr.com/photos/pobice/3925707792/ for an example of a raised kerb.

I did suggest wheelchair=yes, but as pointed out in the thread, the kerbs don't just aid wheelchair access. Plus its hard to verify if all buses serving the point will have a low floor/no step door. -- Pobice 16 September 2009

Proposed Feature: Public Transport

Especially Harry Wood, SK53 and Alv, but also all the others I want to invite to have a look at Proposed_features/Public_Transport and comment the proposal that already is in wide use in central europe. Thanks. --Teddych 12:37, 29 November 2010 (UTC)

ref_name should be ref:name?

Key:ref has a few tag variations that end in '_ref' but all listed ref subtags listed there that start with 'ref' are of the form 'ref:*', not 'ref_*'. This is also more in line with the general tag spezialisation scheme ... Hholzgra 11:15, 24 March 2012 (UTC)

ref_name=* means "reference name" and should be the name of the halt/nus_stop, which works for most online timetable services, when name=* do not work there. So this is no subattribute to ref:* then an extension to name=*. --Fabi2 16:22, 24 March 2012 (UTC)

Proposed tag: bus_number

Why not tagging bus number on the stop, and rendering it?

For example, bus_number:"73, 76, 109"

I lost so much time, and never found the 77 in this area: [2]

--Batisteo 09:58, 21 May 2012 (BST)

There's Key:route_ref. Seems to be well used, with more than 110 thousand uses on bus_stop nodes, as of today. Alv 10:02, 21 May 2012 (BST)

Thanks. I've just noticed that there is also the key "lines", used only 10 thousand times. "Route_ref" seems to me more agnostic, but less explicite. Should we put both on the the description page, or a least one (and which one?) ? --Batisteo 18:05, 21 May 2012 (BST)

Contradictions in the wiki

In most parts of the world highway=bus_stop is used _beside_ the street, while im some parts it has been placed _on_ the street. This made a lot of confusion to mappers as well as data users. The 2010 proposal solves this with distinct tags for both cases and explicitly explaining both ways of old highway=bus_stop tagging in the tabular in section "Compatibility with well known tags".

However, even within this wiki page both approaches are mixed: the first section "common usage" declares that highway=bus_stop should go to the pole beside the street while the table in "More detailed usage" makes the impression it should be placed on the street. Thus, it would be simpler to have the page consistent.

So is the situation with the page "Buses", where both ways of tagging are mentioned inside the same section "Stops and Bus Stations".

However, I agree that in this case the headlines can be read as: In general, it is tagged off the street, but in some local communities it is tagged on the street. I hope I have now claified this in this version of the wiki pages. -- Roland

Thanks for trying to improve this article. However, please have a look at this discussion: User_talk:Teddych#highway.3Dbus_stop. Teddych didn't think this section was correct either (by the way, he certainly read the Public Transport proposal, because he is the one who wrote it ;-) ) but your edit was unclear because you left the highway=bus_stop entry in the table listing tags for the stopping point. I corrected this. However it might be even better to remove the section explaining how to tag bus stops in the Public Transport schema from the Tag:highway=bus_stop page altogether and simply add a link to Buses, where this is already (correctly) described. This would remove unnecessary duplication from the wiki and thus reduce the likelihood of errors and improve clarity. --Dhf 21:21, 31 July 2012 (BST)

I agree that removing the section would be the best solution. However, I'm pretty sure that Teddych will again and notoriously try to revert it.

There is a background story for this situation (and for parts the 2010 proposal): In the early days of OSM, the bus stops were mapped beside the street simply because the poles are beside the street. Essentially, this way the way of tagging followed the way an average mapper sees the situation. A couple of software developers adapted this in several imports (e.g. NaPTAN), the ÖPNV Karte, including myself with the public transport plugin and the line diagram generator. Actually, this was very close to a well working system beside that it had no formal specification. A first and very well-though attempt, the Oxomoa schema turned out to be too complex. The average mapper was never able to follow that.

At that point, TeddyCH came around with the idea to import data from professional sources (which are in Europe sometimes of data exchange format Transmodel). His primary concern is not the make the data easily editable or processable by independend tools but to make a lock-in towards Transmodel (I assume he has a professional background with that format). After some imports with the shifted model, the data was quite messed, because highway=bus_stop got ambigous for either the pole beside the street or a technical datum from Transmodel on the street.

Then one of the weak points of OSM came into play. While TeddyCH never contributed with running software or notable mapping efforts, he put a lot of time in writing wiki pages. In the end, the wiki was less and less in line with the majority of the exisiting data and software tools. Note that I and others can spend time for the wiki only by neglecting mapping or software development or refusing to help other users. Thus, we can't and won't do a systematic maintenance of a large number of wiki pages. To stop worsening the wiki, the 2010 proposal was organized. Of course, TeddyCH was involved in the proposal, because otherwise he could not be stopped from further deviating the wiki from the data.

This ended up with a proposal that is even more complex than the Oxomoa scheme, simply because it is intentionally vague. But at least it contains a way to make the people passionate on On-Street-Stops happy by using their specific tagging.

On the other hand it literally killed the public transport community: note that the amount of mails on the public transport mailing list and fallen since close to zero, and that even more than a year after its adpotion, less than 10 percent of all bus stops are mapped according to the proposal, and that neither the software has completely adopted the proposal nor a proposal-strict software could produce useful results, simply because so few data conforms. Hence, software developers were also deterred.

As a pragmatic solution I therefore suggested the tagging of highway=bus_stop beside the street (to make the data accessible to tools) and of public_transport=platform (to help the proposal to ever come to life). -- Roland

Interesting view.

I do not know transmodel. Perhaps Oxomoa or probably one of his contributors knew.

My Public Transport Schema does not define if highway=bus_stop is on or beside the street. At the {tag|public_transport|stop_position}} it has been removed and can therefore be called fixed.

My goal was to standardise a more detailed possibility of mapping public transport for them they want to map more exact them simply place one node for an area of 30m2 or more. I believe I reached this goal, no more discussions are needed how to tag.

Your point that an average mapper does not understand the public transport schema: Probably you are right. But why has the public transport schema been approved by about 90% of the votes? Did they understand the schema? --Teddych 20:49, 1 October 2012 (BST)

The point that the average mapper doesn't understand this wiki page is the very problem. I don't refer to the proposal here, whether it is good, bad, understandable or too difficult. What I want to convey on this wiki page (it is about "highway=bus_stop" only) for the impatient reader is a message as simple as possible:

• Please map at least a "public_transport=platform" and "highway=bus_stop" for the pole. If the bus stop has a name, add a "name" tag to the bus stop.
• If you furthermore know the stop position, please map also "public_transport=stop_position" at a node that is part of the way the bus uses.
• For the whole picture, please read the "public transport scheme proposal".

And then removing all the subsequent sections which are essentially a duplication of the "public transport scheme proposal". However, I acknowledge that you encouter this section as a lot of work. So to avoid an edit war, I strongly suggest to write it as something like:

• Please map at least a "public_transport=platform" and "highway=bus_stop" for the pole. If the bus stop has a name, add a "name" tag to the bus stop.
• The following is detailed information for specialists, drawn from the "public transport scheme proposal". You can safely ignore it if you don't need details.

and then the section in question as it is. -- Roland

Pragmatic suggestion. "public_transport=platform" and "highway=bus_stop" as common practice. The rest for specialists. I can live with that. If you would also add "bus=yes" I would be very happy (A public_transport=platform without bus=yes is not a bus stop). --Teddych 19:44, 2 October 2012 (BST)

Risking an edit war... ;)

Resolved: Mateusz Konieczny (talk) 18:36, 22 August 2019 (UTC)

At risk of creating another edit war, I have been through the article in some depth to remove repetition, references to old arguments. The article now has a lead which describes what a bus stop is and other related concepts. The 'How to map' section then describes as simply as possible how to tag and bus stop, and the associated features. I have maintained the reference to the lack of consensus about where to position bus stops (beside the road on in the carriageway) while trying not distracting the the main message, which is that they are far more commonly placed beside the road. I am not precious about the current text, so please do adjust the article to better reflect the community position. PeterIto (talk) 18:17, 2 February 2013 (UTC)

Thanks for your initiative and for your work! --Teddych (talk) 08:44, 4 February 2013 (UTC)

Thanks. I must say, that as edit wars go, this is a very disappointing one;) More seriously, the lack of clarity on this must have been putting people off and it will much better to have clear instructions available. Still happy to hear from people who feel we don't have it right yet. PeterIto (talk) 18:26, 4 February 2013 (UTC)

bus stop_links to link bus stops clearly to stop_positions?

In some cases it can be hard to clearly indicate which bus stop (or platform) is associated with which stop_position, for example where a cluster of bus stops are close to a junction, or where there are rows bus stops between service roads in a bus station where the centre of the shelter may be closer to an incorrect service road.

As an experiment, I have tried using an invented public_transport=stop_link tag to create a direct connection between the stop and the appropriate road. Here is a bus station with stop_links for a row of stops where the nearest road (or stop_position) would not be the right one. http://www.openstreetmap.org/browse/relation/218512

We have come across this when trying to deduce which road a bus service would use to access a particular stop.

Any thoughts?

-- PeterIto (talk) 22:25, 4 February 2013 (UTC)

Cycle bypass bus stops

Cycle bypass bus stops (example picture) are becoming more common in the UK, and I believe are common in the Netherlands. Any suggestions for a way to map these? The reason I would like to tag these is that cycle routing in general could generally penalise routes with many bus stops (bus stops are generally a hazard for cycling), but if they are cycle bypasses then indicate that they are OK.

I can think of two approaches. Either use a simple tag on the stop, such as cycle_bypass=yes. Or more elaborately, map the cycleway separately from the main highway for the length of the bypass, with the bus stop node being placed in the gap. Further to this, the area left between the cycleway and the highway could be mapped as an area, with tags something like highway=bus_stop, bus_stop_island=yes. This approach is more explicit but requires much more mapping, and may be harder to interpret the data.

Spark (talk) 17:15, 19 February 2014 (UTC)

Name of a bus stop

Depending on the situation, the geographical location may be included in the name of a bus stop. F.e. the bus stop "Markt" in de city Ghent (Gent in Dutch; fictive example) may say

• name=Gent Markt on the route schema, on the website, in the database of the PT company, ...
• name=Markt on the shelters and the stop signs.

We also need both cases.

• Rendering is better done with the short name, as you can see in which city it is
• When the names get used for searching, the short name "Markt" isn't unique. It isn't even unique per PT route (almost every village has a stop named "Markt").
• When you want to tell the driver where you need to get off (f.e. because different fees apply for different distances), you need the complete name).

Currently, the long name is used in Flanders. It's a waste in rendering space to see the city name appearing again and again on the map, but it's needed for other purposes. Sometimes, the geographical location of the stop doesn't even comply with the actual boundaries. F.e. it might include a neighbourhood without boundaries to avoid double names. So it often can't be deduced from boundaries. I'm thinking the following tag combo would work:

• name=Gent Markt
• short_name=Markt

What do you think? --Sanderd17 (talk) 09:44, 9 December 2014 (UTC)

Wrong or misleading parts

If a stop area relation exists, then this tag can carry the numbering of the platform in addition to the bus stop name.

No. The proposal states clearly that it can be omitted just because the stop_area exists. So the name has to be there without any platform numbering. This is important for the recognition of stop-platform-couples in the route relation.

According to the new public transport schema this replaces highway=bus_stop.

No. It's nowhere in the new public transport schema. There is no single item in the Proposal replacing highway=bus_stop.

If you wish to map this, please tag that node on the road's way, not on the same node as highway=bus_stop.

That's too simple. If the highway=bus_stop is on the vehicles way, it should be on the same node as the public_transport=stop_position. A good reason to put highway=bus_stop there is having a way or an area as a platform. Putting it on the side of the way would then introduce a wrong second platform and omitting it will leave the stops name unrendered.

shelter vs. covered

iD editor suggests shelter=* and covered=*. Which one should be preferred? Both? Does it even make sense to have covered=* and shelter=*? Possibly the answer to this question is a bug report. --Nighto (talk) 13:50, 5 November 2016 (UTC)

From shelter_type=* I think most standalone bus stops would have a shelter (even if just shelter_type=sun_shelter) whereas covered=* seems to suggest that the stop is situated in an area within a building with an open side.--Fernando Trebien (talk) 20:40, 8 December 2017 (UTC)

Bus stop with Drop-off only / Disembark only?

Is there a specific way of tagging stops (bus, trains, trams etc) which only allow for drop-off or disembark only? --Ascaaear (talk) 14:49, 1 May 2017 (UTC)

School Stops

Further to a 'drop-off-only' bus-stop, I have seen 'School Service only' stops. Some of these also had Naptan Codes. Although this should show up when a route relation is added (or not) to the stop, some special annotation or rendered colour would be useful to prevent the casual map-user waiting for a non-existant service. I would suggest highway=school_bus_stop. Any views? —Preceding unsigned comment added by NorthIsland (talk • contribs) 15:01, 28 December 2017

I guess you think of a "school service" as a private service, not accessible to the public? In my area school busses are public and common tickets are valid (in little village they may actually be the only service at all). There are other private services not available to the public, e.g. serving a factory. I would propose to use an access=private for the line, as the stop usually will be used by several lines, public or private. And one could a tag frequency=*, with values like "1/d" or "6/h" (one per day or 6 per hour). Sophisticated public transport maps could render private or seldom provided connections with thin or dotted lines. --GerdHH (talk) 13:40, 10 September 2018 (UTC)

Types of Bus Stop - Proposal

The above discussions on 'alight-only' and 'school' bus stops highlight my problem in that there are different types of bus stop. Not recommended to direct someone to a bus stop and find out that nothing picks up there. I undertand from the highway=bus stop wiki page that bus=yes may also be used. May I suggest that options for bus= should be (at least) 'yes', 'disused' (for disused stops), 'seasonal' (eg summer service only - could use eg 'Jun-Aug'), 'alight_only', 'school_only', and 'rail_replacement'. Will need some control over multiple options...--Iwhs (talk) 13:07, 24 July 2018 (UTC)

Request stop

Is there any tag (or more precisely: a relation role) to mark a "request stop"? This may include route variants, where the bus takes a detour only, if somebody is demanding for it. --GerdHH (talk) 13:45, 10 September 2018 (UTC)

Former bus stops

The following were added to the map by a bulk transfer from NapTan in 2009 (https://www.openstreetmap.org/user/NaPTAN) https://www.openstreetmap.org/node/502322941 https://www.openstreetmap.org/node/502322942 https://www.openstreetmap.org/node/502322937 https://www.openstreetmap.org/node/502333700 https://www.openstreetmap.org/node/502322944 https://www.openstreetmap.org/node/502334156

But these stops were for the Delaine Busses "Town" service, which was withdrawn in 2008, and have not been used since. See http://www.countrybus.com/delaine.htm for a reference.

I can find no way to delete them, so have put a note about the service withdrawal in the description, but it would make sense to get rid of them. There was never any infrastructure like signs at the locations.

Future / unused bus stops?

How do you tag a bus stop which has been constructed (there is a widening in the highway and a small paved area where passengers could wait) but which is not being served by any scheduled buses? This could be on a new highway, built to standards that require bus stops at major intersections. But any potential future bus service might be years away or might never come. Perhaps proposed:highway=bus_stop or disused:highway=bus_stop? Neither seems completely accurate. Semantically, it's not "disused" because it has never been used in the first place. -- T99 (talk) 22:58, 25 May 2019 (UTC)

The meaning of tags in OSM doesn't need to exactly match the meaning of the words used in the tag. I would use disused:highway=bus_stop since the infrastructure has been built, including a place for the bus to pull out of the highway and a paved area for passengers to alight, yet it's not being used. The definition of "disused:*" is "features that are in a reasonable state of repair but which are currently unused", so it doesn't matter whether or not they were previously used. --Jeisenbe (talk) 13:09, 29 July 2019 (UTC)

Status "de facto" or "in use"?

Resolved: Mateusz Konieczny (talk) 18:37, 22 August 2019 (UTC)

I just noticed you promoted highway=bus_stop (currently 2 409 422 instances) from in use to defacto. The reason for in-use was maybe that the tag is disputed (by some), because there is also an alternative tagging method with public_transport=platform and bus=yes (currently 844 200 instances). Not sure which is better in this case (personally I clearly support the de-facto status).--Dieterdreist (talk) 10:30, 29 July 2019 (UTC)

I thought that public_transport=platform should be used in addition to highway=bus_stop, not instead of, but perhaps I am mistaken? However, the existence of over 2 million instances and world-wide usage since before 2008 seems to merit "de facto" status, even if there is an alternative tagging option. In particular, highway=bus_stop is twice as common as public_transport=platform even though the later tag can be used for trains and all sorts of public transport modes, and has increased faster over the past year, according to https://taghistory.raifer.tech - it looks like highway=bus_stop and public_transport=platform both increased by 350k this year, so the gap isn't closing. Probably we need to decide on a more precise definition for when something is switched from "in use" to "de facto": how much importance should be placed on the existence of similar or synonymous tags? --Jeisenbe (talk) 13:12, 29 July 2019 (UTC)

There are at least some proponents who want to get rid of the "old" tag and look only at PTv2. It doesn't look as if they had (or will have) success in it.--

Yes, I've now read through some talk pages and I see there was a complicated history: the English mappers were using highway=bus_stop beside the road (at the bus stop sign), but then an unspecified "central European" guy started importing data that put the bus_stop on the highway. To fix the conflict, they made a complicated proposal with separate tags for "platform" (=bus_stop + railway=platform) and "stop_position", but unfortunately the new system didn't really make a clear way to distinguish between bus stops and railway platforms, or bus stations and railway stations! There was a tag bus=yes, but this has only every been documented for use with "stop_position", which being on a highway or railway node is the one thing that doesn't need it. The proposal specificially did NOT deprecate any existing tags, but now some wiki editors feel that they must deprecate the tags because we can't use both highway=bus_stop and public_transport=platform on the same feature, that's too complicate. No, we have to use public_transport=platform and bus=yes - which is 2 tags instead of 2 tags.

Aduh! (Indonesia for "Oy Veh!" [Yiddish for "Oh my!"]).

I think we should keep it as "de facto" and see what happens --Jeisenbe (talk) 14:54, 29 July 2019 (UTC)

agreed —Dieterdreist (talk) 21:43, 29 July 2019 (UTC)

Mapping as areas

Is there any reason to consider mapping highway=bus_stop on areas as incorrect? Yes, mapping on ways is about 300x times less popular but I see no good reason to consider it as a mistake Mateusz Konieczny (talk) 18:42, 22 August 2019 (UTC)

I agree, it would also simplify legacy tagging, allowing for setting the tag for platform areas. Rayleigh1 (talk) 14:26, 3 September 2019 (UTC)

Where would you place the area? I would think most of the time there is no way to tell the limit of a bus stop. Can you give an example? --Dieterdreist (talk) 15:29, 3 September 2019 (UTC)

On the public_transport=platform area, this would be a good way to keep legacy tags but also use the 2011 proposal. We could also contribute to developing PTv3 and make it extensively documented and detailed. Rayleigh1 (talk) 18:54, 3 September 2019 (UTC)

On the same area as public_transport=platform area (that is often mapped despite no clear boundary). See https://www.openstreetmap.org/way/234100234#map=19/50.06550/19.95151 that has no benefit whatsoever over simple node, but I would not consider it as a mistake worth complaining in validators (and someone else who mapped it apparently considered mapping it as an area as an improvement). And creating separate highway=bus_stop node is for me clearly worse than using highway=bus_stop on an area Mateusz Konieczny (talk) 07:55, 4 September 2019 (UTC)

I agree that if there is an area, using a node is worse. But if the bus stop is technically a point, a node is the perfect solution. Around here, bus stops are mostly points, so an area would worsen the situation, but I can imagine that in other places the situation might be different. If you use the area approach you should be aware that an additional stop position might be desirable, which on the other hand with the node is already implied and not needed usually.--Dieterdreist (talk) 10:36, 4 September 2019 (UTC)

And sometime there are well defined areas - for example special footway along road, sometimes with tactile paving and clearly distinct from the main footway Mateusz Konieczny (talk) 06:14, 21 October 2019 (UTC)

Well-defined (physical) bus platforms which can be mapped as an area should be tagged with highway=platform. Since it's not possible to use both highway=platform and highway=bus_stop on the same area, it's normal to still use a node next to the place where the front door of the bus usually stops (that is, the place where you should wait for the bus). I'm reluctant to support changing this, since the node makes it very clear where pedestrians should be routed to wait for the bus, and where they will exit the bus. If people are mapping areas for bus stops that do not have a real platform, this is not helpful since the area would not be verifiable and would not represent a real physical feature. --Jeisenbe (talk) 04:14, 19 January 2020 (UTC)

You're confusing two separate, independent tagging schemes. In OSM we map *physical* objects. The 'platform' tag is majoritively in the imaginations of those using it. It's employed as an excuse to justify the public_transport=stop_position tag which is purely a duplication of highway=bus_stop (& PT2 as a whole). It adds no quality to the OSM database. --DaveF63 (talk) 14:41, 18 January 2020 (UTC)

Yes, this is one of the big problems with using public_transport=platform for bus stops: it makes it unclear whether this is a bus station or fancy bus stop with an actual platform (highway=platform) or just a sign and pole stuck in the grass or dirt next to the road. --Jeisenbe (talk) 04:14, 19 January 2020 (UTC)

I meant cases like File:Bus stop with platform during night.jpg - it seems fine to tag here highway=bus_stop on area Mateusz Konieczny (talk) 14:40, 2 March 2021 (UTC)

Node in Sidewalk/Footpath Way?

Forgive me for my misunderstanding, all of the communication regarding the proper tagging and placement of the bus stop nodes is a bit overwhelming. From what I gather, it is proper to place a bus stop node as an individual point and not in a way that is highway=... . However, the main page of the bus stop does not indicate whether or not it's common or recommended for a bus stop to be placed in a sidewalk. This is relevant for my campus in which I'm trying to add bus stops to the footways. Recommendations? --IanVG (talk) 21:43, 7 July 2020 (UTC)

The highway=bus_stop node should be placed at the point where passengers wait to board the bus, normally at the location where the front door of the bus will open. Often there is a bus stop sign at this location. It will often be on a sidewalk/pavement. --Jeisenbe (talk) 23:06, 8 July 2020 (UTC)

@Jeisenbe: okay, so from how you explained it, it seems that bus stops should be connected to the nearest highway=footway whatever way if a pedestrian is immediately placed onto this path after they step off the bus. So do you think it would be appropriate to add this to the page? I think it will help with possible confusion on this tagging. --IanVG (talk) 04:18, 26 July 2021 (UTC)

There's no requirement to connect highway=bus_stop to highway=footway in the same way it doesn't need to be attached to highway=<road tags>. The bus stop node can be independent & should be placed at the location of the bus stop sign if there is one, or at the location the bus is expected to stop if there isn't.--DaveF63 (talk) 10:41, 26 July 2021 (UTC)

Great @Davef63:! I think you did a good job explaining that, thank you for the mental walk-through. --IanVG (talk) 13:32, 26 July 2021 (UTC)

Addition of a tag to indicate that a bus stop has a "platform"?

Where I live in the Toronto area, the most basic bus stops are simply a sign to indicate the stop and have no other infrastructure. Some others are simply a sign but do have a concrete "platform" area to facilitate bus boarding. Therefore, I believe there should be a tag to differentiate stops which do have a concrete "platform" and those without. I don't know the technical term for these "platform" things. Andrepoiy (talk) 22:13, 4 July 2021 (UTC)

There is highway=platform. maro21 16:11, 5 July 2021 (UTC)

It doesn't appear that these would be the same things I am referring to. I checked Toronto's bus agency website and they call them "bus pads", which are used to "allow the deployment of ramps to serve customers using mobility devices". https://www.ttc.ca/Service_Advisories/Construction/Bus_stop_improvement.jsp Andrepoiy (talk) 17:24, 5 July 2021 (UTC)

Platform=yes can be added to the highway=bus_stop node, or a polygon be mapped to indicate a *raised* pavement area using highway=platform (similar to railway=platform). --DaveF63 (talk) 11:15, 26 July 2021 (UTC)

How to Map Multiple Networks using Same Bus Stop

How generally should one map a bus stop that is used by multiple networks? I couldn't find anything on the network= tag page relating to this issue. --IanVG (talk) 20:58, 10 September 2021 (UTC)

This is a rather common issue, we have a few hundred multi-operator stops in my city (Brussels).

We use multiple values in the network=* and operator=* keys, separated with a semicolon.

A possible problem is when it’s the same stop but each operator names it differently (typically some minor spelling variation). We solved this problem in my city by setting the name=* as the main operator calls it, and using name:this_operator=*, name:this_other_operator=* for the other names. The obvious drawback of this is that anyone who would build an app that reads OSM data would have to be aware of that scheme.

Bxl-forever (talk) 22:04, 10 September 2021 (UTC)

I would add to the question: We might the bus stop with one name but two different ref number for two different routes. And example of such bus stops would be what we see in BRT lines with shared platform for two different direction. Should we draw two station or we can have one node with `;` separated values for ref, route,... Ahangarha (talk) 17:45, 2 January 2023 (UTC)

Exit only

Is there already a tag to indicate the stop is only used for getting 'off the bus? Martianfreeloader (talk) 11:10, 1 February 2022 (UTC)

In the bus route relation, you use "exit_only" as the member type for the stop_position. The highway=bus_stop node itself is not modified. Jengelh (talk) 11:43, 1 February 2022 (UTC)

Thanks. Martianfreeloader (talk) 11:46, 1 February 2022 (UTC)

To be precise: not "exit_only" but "platform_exit_only" on public_transport=platform and "stop_exit_only" on public_transport=stop_position and not "member type" but "role". maro21 18:40, 26 February 2022 (UTC)