[Talk-gb-westmidlands] [Talk-transit] NaPTAN data import

[Andy Robinson (blackadder-lists)]

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.
>Here
>> 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
>important
>> to identify the source of the data and differentiate it from OSMer-
>generated
>> data
>> 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
>nodes
>> 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
>bus
>> 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
area.

>
>> 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
>merge
>> with existing data  or "switch on" by tagging where we haven't yet
>surveyed.
>> 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
>future
>> other OSMers will have the benefit of Christophe's visual tool to do
>this.
>> 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
>data?
>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
>entered
>> most of this data and he'll have to do most of the work - we all agreed
>> readily!
>
>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
>>
>> Regards
>>
>> Brian
>
>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)
>
>--
>Regards,
>Thomas Wood
>(Edgemaster)

Cheers

Andy