[Talk-transit] NaPTAN bus stop database import
grand.edgemaster at gmail.com
Sun Mar 1 00:26:40 GMT 2009
2009/2/28 Brian Prangle <bprangle at googlemail.com>:
> Hi All
> I've added to Thomas's initial work and completed what I think we should
> import and what the tagging scheme should look like in
> http://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings. Please take a look
> and shoot down in flames/agree/amend: particularly inclusion/exclusion
> Generally if the text of the proposed tag following the naptan: preamble is
> in the format "word1_word2" it is our substitute for an ambiguous or verbose
> NaPTAN field name, otherwise it's a copy (complete with CapitiLisation) of
> the NaPTAN field name
Currently implemented is a 'tag copy' from naptan to osm tags for
'interesting' naptan fields. Of course, this is provided the field has
not been caught by some other processing, such as the Indicator stuff.
For example AtcoCode is mapped to naptan:AtcoCode.
Current config for this is here:
> Three questions:
> Hail and ride section of route, with a linear footprint.
> Flexible zone, with an area footprint.
> 1.Presumably these are represented for HAR with 2 nodes (start and end) and
> for FLX with multiple nodes (min 3) for which we would have to draw a way
> between them and add a tag to the way. (naptan:HAR=yes and naptan:FLX=yes)
Currently decided not to import these, for simplicity's sake.
Eventually, we'll probably want to represent HAR as highway ways as
part of the route relation? Possibly with a visible point in the
centre for ease of rendering? Whatever we decide, we'd have to match
it to the existing OSM data, my skills dont currently extend to this,
but is on the long-run todo list.
No idea about FLX yet.
> 2.Thomas- how easy is this to add the way and tag it within the import
> process or should drawing the way and tagging it be left to manual
> intervention? Roger – how many of these are there?
Drawing FLX zones should be fairly easy, if we decide to import them.
> 3. If we can agree the entire tagging and import scheme would we get any
> extra benefit from offering it for discussion on talkgb or should we just
> get on with it?
I've been taking the just get on with it route, filling in Tag mappings as I go.
(Our edit conflicts this morning kinda proved this, more on this in a bit..)
> An observation:
> With about 30 fields to be imported are editor screens going to look too
> cluttered for the average OSMer? TIGER data takes up a lot of screen real
> estate and there's a lot less fields. Should we (can we) cull the fields to
> be imported?
We can easily not import data, the converter is currently standing at
using 8 tags for a standard london bus stop. (3 of which are the
standard source=naptan created_by=naptan2osm and
I believe that some of your suggestions for tags seem to be
superfluous to the way that some of the data will be structured.
I'm also all for keeping the tags as close to the standard OSM tagging
scheme as possible, for example, using alt_name rather than
naptan:alt_name. Do we really need "consistency on data origin"?
In other news, whilst on the train to (and from) York today, I wrote a
sizable chunk of the StopArea code for the converter. It's in a mostly
working state, the only issues I have to work out are StopArea
hierarchies, particularly when a StopArea is defined in another
region's dataset, the national rail one, for example.
I'm either going to have to do a mass convert of the whole dataset at
once (which I'm not looking forward to, since I suspect the memory use
will skyrocket), or try and resolve the dependencies by parsing the
national datasets to get a hash of all the StopAreas, and then append
on the county level StopAreas as and when they're created, finally we
can then upload the national StopArea points, as and when we get
around to those types of data. (AIrports, NatRail, to name a few)
More information about the Talk-transit