[Talk-transit] [Talk-gb-westmidlands] NaPTAN data import
Andy Robinson (blackadder-lists)
ajrlists at googlemail.com
Fri Mar 6 18:28:04 GMT 2009
Thomas Wood wrote:
>Sent: 06 March 2009 5:38 PM
>To: Brian Prangle
>Cc: talk-transit at openstreetmap.org; Talk-gb-westmidlands at openstreetmap.org
>Subject: Re: [Talk-gb-westmidlands] [Talk-transit] NaPTAN data import
>2009/3/6 Brian Prangle <bprangle at googlemail.com>:
>> Hi everyone
>> We discussed at our West Mids meeting last night the best way forward.
>> is what we would like to see happen:
>> 1. Proceeed with the import on the basis of the proposed naptan taggings.
>> All imported data should have the naptan: prefix as we feel it is
>> to identify the source of the data and differentiate it from OSMer-
>> 2. If it's easy to code, generate ways between related nodes for things
>> like plusbus zones, stopareas etc. We didn't discuss however how to tag
>> these, so I guess just leave them untagged. If it's going to be difficult
>> and slow down the implementation, then ignore it and just import the
>> and we'll have to generate ways manually.
>StopAreas are very common in the London data that I've been testing
>against, as noted in previous emails to the list, the converter does
>convert the majority into relations. The only issues I'm having with
>it is trying to keep list of the national StopAreas. I should tackle
>this problem sometime this coming week.
>I guess a relation for a plusbus zone will also probably be good, a
>polygon can be derived from it automatically, I think we'd have to
>invent a new, creative relation scheme, since a stop area relation
>doesn't suit it well.
>> 3. Rather than import for the whole West Midlands, just import for
>> Birmingham as a test area - it's easier for us to cover as there fewer
>> stops in a smaller area, and it also won't piss off our neighbours in
>> Coventry - most of us are based in Birmingham.
>That's fine, I think I'll add a bbox filtering option.
I spotted that the NAPTAN data included a "Town" flag. If you filter that
field for "Birmingham" that should more than suffice for our initial test
>> 4. The import should not tag the data with highway=bus_stop. We'd rather
>> have un-rendered nodes that we can see in the editors and then either
>> with existing data or "switch on" by tagging where we haven't yet
>> It is OK however to tag taxiranks with amenity=taxi (very few people have
>> been surveying and tagging these)
>I can just flip these tags fairly easily, so isn't much of a problem.
>> 5. Can we have a csv file of the data so we can keep track of our
>> verification and record variations, problems on the ground etc. and
>> co-ordinate activities so we don't go off duplicating effort? In the
>> other OSMers will have the benefit of Christophe's visual tool to do
>> We'll give regular updates here on how we're faring and produce a short
>> report summarising our experience for future imports.
>A csv file of the data, can you be more specific on _what_ you mean by
>The wiki is an excellent place for coordinating tidy-up projects.
>Notes on changes can be stored on the nodes themselves, if suitable,
>otherwise we'd need an annotation tool with Christophe's visual tool.
Something we can sort easily and print off a sheet for the area being
verified. Easy then to check stuff off when out mapping.
>> 6. As a local initiative we are proposing to cease using (and convert
>> existing data) the ref=xx tag for identification plates we find on the
>> ground as it doesn't currently match any naptan data (and so can't be
>> regarded as a global standard reference) and we will use instead
>> asset_ref=xxx. This is Andy's suggestion and as he's the one who's
>> most of this data and he'll have to do most of the work - we all agreed
>Do we now want to import any suitable asset_refs (from whatever the
>equivalent field is called) from naptan, where they exist (most suited
>for other regions)?
For the Birmingham data definitely import the asset data, just put it under
a naptan namespace though rather than asset_ref because we will use
asset_ref for what's on the ground, which for Brum is shorter than what's in
the naptan data.
>> Let us know if there are any problems with this
>Regarding Peter's comments about obtaining the data, I'm already
>getting it from the official site for testing the converter, since the
>license they give there allows it explicitly.
>Regarding the data import more generally, do we have a rough timeline
>of when we want this done by?
>We should probably avoid the 0.6 and licensing changes, so we don't
>create more work for ourselves than is absolutely required.
>Gerrit - NaPTAN references nodes as being part of a StopArea, somewhat
>like our relation structure. The converter is already pulling them in
>according to the unified stop area spec. (Except for not having the
>stop-points on the road way, just beside, but thats just a moot point)
More information about the Talk-transit