[Talk-transit] All about bus stops

Hugh Barnes list.osm at hughbris.com
Sun Jan 18 00:23:37 GMT 2009

On Sun, 18 Jan 2009 00:12:07 +0100
Gerrit Lammert <osm at 00l.de> wrote:

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

Sounding good.

My only possible issue is with the names used. This can be worked on. I
think of a bus stop as the platform, but I probably shouldn't. Perhaps
Peter Ito can tell us what terminology the professionals use for a) the
point on the road where the bus stops, b) the "platform" or waiting
area, c) the "zone" ?

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

I would prefer this was not a shorthand like this. You lose a lot of
what you claim are advantages below. Also, what about features (shelter
etc) on one side but not the other?

> 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
>     http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop
> highway=platform
>     http://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform
> relation:type=site
>     http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
> site=stop_area is just an proposal, could be site=bus_stop or
> something else.

OK then.

> I tagged two example bus_stops this way. See here:
> http://www.informationfreeway.org/?lat=53.90052281215579&lon=10.741871099180775&zoom=17&layers=B0000F000F
> 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

It seems a pretty neat model on the whole. Well thought and well


More information about the Talk-transit mailing list