Peter Miller wrote: >Sent: 20 February 2009 8:49 AM >To: Thomas Wood >Cc: talk-tran...@openstreetmap.org; Talk-gb-westmidlands@openstreetmap.org >Subject: Re: [Talk-gb-westmidlands] [Talk-transit] NAPTAN database > > >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.
Yes, I would agree, forming a username NAPTAN is logical. If the password is ever lost SysAdmins should be able to insert a new one into the db. > >> >>> 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. We can't enforce a no change policy and anyone can delete a NaPTAN data entry. We have not possibility of stopping that. Of course we have the history of changes and can reinstate a deleted item but we cant "lock" the data. >> >> >>> 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? I believe this should be a community decision in the areas being imported. For the north Birmingham area I would prefer the NaPTAN data to be silent until I turn it on. I have a large number of bus stops already mapped and it looks like the data on the bus signs might not match what's in the NaPTAN database. If someone was clever enough to do a http://www.dracos.co.uk/play/locating-postboxes/ type approach then it would be easy to see which stops have been verified and which haven't. Though I accept that might be a tall order, or a challenge for someone! :-) > >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. Maybe ok, but is there any further subdivision? Importing the whole of Yorkshire for example is making a big assumption on what the community wants in each of the big cities. > >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 >> > Cheers Andy _______________________________________________ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
