If #OpenStreetMap had an award for the most used tag for the sole purpose that something shows up on the map, highway=bus_stop would be a promising contender. The headline a common phrase in the German OSM community says just that: Mapping for the render engine.

I've been mapping for 3 months now and after finishing all the house numbers in my village POIs and Bus stops where next on my list and I had never been more confused.

highway=bus_stop is widely used to mark the position where passengers await for a bus service […] however there is not complete agreement within the community on this matter, and some users advocate using highway=bus_stop as a node within the highway=* at the place where the vehicle stops.

Great so what now? A 3rd opinion? What about the German Wiki entry:

This use is incompatible with the new public transport schema and should be avoided.

Proposed features/Public Transport

After reading through all of that I can say that there is one sentence above I stand 110% behind, the German Wiki:

This use is incompatible with the new public transport schema and should be avoided.

PLEASE support public_transport=

It doesn't matter if you are mapper or developer. But I especially appeal to all the people responsible for rendering map tiles, because I won't be able to get people to use public_transport=stop_position if it doesn't show up on the map. And thanks if you already do!

Right now the "or" basically means add public_transport=stop_position to highway=bus_stop if you like or don't, but not that you can use either of those with the same result.

The main reason I write this is because I hope more people will support and use the new schema as there have been several post in the German Forum over the last weeks and it was even discussed in the German Podcast 01:09:30 and the only thing consistent in all discussions is inconsistency.

Wipe off highway=bus_stop from the surface of OpenStreetMap!

...that's my personal opinion. Redirect the Wiki entry to public transport, replace all the tags in the database and remove it from every editor and render engine.

Could you elaborate that? So far the only problem I have found was the station tag, but that has nothing to do with highway=bus_stop, but rather with amenity=bus_station and railway=station.

way too complicated.

Set a public_transport=stop_position on the street, a public_transport=platform where the people are waiting and put them in a stop_area relation. The only thing I found complicated were all the inconsistencies, because this highway tag still shows up everywhere.

Yes it's more complicated than highway=bus_stop, but also covers a lot more. highway=bus_stop itself is already inconsistent, so while it's a lot easier you don't even know if it's a stop position or platform.

Also a lot of things in OpenStreetMap are complicated, but most multipolygons cause me much more headaches than this simple relation.

If I am to ask a newcomer to map a bus stop on OSM I am pretty confident that they would find highway=bus_stop a more obvious tag than the public transport schema.

Whereas the latter has received support in the the German community I think it is fair to say that such support is lukewarm elsewhere. The problem with this schema is that it is trying to solve a problem which does not exist in OSM: normalisation of a database schema. Having a common mechanism for tagging a concept of place where one waits for a public transport service is much more important IFF the data is stored in conventional tables in a relational database. In such cases we want to overload concepts (platform, halt, bus stop, taxi rank) so as to represent them in a clean as way as possible. The same applies if we have an application which wants to process multi-modal transport: generic objects and functions help a great deal.

However, overloaded concepts are not what we need in OSM for mappers. What we need are concepts which sit most comfortably with the implicit classifications which people use. Most of us treat bus/tram stops, railway platforms, airport gates, and taxi ranks as distinct. By keeping the core tagging as close to how people think about things naturally makes it easier for mappers because they dont need to look through elaborate wiki pages (with the title "Proposed" to further confuse them) or resort to tools like taginfo to try and disambiguate these usages.

Furthermore simple post processing rules to take highway=bus_stop, railway=halt etc and merge them for a particular application turns out to be really straightforward. We have lots of good tools for doing this too, notably LUA with osm2pgsql. Given that any public transport data need considerable post-processing before they can be used for generating routes there is little or no advantage to force mappers to do some of this work at the expense of greater cognitive complexity.

This is a fairly obvious example of a conflict in OSM tagging between the extremely particular and the extremely generalised (by analogy to taxonomy, one might refer to these tendencies as 'splitters' and 'lumpers'). The public transport schema is definitely an example of the 'lumpers'. There is much of great value in the schema, but as with many data schemas, the true art is learning that pragmatic choices must be made between the purity of the base conceptual schema and the nitty gritty of what gets used. Direct implementation of conceptual schemas often leads to unforseen problems, not least of which is that people tend not to understand them and therefore re-invent instances of the concepts. In other words if highway=bus_stop had not existed before the public transport schema, I'm sure that it or something very similar would have been invented anyway.

AndiG88: Yes, absolutely. The internal politics of OSM has poisoned public transport mapping and dissuaded me at least from contributing in the area .It is time to eliminate styles maintained by people not minded to work wither the public transport mappers from the transport mapping ecosystem.

Having a common mechanism for tagging a concept of place where one waits for a public transport service

Then why are 90% of the bus_stop tags here on/in the road and not at the platform where people wait?

