[Talk-gb-westmidlands] NAPTAN database

[Brian Prangle]

Can I propose that we carry on, on the basis of:

1.we include onstreet and offstreet bus stops
1a. understand Peter's point about node imports (taxi ranks, station
entrances etc but I'd still like to leave that until later)
2.create a user NAPTAN as suggested by Peter ( how do we do this and who
does it?)
3.use the wiki page NAPTAN/import to indicate whether to include/exclude a
field - we can worry about tagging later - at this stage we just need to
decide do we need the field or not - needs an extra column in the wiki
table/ re-label the OSMtag column (Thomas?).
We can discuss/justify disagreements here in talk transit. Are there any
dire consequences of just importing everything except the obvious fields(
already indicated in the wiki page NAPTAN/import)- database performance/
disk capacity?
 (Peter what is the precise agreement with Traveline as to the extent of
what we can import?)
4. Thomas - it seems you already have a dataset to work from and a pretty
good importer prototype from the example you sent me of Birmingham
International.
5. Once we've decided what to import, I think it would be a good idea to
offer that to talk-gb to see if anyone wants to challenge/change it. Can you
estimate how much more needs to be done - is Christophe up to speed with any
of this?
6. Whilst that's going on we can decide on tagging structure ( might want to
look at how TIGER data is tagged?)
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.


Clarification from those who know the NAPTAN schema better than me please:

Currently the typical tagging of bus stops (from those who really care ;-) )
in Birmingham follows the pattern here:

Node 410393Details <http://www.openstreetmap.org/browse/node/410393>

   - *ref*: 504974
   - *route_ref*: 104;104A;105;110;112;115;902;904;905;915
   - *shelter*: yes
   - *highway*: bus_stop
   - *location*: Birmingham Road;The Yenton
   - *towards*: Sutton Coldfield

All of which is visible from a survey. Additionally, some bus stops have
names such as Acocks Green Village AB. I take it that all this information
is available in the NAPTAN data

Sorry for such a long post - hope it makes sense

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb-westmidlands/attachments/20090219/61f13229/attachment.html>