[Imports] New module to merge-sort imports over time (osmfetch python)

Bryce Nesbitt bryce2 at obviously.com
Fri Aug 26 05:34:29 UTC 2011

> On Thu, 25 Aug 2011, Bryce Nesbitt wrote:
>> I disagree here.  If the external source is "ground truth", then 
>> that's the data that should take precedence.  A car share operator 
>> for example won't want a disused location shown, and may well make 
>> that a requirement of permitting the merge-sort.  An import from a 
>> car share reservation system is definitive ground truth.
> A car share operator, or anyone else can go in and mark a location as 
> closed or delete it but the operator isn't automatically considered 
> more authoratative than any other mapper.  For example let us say a 
> fast-food chain imports a database of their restaraunt locations and 
> marks some of them as wheelchair=yes but I go visit the location and 
> feel it doesn't qualify for that tag. The operators database can't 
> complain ground truth or authority over someone who has actually 
> visited that location and an automated script shouldn't 'undo' my 
> change every month.

That's the cool thing about the proposed approach.  Who is the authority 
for each tag is scriptable. _wheelchair=yes_ can (and would) be mastered 
in osm. Exact _lat/lon_ would /always/ be mastered in osm.  Heck the 
script could even set an OpenStreetBug if it cared to resolve a 
minor-tag discrepancy ("Chain-store says toilets=permissive, local 
mapper says toilets=no, who is right?").  But in general I'd leave all 
those tags to humans.

But if the fast-food chain claims a store is closed, well... I'd go with 
that as first cut.
Similarly if fast-food chain says a store is now open.
If the car-share reservation system says there is now a "Prius" and a 
"Batmobile" for hire, I'd go with that over older community data that is 
likely stale.

The car share data produced by the community process was highly spotty. 
  The reservation system data is complete.  But you can have it both 
ways: osm contributors can add all sorts of tags (description, photos, 
etc.) and the merge process will keep the best of both on the same node, 
with full history.

The automated tool in question already shows the human operator the 
diff: so a human is still in control.  Perhaps it could be extended to 
detect and flag any potential edit wars (e.g. same tag 'corrected' 
twice)?  Would that satisfy the objection?

                             -Bryce Nesbitt

PS: I loathe the thought my script might be used for chain store 
imports.  I map all the unique and local shops in my area, having no 
interest in the chains.
I do have a similar project that checks up on the local shops, verifying 
that the
website= tag still matches the actual shop.  Unfortunately it mostly 
helps mark the demise of local shops as they go out of business and the 
domains expire....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20110825/e764816f/attachment.html>

More information about the Imports mailing list