What we need are concepts which sit most comfortably with the implicit classifications which people use. Most of us treat bus/tram stops, railway platforms, airport gates, and taxi ranks as distinct.

Then where is tram_stop? (Oh I just found it in the railway section. Great now I would have to read that when i start tagging the trams) Where is subway_stop? Also railway halt translates into all kind of things in German and the wiki even suggests merging it with tram_stop. When I have stop_position bus=yes, tram=yes etc. I at lest know that I just have to find the right ???=yes tag or leave it to the next guy, but I can always set the stop tag.

Look at a city like Munich: Straßenbahn(tram), U-Bahn(subway), S-Bahn(light rail - a translation which btw. nobody knows) and Eisenbahn(raiload).

So what is easier now: Setting a default public_transport=stop_position or figuring out if it is railroad/tram=stop/halt/tram_stop in the first place? Is there maybe a railway=subway_stop? Not to mention that trams often share stops with buses. 2 nodes? bus_stop with tram=yes? railroad_tram_stop with bus=yes?

These implicit classifications might be great as long as they work, but become a nightmare when the "lock-and-key principle" fails.

In other words if highway=bus_stop had not existed before the public transport schema, I'm sure that it or something very similar would have been invented anyway.

I doubt it. More experienced mappers would simple remove every redundant tag and overall as I said those stops are very limited and among the first things that were mapped.

There is a balance you have to strike when trying to develop a tagging schema.

If you make it so simple that it's obvious without having to look in the wiki then it many more people will help contribute data (and the map editors will be more likely to adopt it). Make it difficult, and you will reduce the number of people who are able to add the feature to the map. Worst still you end up splintering the way we map something.

Remember in iD tags are hidden. You mention the Opening Hours tag which is complex, but it could easily be added to iD (and other editors) via a really simple user interface. With such an interface, mappers will not need to know about the opening_hours tag. How should public transport be converted into a simple interface for iD? Stops as nodes on the way, platforms next to the way makes this task more challenging.

Oh and one of the things that has always concerned me about the tagging system is that the people proposing new tags (and this includes me) might not be experts and often we assume the changes we make are for the better. But has anyone ever bothered to stop and ask our current and future end data users?? Telenav? Bus companies?

If you make it so simple that it's obvious without having to look in the wiki then it many more people will help contribute data

Again are bus stops really something where you need a lot of beginners to contribute? My city had every stop I use and most nodes date back 4 years when you check the history.

How should public transport be converted into a simple interface for iD?

If you search for Bus it could show you Bus Stop and Bus Platform, then instead of placing highway=bus_stop, it places public_transport=stop_position and bus=yes. With the platform it just ignores the bus part and places a platform.

And if the user figures out to search for public transport it could list the things even better (like it now does with building)

Stops as nodes on the way, platforms next to the way makes this task more challenging.

How is highway=bus_stop better? Great it can be used for both, but do you really think that is what Telenav or Bus companies want? A tag that's not even 100% defined, so it can't even be fixed by an experienced mapper, because there is no right way to do it? Btw. here is actually a company using the public_transport schema, they even have their own mappers applying it.

Overall a user would be more likely to place the public_transport nodes correctly, because the schema presents him with 2 options: stop_position & platform. And platform is self explaining so it's easier to guess where stop_position belongs

Again are bus stops really something where you need a lot of beginners to contribute?

Yes. And I find it a bit rude that you think otherwise. Not everywhere has the level of detail of Germany and in my opinion we need all the mappers we can get.

How is highway=bus_stop better?

It's simpler. It's gives people the information they want (i.e. where is the bus stop for this side of the road). You only have to add one thing. When do you get a bus stopping somewhere other than right next to where the passengers are waiting?!

If I have a bus stop at X in the road, and the opposite bus stop is 10-20m further along the road then should I be adding 2 public_transport=stop_position tags? And how do we know which one relates to which direction of travel? You need to create a relation and add the appropriate stop_position for the direction of travel, right? If yes, then why not just do the same with highway=bus_stop and assume the stopping place is on the road adjacent to the bus stop?

Why is the stopping point even relevant to OSM? Only the bus driver needs to know this, so why tag for a single end user? Also, the stopping point for us bus is often marked as a rectangle on the road, so why only map as a node?

How should public transport be converted into a simple interface for iD?

If you search for Bus it could show you Bus Stop and Bus Platform

Fine, that gives you the options in iD but you still have to find a way to ensure they get used properly. For a new user (or infrequent bus stop mapper) they won't know that "platform" gets mapped to the side of the road, whist "stop" is as a node in the road. Add to this the language barrier that many of our mappers will experience then the chance of success will fall even lower. You'll end up with bad data in the public_transport tag. Perhaps then someone will create a new tagging system!!

