[Imports] New module to merge-sort imports over time (osmfetch python)
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
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?
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Imports