[Talk-transit] catching up

Peter Miller 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 mailing list