There has been a history of unpleasantness from some opponents of the schema, for instance convincing mappers that their work will be wasted if they follow it. In some cases this may have been because they see this as acceptable collateral for undermining wiki discussions. At least everyone who has commented here is willing to engage.

It's simpler. It's gives people the information they want (i.e. where is the bus stop for this side of the road).

Mh no it doesn't. There is not rule where the place the bus_stop

And it gets even better when you realize what's actually in the Editor: .

Turns out that node you can see is absolutely useless. All the information is in the platform with a highway=bus_stop tag that isn't shown.

You need to create a relation and add the appropriate stop_position for the direction of travel, right?

No. You should make a relation in the new schema, but that relation isn't the important one. The route relation which gets the tag is what matters. Which is also my main argument why this is something that newcomers won't be able to easily map.

If yes, then why not just do the same with highway=bus_stop and assume the stopping place is on the road adjacent to the bus stop?

One of the main reasons we map public transport is for routing applications!

Why is the stopping point even relevant to OSM? Only the bus driver needs to know this, so why tag for a single end user?

Bus Driver = Bus = Software. Sorry, but did you really think we are just mapping things the end user can see on the map?

For a new user (or infrequent bus stop mapper) they won't know that "platform" gets mapped to the side of the road, whist "stop" is as a node in the road.

Where else would you map platform. The name literally says what it is. And if a newbie places the stop node beside the road where the bus stops it takes me 1 second to drag it on the road.

All you are doing is ranting over public_transport=, but not explaining how highway=bus_stop is better.

You say it is easier, but that's just because you can apply highway=bus_stop randomly to whatever you want. Every fault you point out in the new schema pretty much applies to the old one, too. And yes maybe people will use wrong values, but we can fix that. Every day dozen of people apply wrong and new values to the shop= tag.

Here in the West Midlands of UK, the highway=bus_stop is used in the same way by all mappers - the position of the bus shelter/pole.

I get the problem that the public transport schema is trying to solve, but if after 3 years the tag is not well adopted, then you have a problem. Personally I would start by making the wiki pages a lot easier to read (shorter, basic example, separate pages for buses, trams, etc).

I've often thought "wouldn't it be great if we could standardise X", but I've now come to realise a few things:

OSM is a big community. Getting everyone to change is near impossible.

Tagging schemas are only as good as the people who get involved in writing them.

Not many people read the wiki, the tagging mailing list, etc.

Change that is not well communicated risks damaging the community.

This isn't to say don't attempt it. I'm just saying, it needs to be with the community.

The route relation which gets the tag is what matters.
Which is also my main argument why this is something
that newcomers won't be able to easily map.

There is no reason why routes should be difficult to map.

Put yourself in the shoes of a newcomer. All the roads in their town are mapped. The corner shop is mapped. The church is mapped. The pubs are mapped. But the bus routes aren't and the bus stop isn't.

Why should we say "sorry, churches are easy to map, but bus routes aren't"? What sort of message is that to send out?

It is incumbent on people "designing" tagging schemes to make them approachable for the newcomer. If the scheme fails that test, it isn't fit for purpose. Your insistence that the public_transport tagging isn't suitable for newcomers is leading me to think it should be dropped entirely and replaced with something saner.

Here in the West Midlands of UK, the highway=bus_stop is used in the same way by all mappers - the position of the bus shelter/pole.

And here in Germany it is very common to put in on a node in the street.

Looking at taginfo you can see that it is frequently used with public_transport=stop_position Assuming most of those are correctly set all those bus_stops are on the street, ID does even have an icon for that which suggest that that is the correct use.

I get the problem that the public transport schema is trying to solve, but if after 3 years the tag is not well adopted, then you have a problem.

It doesn't help when it is not rendered on the map and the ID editor uses highway=bus_stop as default.

Personally I would start by making the wiki pages a lot easier to read (shorter, basic example, separate pages for buses, trams, etc).

I'm just saying, it needs to be with the community.

And that is my problem. Look at all the comments here. Everybody supporting highway=bus_stop How Am I supposed to clean up the wiki when we can neither agree on highway=bus_stop vs. public_transport nor if it is supposed to be used on the street or where people are waiting?

Meanwhile check out public_transport= and you get a very clean overview over the basic tags.

separate pages for buses, trams, etc

That whole purpose of the new public_transport system is that this is not needed.

Why should we say "sorry, churches are easy to map, but bus routes aren't"? What sort of message is that to send out?

Why? Because REALITY! Some things are easier to map than others. A railway network is more complex than a house.

What about the administrative boundaries? Those aren't easy to map either and might not exist in his town, I'd say on the same level if not more complicated than routes, yet they are successfully used all over OpenStreetMap. Are you questioning those, too? Has the whole boundary system failed? Should we just start using area=city with name=xyz instead of relations?

