[Talk-transit] NaPTAN bus stop database

[Roger Slevin]

Brian

 

My comments are shown below - I hope they are helpful

 

Roger 

  _____  

From: talk-transit-bounces at openstreetmap.org
[mailto:talk-transit-bounces at openstreetmap.org] On Behalf Of Brian Prangle
Sent: 22 February 2009 22:01
To: talk-transit at openstreetmap.org
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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20090222/4b93887a/attachment.html>