Talk:Tag:highway=bus stop

From OpenStreetMap Wiki
Jump to: navigation, search

New proposal (unified stoparea)

Unresolved: Can we just agree to let the db data resolve the issue for us and move on? Seems pretty cut and dried to me --achadwick 13:01, 30 November 2010 (UTC)

There's a unified stoparea proposal that could replace all of the public transportation stop mapping schemes. Please evaluate & comment on it.

Trying to change the meaning of highway=bus_stop (from the shelter/pole position beside the road to an virtual position on the road) seems likely to only cause confusion, disputes and incosistent rendering. Please use some other tag. Alv 12:24, 23 October 2010 (BST)
The buses I know in several countries stop on the road and not somewhere in the field beside the road. Some bus stops have bus bays, yes. But this is usualley only 3 meters from the center of the road. There is also a highway=platform that is interpreted and rendered correctly. It is where the people are waiting for the bus and where a shelter and so on can be placed. Usually beside the road. --Teddych 05:45, 24 October 2010 (BST)
The people I know in several countries wait on the sidewalk and not somewhere in the middle of the road, nor in the field beside the road; so that doesn't make the location on the road more worthy of the highway=bus_stop tag. And in everyday language people (that's mappers) refer to the pole or shelter with the bus stop sign as "the bus stop". Since the beginning people have described the bus stop with attributes such as shelter=*, ref=*, name=*, timetable=*, wheelchair=*, waste_basket=* and so forth, which all describe the physical structure for passengers. Even the unified stop area model, and models used outside OSM acknowledge that both positions are needed: the bus stop, and the stop point (you know, public_transport=stop_position). Not all bus stops have a distinct platform (even railway=platform acknowledges that, to which the highway=platfrom refers to for definition), and it describes only the walking area at the stop, not the stop itself. Alv 07:43, 25 October 2010 (BST)
For me a "bus stop" usually is the combination of two (sometimes more) stopping positions, two (or more) poles and if shelters, benches and so on. All this is one bus stop with one name (in all proposals this would be the relation). When I understand correct, you reduce a bus stop to mainly one pole (with a shelter, bench, ...).
Another thing I do not understand: You are writing people wait on the sidewalk. A sidewalk usually belongs to the road. So in OSM-terminology people wait on a road with a sidewalk. Where is the difference now?
The third thing: How would you map a bus stop that only has the yellow lines on the road, but no bus bay, pole, shelter, ... We have this outside in the country (but not in cities). I also know cities in developing countries where a bus stop is a completely virtual thing. There a bus stop is a where the driver stops. No pol, no lines, nothing. --Teddych 12:49, 25 October 2010 (BST)
In the end the sidewalks will be mapped as separate highway=footway ways. I finally found some minor cities in Germany where they've followed that advice, but that's only less than 1 out of 10 places in Germany. Seems someone has very recently and without any discussion edited the wiki to recommend such practice there. Major changes to tagging should be first discussed in the tagging mailing list and in English - or at least somewhere. There was some unfinished discussion in the distant past about "hail-and-ride sections", which seems to be in a way equal to totally unmarked bus stops. Alv 13:57, 25 October 2010 (BST)
Nice work in Helsinki. But I think on most places this will be still a long way. An I personally think it does not make sense. --Teddych 15:04, 25 October 2010 (BST)
I moved the stuff about unified_stoparea further down the page and clearly labelled it as a "proposal", but was tempted to just remove it. This page is established tagging documentation. Not really the place for adding new proposed ideas.
After much discussion (several years ago) most people are placing highway=bus_stop nodes off to one side of the way. If you want to change that you'll have to persuade many thousands of mappers that they've been doing it wrong for the past few years. As Alv said, a better idea would be to devise new tags to represent the things that need representing for this scheme
-- Harry Wood 10:18, 25 October 2010 (BST)
You would partially have my understanding when you would remove the unified_stoparea. Yes, because it is only a proposal. No, because the main content of the whole article differs quiet a lot between English and German version. The German version defines the bus stop on the way, not beside. I did not translate the german to english, I only added someting to the english version that was basically state of the art in the german version. --Teddych 13:10, 25 October 2010 (BST)
Aha interesting. So there's a difference between german and UK mapping, and a difference between the language versions of the tag docs. Of course these are self-reinforcing. Would be interesting to just confirm this state of affairs with a map of bus stops on ways vs bus stops off ways. Is everyone mapping them on the ways in Germany? or was this introduced recently? -- Harry Wood 13:20, 25 October 2010 (BST)
Germany (and therefore also German part of Switzerland) has very different mapping models (bus stops). There is Oxomoa, unified_stoparea, the so called reasently used practise and perhaps others. The reasently used is off the way, unified_stoparea is on the way and Oxomoa sets as compatibility also on the way. I did not count, but wherever I map I find bus_stops on the way. Alv said 1 out of 10. In Switzerland I guess it's 30-50%. --Teddych 15:04, 25 October 2010 (BST)
OSM works best when the community reaches consensus about how to tag. Handing down dictats by fiat is likely to meet resistance, not least because it is likely to mean that 99% of existing tagging does not accord with the wiki. The wiki is for documenting how tags are used, NOT FOR ORDERING PEOPLE HOW TO USE THEM. Europe now has about 550,000 highway=bus_stop, of which 204,356 are in Great Britain, many imported from NaPTAN data according to the side-of-the-road/location of pole or sign convention. As a proposal this asks OSM contributors to change in excess of half a million objects in Europe alone. There has been a considerable amount of discussion on talk-transit, on the wiki, on IRC, and in country-specific lists, on this and related subjects for the two years I have been involved with OSM. Furthermore various suggestions have been made by transport professionals closely involved in the development of national and european data models (e.g., User:PeterIto). This proposal seems to ignore all prior discussions (except possibly ones in German) and fails in consensus building, compounded by ill-considered wiki edits. Another point is that the pole location is eminently amenable for verification (see Verifiability), whereas the stopping locations of buses is not as straightforward. SK53 14:49, 25 October 2010 (BST)
Mappers in Germany are mapping highway=bus_stop on the way since arround early 2009 (or longer). The german wiki was updated to this handling in 2010, one year later. So it definitively was not to order people how to use, it was a documentation on how (german) people really use it. For me PeterIto's Stop Place is only one out of many ideas. And by the way only a variant of Oxomoa's Proposal. A variant I did not see in OSM yet. Teddych 13:59, 26 October 2010 (BST)
Why would someone recommend changing the practice? The practice of using the location of the pole/shelter predates any of the more comprehensive information schemas. "PeterIto's Stop place" only acknowledges that the bus_stop has been used, and would be used at the pole/shelter. Seems that no other part of the oxomoa or unified stop area conflict with the older way. Alv 14:40, 26 October 2010 (BST)
It is a need, that the mappers are able to map a bus stop more exactly then only one node for the pole. This is shown by the multitude of proposals. There are two things that get rendered properly: highway=bus_stop and highway=platform, but no other tags (AFAIK). The platform is definitely beside the way. So it is obvious to redefine highway=bus_stop as the stopping position to represent the second important point of a bus stop. This is how I would answer your question. Why others (especially German community) changed the practice you have to ask them yourself. This was before I started to work on OSM. Teddych 08:12, 27 October 2010 (BST)
As a German mapper, I cannot confirm "Mappers in Germany are mapping highway=bus_stop on the way since arround early 2009 (or longer)." other that it means "Some mappers ...". In the places I've been mapping bus stops have been near the road all the time. However, in some places it was migrated to "on the road". When I was a beginner, I read the wiki and found the pole position an obvious way to tag. And since you can easily infer the stop_position on the road from the pole, and because you can not vice versa infer the pole position from the stop position on the road, it should be obvious that bus_stop should not be redefined. kay_D
You think you can infer the stop_position form the pole. But this is not through. I know several bus stops where the pole/shelter is before or after the bus bay. What about bus stops with two or three stop positions and only one pole/shelter? Teddych 11:19, 27 October 2010 (BST)
What of those roads which don't use bus bays or marked positions? Best to mark the physical location of the marker - if present - as a Nodehighway=bus_stop (because that's the most common worldwide usage now) and the location of the marked bus bay - if present and physically distinct from an ordinary kerb - as a Node or Way public_transport=stop_position? --achadwick 13:01, 30 November 2010 (UTC)
Also, routing software generally performs pre-passes to generate its internal routing graph, as I understand it. In the absence of more exact information, just associate the pole position with the nearest way in the route relation, at the nearest point, and call that a stop_position (inferred). --achadwick 13:01, 30 November 2010 (UTC)
kay_D: I found the exact opposite obvious when beginning, to be honest, but I've switched to off-way Nodehighway=bus_stop because we should be mapping physical objects primarily. My experience may have been driven by exactly where in the discussion I stepped in, of course - perhaps yours too? There's been a *long* to and fro about this. Can we have consensus please? I vote for Alv's method below. --achadwick 13:01, 30 November 2010 (UTC)
With a little help from more skilled awk users, I managed to analyze the germany.osm.bz2 downloaded today. In that extract, out of the total 134 351 nodes tagged highway=bus_stop, only 25 564 (19,02%) are part of any ways. That is hardly the common way, especially if they've been doing it for so long. Change those to public_transport=stop_position and survey the location of the pole/sign/shelter, OK? Alv 13:21, 27 October 2010 (BST)
Definitely. Seconded. Suggest we use the existing and widespread pattern of Nodehighway=bus_stop positioned to the appropriate side of the way for the physical location of the stop (and any associated shelter, initially). Bind the way, the stop_position, poles, road markings, bays, shelters, whatever together in a route relation, and have done with it. --achadwick 13:01, 30 November 2010 (UTC)
You showed your opinion on unified_stoparea. Do you have such a clear opinion on oxomoa's schema? --Teddych 15:35, 30 November 2010 (UTC)

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

