Brian
My comments are shown below - I hope they are helpful Roger _____ From: [email protected] [mailto:[email protected]] On Behalf Of Brian Prangle Sent: 22 February 2009 22:01 To: [email protected] Subject: [Talk-transit] NaPTAN bus stop database 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 ;-) [rs] I understand your wish to be less verbose in your tags - and as long as the OSM tag is clearly an abbreviated form of the NaPTAN field name, I think this is unlikely to be an issue. 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 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 [rs] Perhaps worth noting that taxi rank data is not a key part of NaPTAN and completion rates for this are very low. 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. [rs] From my perspective the key to NaPTAN has to be AtcoCode - this defines the NaPTAN record, and is the code that is used for cross-referencing records within NaPTAN. I will look at the wiki to see what you are suggesting . there are some things in NaPTAN that are self-evident if the data is used within a mapping context (eg: street, crossstreet, landmark . these are in the database for searching purposes, and also to give a pointer in the choice of commonname and indicator. 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 [rs] "Optional" isn't necessarily the same as "important" . NaPTAN v2 is still in the form that was launched when authorities had to migrate their data from v1 to v2 - so we were unable to make various fields mandatory at that point as v1 data could not be imported against the v2 schema. Having said this, though, I think it is unlikely that many data items that are optional are going to be essential for OSM. 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 Questions/thoughts 1. Taxi ranks : can someone explain the difference between a taxi rank and a shared taxi rank (shared with what?) [rs] There are two modes - "taxi" is a vehicle exclusively hired by one person or party of travellers. "Shared Taxi" (there aren't many of them) are able to carry several passengers at the same time, each making different journeys. As noted earlier, taxi rank data is very limited - and there are very few shared taxi ranks (if any) in NaPTAN data nationally. Personally I would ignore both taxi rank and shared taxi rank at present. 2. Fields which are described as location 3+ - what are these? [rs] NaPTAN generally describes points . but for Hail-and-Ride stops, two additional locations are specified for each stop. The NaPTAN record is the "anchor" location, but the Hail-and-Ride section also has an entry point and an exit point (should be on the same named road etc - see NaPTAN guideance - but this is not always adhered to). More recently it has become possible to operate services in "demand responsive" mode - where the service can stop anywhere in a zone . and this requires a polygon to be defined within which the bus can stop for each area served. . the 3+ refers to the need to define at least three points in order to define a polygon. The same applies to PlusBus zones - these are zones within which you can travel on most buses using a PlusBus rail ticket. 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. [rs] As noted above, the AtcoCode is the key to NaPTAN data and I think it is essential that this is used. NaptanCode is the name given for structured codes used for SMS service (the rules for which are likely to be relaxed in Yorkshire and London for local reasons - but the codes will remain unique nationwide). PlateCode is optional and is not widely populated - its use is almost exclusively related to particular types of real-time information systems 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/ Regards Brian
_______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
