[Talk-transit] NaPTAN bus stop database

[Thomas Wood]

2009/2/22 Brian Prangle <bprangle at googlemail.com>:
> Hi everyone
>
> Thanks for all the contributions - there's obviously still a lot to discuss,
> agree and clarify.  I'm keen to crack on and get some agreement on what I
> think might be the easy decisions.
>
> 1. Everything imported should be tagged NaPTAN: whatever the NaPTAN
> fieldname is  (except we might want to shorten some of the longer and more
> obstruse names- any comments on this?) = value in NaPTAN.  This follows the
> TIGER pattern in the US and makes explicit what the data is. I think we
> should adopt the capitalisation structure of our data donors ;-)

Yes, this is already implemented in the code, except using a prefix of
naptan: (lowercase), we do adhere to the NaPTAN field capitalisation.

> 1a - we can decide later if we are going to add the OSM tag highway=bus_stop
> (or whatever the taxi one is) as part of the verification process with
> existing OSM data

Currently defaults to adding, but is easy to change, I'd prefer the
default add option, since it's easier to remove data than to find
missing unrendered nodes, more on this later.

> 2.No-one seems to object about creating a user NAPTAN ( or should that be
> NaPTAN?) to do the import
> 3.We'll include taxi ranks but nothing else in this first phase
> 4. I'd like to methodically work down the list of  NaPTAN fields in
> http://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings and agree on what we
> can omit. I've annotated what I think should be  omitted (labelled "N/A BB"
> ) for the first 4 tables under the NPTG section. (Thomas - I don't
> understand your comment in the wiki page about this data not being suitable
> for import - if you can explain and we can agree it's not then we can just
> ignore it - but I think Peter has some form ideas about the usefulness of
> this data). Can we concentrate on discussing and agreeing this over the next
> week (or more quickly if it's not contentious) - then we can move down the
> list.

Yes, this is the aim of the table, so far I've been the main
contributor. I'm kinda refusing to add more myself.
Much of the NTPG data is for the administration of the NaPTAN data,
the only really useful stuff is the Localities, but I'd hesitate about
importing that, since as noted it looks heavily derived from OS data
(yes, we have permission from the DfT, but the explicit noting of OS
as the source field is worrying me still.)

> 5. Any field that is identified as optional I've omitted by default, as
> presumably some regions/areas will have them and others won't

Optional means optional in the NaPTAN data, it may still be worthwhile
to import if the data is present.
I'd recommend against putting a N/A just because a field is optional.

> 6. Towards is not in the NapTAN data and is a local OSMer decision ( Andy
> always tags these, I'm a bit hit-and-miss

I've never tagged towards personally, I'll leave that to the route
(relation) layer of data to handle.

>
> Questions/thoughts
>
> 1. Taxi ranks : can someone explain the difference between a taxi rank and a
> shared taxi rank (shared with what?)
> 2. Fields which are described as location 3+ - what are these?

Ignore any fields described as 'Location object' or similar, these
imply more complex geometry types, so are inherent in the OSM
database. 3+ indicates the minimum number of points for a polygon to
be formed.

> 3. Ref numbers NaPTAN vs local. Lots of discussion and examples around this
> one and I'm still confused. But I think it will resolve itself if we import
> AtcoCode, NaptanCode,and PlateCode(even though this one  breaks my rule of
> being an optional field). Then any OSMer-generated data using ref or
> local_ref (i.e what's seen on the ground) can be kept and OSMers can keep
> collecting such local data.

I've not yet seen PlateCode filled anywhere. (Of my sample of 4 counties).

> 4. Thomas - do you agree that Christophe's time would be better spent on a
> Dracos-style data analysis tool?
> http://www.dracos.co.uk/play/locating-postboxes/

Yes, I've talked to him about this, he seems to think this is the best
way to use his time.

> Regards
>
> Brian
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>
>



-- 
Regards,
Thomas Wood
(Edgemaster)