Hi If anyone is interested in joining a new OSM transit list, please sign yourselves up here:
http://lists.openstreetmap.org/listinfo/talk-transit I'm forwarding Peter Miller's message as per the request in its last paragraph. As he says, if you are interested in this subject, now is the time to get involved. I think it will be fun. AFAICS, official Australian transport information websites have a lot of catching up to do, so there's certainly a gap to fill. Cheers *** Begin forwarded message: Date: Sat, 10 Jan 2009 10:04:16 +0000 From: Peter Miller <[email protected]> To: [email protected] Subject: [Talk-transit] catching up 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. Regards, Peter _______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit _______________________________________________ Talk-au mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-au