Rendering of bus stops

Resolved: Both on-way and off-way are rendered. Semantic differences are still being discussed, but elsewhere --achadwick 11:29, 30 November 2010 (UTC)

It seems bus stops which are not part of the way are not rendered in openstreetmap or informationfreeway. However both do render bus stops which are part of the way. This is in contrast with the way bus stops are most commonly tagged as described by Bus_stop. Making a bus stop not part of the way would make it easier to visually spot which direction the stop is into, but obviously this doesn't work if the bus stop is not rendered at all. Are there plans to make both styles of bus stop tagging rendered, or should bus stops be tagged as part of the way as in the second proposal above? --Jkp 15:05, 18 May 2008 (UTC)

Bus stops do get rendered if the node not part of the way. In both Mapnik and Osmarender. Example:
I don't know why you're under the impression they dont get rendered. Maybe you're setting the tag wrong, or maybe you're not waiting long enough for the map to be re-rendered.
-- Harry Wood 16:04, 18 May 2008 (UTC)
OK, I stand corrected, they do get rendered as shown by your example. Some of the ones I've added (like all bus stops not part of ways) didn't get rendered, though. When comparing the above to the ones I've tagged, the only difference I see is I have used "source=survey" in addition to "highway=bus stop". If I understand Map_Features correctly, source=survey is correct usage for nodes as well as ways or areas. But now when I look at the nodes I've tagged with source=survey (like a convenience shop), it seems some of them haven't been rendered, when ways I entered later than those have been rendered. Some have been rendered, like amenity_parking, so I'm confused. Or maybe I'm just forgetful about when I have added what, as you suggest. Anyway, I'm now checking with removing source=survey from some of the tags and asking for a new rendering to gather some more data. --Jkp 20:10, 18 May 2008 (UTC)
I ruled out being forgetful about when I have added what. An example: yesterday I added a mailbox and bus stop next to each other, both with source=survey, tags being highway=bus stop and amenity=post box. I added both with potlatch. The mailbox is rendered at http://www.informationfreeway.org/?lat=60.24392840216323&lon=24.65566641775273&zoom=17&layers=B000F000F but the bus stop is not. What am I missing? --Jkp 09:43, 19 May 2008 (UTC
Correct tag values are bus_stop and post_box, with an underscore and not a space. What potlatch shows as the available shortcut (post box) is not necessarily what it puts in the tag value (e.g. post_box which has been rendered). Alv 10:06, 19 May 2008 (UTC)
Maybe it's the coding of space vs. underscore what I'm missing? Potlatch shows the tag for post box as "post box", so I've assumed that I can code the tag as "highway=bus stop". But Potlatch doesn't offer bus stop as a selection for tag highway, and I see things like amenity=bus_station in wiki, so should I type the bus stop as bus_stop? --Jkp 09:56, 19 May 2008 (UTC)
OK, that's it, problem solved. I typed "bus stop" when I should've typed "bus_stop". The two are almost indistinguishable when just looking at them in Potlatch - in the example above, Potlatch shows the tag as "bus stop", not "bus_stop". Now when I look at it closely, bus_stop shows a slightly wider space between the characters, but no underscore. When I cut&paste, the difference is clear. --Jkp 10:31, 19 May 2008 (UTC)
That's some local or version issue with potlatch/flash/system, on mine and likely most other systems users can clearly see if there's a _ or a space in a tag value. Alv 10:41, 19 May 2008 (UTC)
Seems to be a font issue on the gnome desktop (with firefox as well as konqueror), the letters don't fit into the box allocated to them, g's lower part is absent as well as the underscore. --Jkp 11:20, 19 May 2008 (UTC)
What is the general consensus? Should we tag highway=bus_stop together with left=*/right=*, should we tag highway:left=bus_stop/highway:right=bus_stop? Or should we use a separate node, even if the bus stop is part of the main lane of the road? --Skippern 15:41, 22 February 2009 (UTC)
These days, I make a separate node at the physical location of the sign or the shelter, and make it part of the relation (with a blank role). Same as you do when adding a post box or a telephone kiosk. Let the physical location determine which way the stop is "on". The fact that both will exist in the same relation is a helpful hint! Documenting what I do right now at User:Achadwick/Mapping style. --achadwick 19:19, 22 February 2009 (UTC)
My point is that if the node is on the side of the road, it will be missed by routing software, and if the bus stop is in the lane of the road and not a designated pocket at the side of the road, a warning or notice in the router might be desired. Besides, this node at the side of the road should be connected to the road itself in some way, how do you do that? Service road? --Skippern 11:24, 24 February 2009 (UTC)
I think the consensus is as achadwick has described. The node is off to the side of the road, and (for the benefit of future routing software) linked to the route via a relation.
We had plenty of other tagging ideas discussed in the past. Many of those discussions pre-dated relations. These days if anyone wants to implement hybrid pedestrian->bus routing (and I don't think anybody's done it yet), then all the data is there. The bus stop is associated to the road by means of a relation. No real need to connect the bus stop to the road in any other way. -- Harry Wood 14:34, 24 February 2009 (UTC)
there still seem to be some problems with this approach.
1. i think, it is important to know where the bus actually stops - for example, if the bus stop is on the corner, exactly the same distance from both ways, is the bus stop located before the turn or after ? what if bus route goes past a bus stop in both directions at the same distance (like bus entering town, then leaving it), how would routing software have any idea which direction this stop is on ?
2. most often, when tagging bus stops, i have no idea what route goes there. mapping them is still important, because they serve as location markers, often being named after house or populated place.
3. imagine a case where a named bus stop does not belong to a bus route anymore. it's still a useful for navigational purposes - let's say you come out of a wood, holding a printed osm version ;) - seeing the named bus stop immediately allows you to know where you are.
thus i believe bus stops should be connected to corresponding ways where the bus itself would stop. they can/should still be added to route relations, but noting actual road connection is important. now, how to do this - currently i'm connecting them with untagged ways, which seems to be a bit bad. should these helper ways be tagged to help routing software, maybe ?
--Richlv 11:49, 18 April 2009 (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 {..., Way for stop N, Node 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)

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

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)

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

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... ;)

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:

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)