[Talk-GB] 10 fascinating facts about OSM & OSGB
oliver.jowett at gmail.com
Thu Apr 18 18:48:40 UTC 2013
On Thu, Apr 18, 2013 at 7:15 PM, Chris Hill <osm at raggedred.net> wrote:
> On 18/04/13 18:12, Oliver Jowett wrote:
> On Thu, Apr 18, 2013 at 4:57 PM, Chris Hill <osm at raggedred.net <mailto:
>> osm at raggedred.net>> wrote:
>> I followed the guidelines in the wiki 
>> That seems to boil down to "don't modify naptan: tags except
>> naptan:verified", so hopefully we won't have to worry about conflicts
>> between import updates and manual changes there.
> There are many naptan:* tags that are not mentioned on the page. If you
> find any that are not consistent with what you find on the ground, change
> them. Examples are bearing, street, Atcocode, landmark, all of which I
> found often to be wrong. Various authorities include different levels of
> detail, so there may be more tags than this. All are open to change if you
> find an error.
I'm a bit confused now. The wiki page says "Tags that start with Naptan
should not be edited until a system had been agreed on (except
naptan:verified=*, see below)". Have you been updating the naptan tags
in-place as you find errors, or correcting the data elsewhere (e.g. by
modifying name= as the wiki page suggests)? On the NOVAM example you
linked, I see stops where there is a note saying that the NaPTAN Bearing is
wrong and should be some other value, but the original value is still there
(On another note, shouldn't "source=naptan + survey" be
> Not sure what to with naptan:verified=yes when updating a stop, setting
>> it to "no" and leaving it unchanged both seem unsatisfactory.
> If a stop has been verified, delete the naptan:verified=*.
Oh, right, I misread how that was used. However my point is that when
merging updated data from NaPTAN to a stop that has been verified on the
ground, we want some way to say "this has been verified manually at some
point in the past, but there have been subsequent imported changes that may
need re-verification" - how should we represent that?
> I should add that I sent all of the anomalies I found to my local
> councils. having said they were interested, both ignored my data, so OSM in
> my area is still more accurate that the NaPTAN data. Local authorities
> provide the data that ends up in NaPTAN. I would not, therefore, support
> updating OSM with another NaPTAN import in my local area.
I'm working around Cambridge where there's been essentially no verification
done, and there have been various route and stop changes since the import
so the current TNDS data now references many stops that do not exist in
OSM, and there are lots of dead stops. An update is definitely needed here!
Since the original imports were done piecemeal I expect the same would
happen with any updates, so at worst we can just not update areas with good
coverage that we don't want to touch. Ideally, though, we'd take the best
of both datasets. Certainly we would not want to clobber manual corrections
with the old, wrong, import data, but if we get new NaPTAN data then it's
probably worth at least flagging the changes for further inspection?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-GB