It is incumbent on people "designing" tagging schemes to make them approachable for the newcomer. If the scheme fails that test, it isn't fit for purpose.

Sorry, but that is a GIANT misconception.

Pretty much any kind of relation is not easily approachable for a newcomer. Some are easier some are more complicated, but in general you won't be able to do anything without a look into the wiki and even then you will spend more than a minute there. And that's perfectly fine, newcomers don't need to be able to map everything.

Start by cleaning up the public transport pages (leaving highway=bus_stop).

The public transport page on the wiki is an overview of the tags, yes, buts its data overload. It's trying to do all things for all users. In my opinion it would help if it was written as a quick reference guide:

here's how to map a bus stop (no more than 3 simple steps).

and for those folk who are interested, here's a link to the full public transport schema.

Pretty much any kind of relation is not easily approachable for a newcomer.

If that's the case, then that's a UI issue in the editors, and eminently fixable. The correct approach is to improve the editors.

Friendly advice: your consistent shouting, boldcase and headline font in all this is seriously detracting from the points of your message, especially when you're yelling at people who have more OSM experience than you do. Please calm down a little.

The new scheme is nice for complex cases, especially stop areas mixing several types of transportation (e.g. tram+bus). But this is painfully over-complicated for the ~95% simple bus stops. How can you convince newcomers that 2 nodes, 1 relation and 6 tags is "better" than 1 node + 1 tag ?

After multiple pages of monologue, some dialogue and smileys you have found out that:
* public_transport wiki page needs serious rewriting and improving.
* highway=bus_stop/railway=station/etc are easy to use by newcomers for simple stations.
* public_transport schema is needed for more complex stations.

Reality is that newcomers mostly use presets for tagging. So it would not matter if a simple bus stop is represented by highway=bus_stop or public_transport=stop_position + bus=yes.

For simple stations or not completly mapped complex stations those two tags are already enough to define a station. So only 1 extra tag to define a station on the same detail as previously (not 5).

//That small thing called rewriting of wiki page remains: Currently there is a lot of hard to read copy-paste text, missing examples, redundant network key (already defined by bus/train/etc. relations)

Until you realize that there are tram stops which don't include a bus=no, sometimes not even a tram=yes. And often the railway tags are on the track, not connected to the "bus" node.

By default you cannot 100% assume that highway=bus_stop is actually a stop just for a bus or even a bus at all.

Also the assumption "1 node where PT users are waiting" is wrong. As I pointed out in a comment above there are over 100000 bus_stops mapped together with stop_position. Which means probably most of them are on the road.

I pretty much share the opinion of the next comment here:

Reality is that newcomers mostly use presets for tagging. So it would not matter if a simple bus stop is represented by highway=bus_stop or public_transport=stop_position + bus=yes.

What I don't really agree with is that the public_transport= needs that much work. Some examples would be nice going to be working on that, but what matters are the tables and the mandatory tags.

The problem is the highway=bus_stop page, which as there are 3 different opinions (use it as platform, on the road or not at all) is pretty much impossible to clean up without upsetting a lot of people... I personally as I said would just put a redirect on public_transport, while others stand 110% behind the tag and probably would rather do it the other way round.

@AndiG88
As someone who has mapped a lot of bus tops, you are FUCKING WRONG!!!!!

There, how does that feel? Do you feel that my outburst has helped? No of course not.

In OSM there is no right way or wrong way, just the way that people like to use. Data consumers worth their salt understand this and consume multiple approaches. It is not too hard, so in the end it really doesn't matter. This scheme has caused much more hassle than it is worth.

Problem with public_transport is a birth defect : since its first porposal and during approval process, it was never clearly asking to deprecate "highway=bus_stop" for the simple reason that the new solution was more complex than the previous one for simple bus stops and the submitters knew they would fail in such way (by experience, all proposals starting with "depecrates this and that" are always slaped by responders).
The PT is nice for complex stations and multimodal connections. It's also nice when you map PT networks from the operator point-of-view. But it is too complicate for the simple contributor who just care about a simple bus stop/halt.
My proposal : keep simple scheme for simple stops, "bus_stop" for a bus stop, "tram_stop" for a tram stop. And switch to the PT scheme for complex/multimodal cases only.

Also the assumption "1 node where PT users are waiting" is wrong. As I pointed out in a comment above there are over 100000 bus_stops mapped together with stop_position. Which means probably most of them are on the road.

Your numbers are wrong. 1142673/1295234 (88%) of highway=bus_stop are not part of any way. Of the 12% that are part of a way, a reasonable portion of those will be part of a footway, not part of the road. There's a pretty clear standard usage.

This is consistent with the long-standing method of the node being at the pole location, not the the middle of the road.

In short, highway=bus_stop is the standard way to indicate the pole location of a bus stop, and will likely continue to be for the foreseeable future.