[Talk-transit] All about bus stops

Gerrit Lammert osm at 00l.de
Tue Jan 27 00:25:27 GMT 2009

Hi Christian.

Christian Krützfeldt wrote:
 > [...]
> Any maybe it could be a good idea to add all the individual tags into one relation and call it a bus stop plus give it the name of the bus stop.

I made a very similar proposal a couple of days ago. As you are not 
referring to it, I guess you are new to this list and didn't read it 
yet. So I will attach it to the bottom of this mail. You can find more 
posts about this from me in the archive of this list as well as the 
german talk-de archive (over the last 2 weeks).

Its basically the same approach as you had with other names (mostly for 
reasons of compatibility; will be rendered in current maps) for easy 

You can find an example of that scheme in the bus line 12 in Lübeck:
And a Kombination of tram and bus stops:
An example of usage in train stations can be found here:



-------- old post --------

I'm happy that the bus station problem is finally addressed properly.
I also tag the stops next to the road for now, but I came across many
problems in doing bus traffic simulations with this data and I think its
neither ideal for routing.

I came up with the following approach. It also works with rail-bound
traffic (Trains, ...):
a) Create Node with {highway=bus_stop} ON TOP of the way it belongs to.
b) Create Node with {highway=platform, shelter=yes, amenity=bench, ...)
NEXT TO the way at its actual position
c) create a Relation with {type=site, site=stop_area, name=[NameOfStop],
operator=[NameOfOperator], ...} and add all stops with "the same name"
to it.

In simple stops (one street, platforms on both sides) one Node with
{highway=bus_stop} would be enough. On crossroads or when the platforms
are far apart one could use more of these and define their
side-relevance with backward/forward-role like in route relations.

These {highway=bus_stop}-nodes would be the members of the bus routes,
making it easy to be used in simulations, whereas the
{highway=platform}-nodes mark the spot from a customers perspective and
can nicely be displayed on the map. In higher zoom-levels only the
relation could be displayed, avoiding clutter, while the individual
platforms pop up when zooming in.

easy-peasy, flexible and simple to set up. For the time beeing, we could
put the name tag not only in the relation but also on one
{highway=bus_stop}, so it will pop up in renderers even if they can't
handle the relation.

Most of the tools for this already exist.
highway=bus_stop, shelter=yes

site=stop_area is just an proposal, could be site=bus_stop or something

I tagged two example bus_stops this way. See here:

Summing up:
- clean separation between the logics ({highway=bus_stop}), what we
actually see ({highway=bus_platform}) and the metadata (relation)
- Easy transmission, old renderers will still show it right.
- customer/map-relevant features are considered
- routing/simulation/route-relevant information is there
- you might have 1-2 more nodes and a relation, but you can combine many
tags redundant in the current nodes (name, operator, ...) into the relation
- train stations could be handled in a very similar way, removing a lot
of trouble currently in this area
- {amenity=bus_station}, {railway=halt}, ... would also work perfectly
well with this

I'm looking forward to your thoughts on this.


More information about the Talk-transit mailing list