[Talk-gb-westmidlands] [Talk-transit] NAPTAN database

[Thomas Wood]

2009/2/19 Brian Prangle <bprangle at googlemail.com>:
> Can I propose that we carry on, on the basis of:
>
> 1.we include onstreet and offstreet bus stops

The current implementation in the converter doesn't care about
On/OffStreet distinctions, it just matches against point type.

> 1a. understand Peter's point about node imports (taxi ranks, station
> entrances etc but I'd still like to leave that until later)

I think we could get taxi ranks in at the same time, but I'd like to
leave out airports/rail/tram/tube for now, since they're going to be
more complex to integrate with the existing data.

> 2.create a user NAPTAN as suggested by Peter ( how do we do this and who does it?)

I guess whoever is nominated to do the final import will be the one to
actually create the user &c.

> 3.use the wiki page NAPTAN/import to indicate whether to include/exclude a
> field - we can worry about tagging later - at this stage we just need to
> decide do we need the field or not - needs an extra column in the wiki
> table/ re-label the OSMtag column (Thomas?).

(Its NaPTAN/Tag mappings btw) If we're deciding not to import a field,
just mark as N/A. I rewrote the Bus/Coach section today, see
http://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings#Bus.2FCoach

> We can discuss/justify disagreements here in talk transit. Are there any
> dire consequences of just importing everything except the obvious fields(
> already indicated in the wiki page NAPTAN/import)- database performance/
> disk capacity?
>  (Peter what is the precise agreement with Traveline as to the extent of
> what we can import?)
> 4. Thomas - it seems you already have a dataset to work from and a pretty
> good importer prototype from the example you sent me of Birmingham
> International.

Image examples are available on my flickr page, the converter code is in SVN.
http://flickr.com/photos/grandedgemaster/3291991006/
http://svn.openstreetmap.org/applications/utils/import/naptan2osm/
I got the data from the NaPTAN website, using the "information system
suppliers for the purposes of product development" clause of the
license there as an allowance for testing the converter.

> 5. Once we've decided what to import, I think it would be a good idea to
> offer that to talk-gb to see if anyone wants to challenge/change it. Can you
> estimate how much more needs to be done - is Christophe up to speed with any
> of this?

He sent me an email regarding the progress I've made, I've sent two
replies, but not heard any more from him.
I don't know how we're going to do tidyup, whether it should be
pre/post import, how we go about checking the data etc...

> 6. Whilst that's going on we can decide on tagging structure ( might want to
> look at how TIGER data is tagged?)

Its already been decided by the way that imports are done that any
import-specific tags are placed under a 'namespace', naptan: has been
decided by either myself or Peter (I forgot who first put it on) on
the Tag mappings page on the wiki.
Other OSM tags are being decided on that page, it's what I've been
implementing the converter against, and I've been updating it as I've
been inventing tags whilst writing the converter, too.

> 7. Then we have the thorny question about how the import gets compared with
> existing data:
>
> Intial thoughts:
> a. Do we need to worry about misalignment with existing ways? Probably not,
> but would like confirmation
> b. Do we need to worry about stops where there are as yet no ways? Probably
> not, but would like confirmation
> c. Do we initially not include the tag highway=bus_stop so they don't get
> rendered but suggest that OSMers on the ground add it once they have
> surveyed/confirmed the position, particularly with regard to existing stops?
> d. We could be more sophisticated and tag highway=bus_stop only where there
> is no existing bus stop within say 20m  (means extra coding effort),
> otherwise default to c
> e. Do we need to worry about the integrity of the data once OSMers start
> editing - do we need a "code of conduct" explaining what the data represents
> which other software might be relying on?
> f. following our test in West Midlands do we go for a big-bang import or on
> a region by region basis depending on OSMers local enthusiasm?
> g we need a process for updates- haven't got any clear ideas around this
> currently
>
> We don't have to nail any of 7  down at the moment but we need to start
> thinking about it. I'm keen we don't get too distracted from the initial
> task of deciding which data fields to import.

No idea about any of these, a-d I've not considered yet, doing
programmatic comparison of NaPTAN with existing OSM data is probably
beyond my skills.
e & g - Currently the import page says:
"The Department requires that the official identifier for each feature
is also included in the imported data to allow the movement of these
features to be tracked over time and for updates to potentially be
added in the future."
So, we'd have to ask people not to delete the naptan:AtcoCode tags.
I'm hoping that whatever uploader we use will keep a log of
internal->OSM ids, so we can easily keep an index of what we've
uploaded for rollbacks etc.
f - I guess we ask on talk-gb what people'd prefer.

> Clarification from those who know the NAPTAN schema better than me please:
>
> Currently the typical tagging of bus stops (from those who really care ;-) )
> in Birmingham follows the pattern here:
>
> Node 410393Details
>
> ref: 504974
> route_ref: 104;104A;105;110;112;115;902;904;905;915
> shelter: yes
> highway: bus_stop
> location: Birmingham Road;The Yenton
> towards: Sutton Coldfield
>
> All of which is visible from a survey. Additionally, some bus stops have
> names such as Acocks Green Village AB. I take it that all this information
> is available in the NAPTAN data

Routes, shelters, no. Towards, yes, to some extent - the bearing at
which the bus leaves is given.
Ref depends on where you are, in London, yes, but has to be parsed out
of the Indicator field, which may be of the form "Stop A, Stand A, or
A" code has been written for this.
Surrey has stuff present in the NaptanCode field, the converter also
takes this into account, Surrey uses free-form Indicator fields, to
say things like "O/s no. 15"
I've not yet run the West Mids data through the latest version of the
converter to see what it does with it/it looks like.
Names are in the data set.
I'm not exactly sure what you mean with your location tag, if it's
whats printed on the bus stop sign, then I've usually tagged as name.
Since the 'location' is inherent in the node positioning. However,
NaPTAN does provide data of which street the stop is on, and if it's
near a junction with another street.

>
> Sorry for such a long post - hope it makes sense
>
> Brian

-- 
Regards,
Thomas Wood
(Edgemaster)