[Talk-transit] All about bus stops

Joe Hughes joe at headwayblog.com
Sun Jan 18 21:23:15 GMT 2009

Thanks for contributing a concrete proposal, Gerrit.  At this point
I'm not familiar enough with OSM metadata practices to comment on
those particulars, but here are some general thoughts.  Hopefully
Peter Miller and/or Nick Knowles will also chime in from a
TransModel/UK perspective.

1) Hopefully, whatever scheme we end up with will encourage placement
of stop points at the location where riders should wait, rather than
the middle of the way.  When a stop ends up shown in the middle of an
intersection, it can be a confusing process for a rider to determine
which corner they're supposed to be standing on.

2) Bus stops don't always occur on public roads.  Most often this
happens when the stop is in a shopping center parking lot (the nearest
thoroughfare is often a significant walking distance away), but it can
also occur with bus-only ways (Pittsburgh, PA busways and Boston's
Silver Line) and other oddities like bus-only lanes going opposite the
normal flow of traffic on a one-way street.

3) It is generally useful to be able to group individual stop points
into a parent entity, as this can be used to reduce visual clutter on
a map.  Typical use cases would be for bus and train stations with
many platforms/bays, as well as stop points that are roughly right
across a street/intersection from each other.  TransModel allows
arbitrary levels of nesting, while GTFS has a one-level mechanism for
grouping "stops" into a parent "station".


On Sat, Jan 17, 2009 at 3:12 PM, Gerrit Lammert <osm at 00l.de> wrote:
> Hi.
> 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
>    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.
> 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
> I'm looking forward to your thoughts on this.
> Gerrit
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit

More information about the Talk-transit mailing list