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
_______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
