[Talk-GB] NaPTAN (stop) import

[Stuart Reynolds]

OK. Clearly I’m going to have to think on this for a bit longer. I think looking at somewhere like Swanley is a good idea, and also at somewhere like Derbyshire if the stops data hasn’t been imported there.

In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually!

Stuart

From: Marc Gemis [mailto:marc.gemis at gmail.com]
Sent: 01 August 2014 9:12 AM
To: Lester Caine
Cc: Talk GB
Subject: Re: [Talk-GB] NaPTAN (stop) import

In Belgium Jo Simoens has done similar things for the public transport import of De Lijn (Flanders) and Tec (Wallonia).
He has python scripts to compare OSM data via an external reference of De Lijn to updates in a Postgis DB.
He also has scripts to compute the most likely route  between bus stops. This information was not in the DB of De Lijn.

regards

m

On Fri, Aug 1, 2014 at 9:25 AM, Lester Caine <lester at lsces.co.uk<mailto:lester at lsces.co.uk>> wrote:
On 01/08/14 01:36, Will Phillips wrote:
> I do not believe the stop areas should have been imported at all because
> they are not verifiable on the ground. Also, I am often unable to find
> much logic in the groupings other than the stops are relatively close
> together, so I don't think they are really useful.

This is where having a unique ID for ab object comes into it's own. That
is if the data source allows you to access that data using it. All that
needs to be in the OSM data is 'bus stop' and it's NaPTAN reference, and
anything else comes from a secondary read. Although names and the like
may be worth duplicating.

Where a source of a data import is readily accessible, then we don't
need to duplicate the 'non-mapping' data. It may be for some imports we
need a private copy of the data to make this work nicely, but that
should be a natural part of the import process anyway. A clean copy of
what was imported.

What is available and easily accessible is growing daily ... but it does
not need to be all imported into one database :)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

_______________________________________________
Talk-GB mailing list
Talk-GB at openstreetmap.org<mailto:Talk-GB at openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-gb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20140801/9dc9aa10/attachment.html>