Can I propose that we carry on, on the basis of:<br><br>1.we include onstreet and offstreet bus stops<br>1a. understand Peter's point about node imports (taxi ranks, station entrances etc but I'd still like to leave that until later)<br>

2.create a user NAPTAN as suggested by Peter ( how do we do this and who does it?)<br>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?). <br>

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?<br>
 (Peter what is the precise agreement with Traveline as to the extent of what we can import?)<br>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.<br>

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?<br>
6. Whilst that's going on we can decide on tagging structure ( might want to look at how TIGER data is tagged?)<br>
7. Then we have the thorny question about how the import gets compared with existing data:<br><br>Intial thoughts:<br>a. Do we need to worry about misalignment with existing ways? Probably not, but would like confirmation<br>
b. Do we need to worry about stops where there are as yet no ways? Probably not, but would like confirmation<br>
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?<br>

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<br>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?<br>

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?<br>g we need a process for updates- haven't got any clear ideas around this currently<br>
<br>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.<br>
<br><br>Clarification from those who know the NAPTAN schema better than me please:<br><br>Currently the typical tagging of bus stops (from those who really care ;-) ) in Birmingham follows the pattern here:<br><br><table class="browse_heading" width="100%">
<tbody><tr><td>Node 410393</td><td align="right"><a href="http://www.openstreetmap.org/browse/node/410393">Details</a></td></tr></tbody></table><ul><li><b>ref</b>: 504974</li><li><b>route_ref</b>: 104;104A;105;110;112;115;902;904;905;915</li>
<li><b>shelter</b>: yes</li><li><b>highway</b>: bus_stop</li><li><b>location</b>: Birmingham Road;The Yenton</li><li><b>towards</b>: Sutton Coldfield</li></ul>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<br>
<br>Sorry for such a long post - hope it makes sense<br><br>Brian<br><br><br><br><br><br><br>