[Talk-transit] catching up
peter.miller at itoworld.com
Sat Jan 10 10:04:16 GMT 2009
First to say hello! I have only just joined the list and caught up on
the discussion so far. A few responses:
Firstly, I am glad that there appears to be a consensus on putting the
stop beside the way not 'in' the way. I also think this is the right
solution and incidentally it is the one adopted by the professional
community to allow them to use the stops data with different road
datasets (OS/Navteq/TeleAtlas etc) rather than being locked into one.
It also allows one to accommodate a change in bus stop location
without adjusting the road network. We should note however that we
normally put stations in the way (ie a node railway=station is a node
on a way tagged railway=rail) but that might be a separate discussion.
With regard to routes, there are two distinct concepts and I think it
is worth keeping them separate. The first is the order of stops that a
service calls at, and the other is the pieces of road (or rail) that
are use to move between the stops for the service.
In the EU (and elsewhere) the term 'Service Pattern' is used for an
ordered sequence of Stops that a vehicle will call at along its route.
However.... for long distance coaches this is not sufficient to decide
with certainty which actual roads will be used - for example there
might be no stops between Reading and Heathrow on a coach service. In
order to establish which roads are used there is the 'route', which is
a list of points that are called at where the number of points only
needs to be sufficient to unambiguously define the roads that are
used. In many situations all that is needed is the list of stops, but
in some cases a few additional points are needed where there is a
choice of routes on the ground between the stops.
I would suggest that we also adopt these distinct modeling concepts
and keep the term 'route' for the physical the path through the
network and use 'service pattern' for the sequence of stops. It would
make many professional in Europe very happy is we adopted this approach.
In our case we may define a route as being a sequence of ways (as we
do for cycle routes) although that might require us to snip ways at
points where the bus turns up a side road which wouldn't be required
if one used the points model and only cherry-picked nodes along the
route sufficient to do the job.
The inclusion of ordering in relations in API0.6 is of course a great
step forward and will allow these to be implemented pretty easily now.
With regard to bus stops then I think the NaPTAN import will be a good
exercise in sorting some of the tagging issues. I would encourage the
use of namespaces for some purposes - for example I suggest we have a
'naptan:' namespace to hold specific data that we imported from NaPTAN
in its original format and then use simple tags for the name OSM
concepts (a bit like was achieved with Tiger). For example NaPTAN has
three elements for the stop name 'Locality', 'Common Name' and
'Indicator' which can be used in different ways to construct a useful
name in different circumstances. We might want to store that raw
information as 'naptan:locality' 'naptan:common_name' and
'naptan:indicator'. From these will will then agree how to construct a
string to put in the 'name=' tag.
Before getting stuck into the NaPTAN import itself can we make sure
that everyone who wants to be part of it is subscribed to this list? I
will ask the people who have told me they are interested and also the
people who have expressed interest on the NaPTAN page. Anyone else?
Can I suggest people put out invites of their own national lists. I
will invite Joe Hughes.
More information about the Talk-transit