<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:BLU0-SMTP4DD56913B2753176161C4AC130@phx.gbl"
type="cite">On Thu, 25 Aug 2011, Bryce Nesbitt wrote:
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br>
That's the cool thing about the proposed approach. Who is the
authority for each tag is scriptable. <u>wheelchair=yes</u> can
(and would) be mastered in osm. Exact <u>lat/lon</u> would <i>always</i>
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.<br>
<br>
But if the fast-food chain claims a store is closed, well... I'd go
with that as first cut.<br>
Similarly if fast-food chain says a store is now open.<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
-Bryce Nesbitt<br>
<br>
<br>
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.<br>
I do have a similar project that checks up on the local shops,
verifying that the<br>
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....<br>
</body>
</html>