[Talk-transit] How to map named bus stop platform/positions

Steven Chamberlain steven at pyro.eu.org
Wed Sep 1 22:27:25 BST 2010


On 31/08/10 19:17, Magnus Bäck wrote:
> In the Skånetrafiken public transport network in southmost Sweden, bus
> stops are identified not only by name but also by a capital letter that
> identifies this particular platform (or stop position, if you will). In
> most cases you have an "A" platform for one direction and a "B" platform
> across the street for buses heading the other direction.


Hi,

It sounds exactly the same in my region (Redcar & Cleveland, United 
Kingdom), except numbers are often used instead of letters.  Stops at 
the same location often share a common name, eg. 'Market Place' but with 
a 'Stand 1' and 'Stand 2' on opposite sides of the road, for travelling 
in different directions.

Where there are many stops at one location along a stretch of road, 
stops are numbered or sometimes lettered, and you must wait at the 
correct stop for your bus service.

My local authority has entered these 'stand identifiers' in the UK-wide 
database of stops (NaPTAN) as 'Indicators' and during bulk imports to 
OSM, data from this field is imported as 'local_ref=*'.

I'm not sure if that's the best attribute to use.  But I certainly don't 
like the idea of textualising details like 'Stand 1' or 'West-bound' 
within the 'name=*' tag, because I feel that sort of data should be 
stored 'atomically', as a separate attribute, to make it simpler to 
query and process.  A renderer or application is then free to textualise 
the data later in a way that seems appropriate.

I'd expect a renderer to display stand identifiers at their exact 
location, and the area around them labelled with their common name. 
When zoomed out, it would only show the name and perhaps a single dot, 
looking more like a schematic route diagram.

Is there a recommended attribute to use for stand identifiers, or are 
stop area relations being used to achieve this instead?


ps., on a more general note...  I hope that OSM, and free software and 
services built on free data, aimed at public transport operators and 
authorities, can someday influence and standardised the way things are 
done in the real world.  I think a lot of aspects of the design and the 
vocubulary regarding stops, routes and even pricing/ticketing is often 
borrowed from whatever software being used and the features it has. 
Giving the operators good, open-source and standards-based programs and 
services to work with, may nudge them towards a simpler design avoiding 
many of the incompatibility issues being brought up on Talk-Transit. 
That's something I hope for, anyway.

Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org



More information about the Talk-transit mailing list