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