[Talk-transit] All about bus stops

[Peter Miller]

On 18 Jan 2009, at 21:23, Joe Hughes wrote:

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

Agreed, this is also the TransModel approach. I also suggest that as a  
guiding principle we should not burden contributors with the  
requirement to do additional work (such as adding an additional node  
in the highway) to make it slightly easier for downstream systems.  
These downstream systems can easily add nodes or whatever as they see  
fit.

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

In OSM we can add all of the roads that are used by buses (unlike with  
many car-oriented commercial datasets), and as such the bus stop  
should always be close to a way navigable by a bus. If the bus can go  
the 'wrong' way on a one-way street then the street should be tagged  
as such within OSM.

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

I suggest we use the TransModel 'logical grouping' approach which  
groups nearby stops into Stop Areas. As Joe says, these can be  
hierarchical with Stop Areas within Stop Areas. How this works in  
practice should become clearer as the NaPTAN import progresses.

There is a new CEN standard (IFOPT) which is used to describe the  
physical interchange elements: walkways, escalators, lifts, entrances,  
barriers etc,  but this is kept distinct from the logical Stop Points  
(bus stops, platforms etc) and Stop Areas (logical grouping of Stop  
Points) model. Only in the case of simple point features, such as bus  
stops and taxi ranks are these merged. GTFS rolls these two concepts  
into one for simplicity and only really uses the clustering for  
stations. In the UK (and in many other parts of the EU) every pair of  
bus stops across a road should be bundled into a Stop Area even though  
there is nothing to bind them together except their proximity. These  
groups of stop Points should normally share a common name and only  
differ in the indicator. A bus stop in the UK might have a common name  
of 'The White Horse' and the indicator for one might be 'opp' and for  
the other 'o/s' (standing for opposite and outside). When zoomed out  
there would only be one feature shown ('The White Horse') and when  
zoomed in then both features will be shown with information about  
their exact name White Horse (opp) and White Horse (o/s).

Here is an real example on Google Maps (which takes data from NaPTAN):
http://maps.google.co.uk/maps?ll=52.001865,1.111515&spn=0.000798,0.002052&t=h&z=19

In this case the registration between the bus stops and the road  
leaves a little to be desired. In OSM we could get the registration a  
little better

More comments in-line below

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

We could certainly add tags to the Stop detailing things about  
shelters and equipment. Personally I think information about which  
operators use the stop belongs in the schedule data (in the UK many  
stops are used by multiple operators and this can change frequently).

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

In the EU the guidance is to always create a Stop Point for each place  
where people can wait. these are then grouped into Stop Areas.

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

In the EU using TransModel there is the 'route' which pretty much  
matches our 'route' relation (a shape in GTFS). There is also a  
Service Pattern which is an ordered list of Stop Points at which the  
journey stops along the route.


Regards,



Peter



>>
>>
>> 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
>>
>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit