On Thu, Apr 18, 2013 at 7:15 PM, Chris Hill <[email protected]> wrote:
> On 18/04/13 18:12, Oliver Jowett wrote: > > On Thu, Apr 18, 2013 at 4:57 PM, Chris Hill <[email protected] <mailto: >> [email protected]>> wrote: >> >> I followed the guidelines in the wiki [1] >> >> 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 in naptan:Bearing. (On another note, shouldn't "source=naptan + survey" be "source=naptan_import; survey"?) > 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? ("naptan:verified=previous_import"? "naptan:unverified=CommonName;Bearing"?) > 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? Oliver
_______________________________________________ Talk-GB mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-gb
