[Talk-transit] NAPTAN database

[Peter Miller]

On 20 Feb 2009, at 00:00, Thomas Wood wrote:
>>
>
> 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.

makes sense.
>
>
>> 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.

That was what I imagined. It is just another user - we would however  
need to ensure we didn't loose the password for the user and have a  
protocol for using it.

>
>> 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.

I suggest we use the format naptan:xxxxx=yyyy for the actual data we  
import, and then derive content for the name field and ref fields from  
that data as appropriate, but the idea will be that anything within  
the naptan namespace is not changed from within OSM.
>
>
>> 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.

Would a simple way be to import all the new NaPTAN stops as visible  
complete stops, and add a tag to all existing stops to suggest that  
they are reviewed to see if they are duplicates or not?

We need to discuss this on talk-gb when we are ready for suggestions.

We could easily import by county given that the stops give an  
authority ID.

I would like Suffolk to be included in an early import if possible. I  
would need to check with David Earl and a few others in that area  
before confirming.


Peter
>