<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>On 26.08.2011, at 8:34, Bryce Nesbitt wrote:</div><div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div 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></div></blockquote></div><br><div>What is this "care share location" really? Some special spot, or co-located with other amenities (gas stations, bus stations, buildings etc)? If the objects are really autonomous nodes, connected to nothing, then your solution could work well. I can imagine similar situation with other very specific datasets: say elevation info (DEM), half-virtual objects like geocaches. </div><div><br></div><div>If the spots are shared, then you have to merge it with existing (possibly conflicting) tags, locations, you link points with ways etc, how exactly it would work with your script. </div><div><br></div><div> I cannot resist to propose also OpenMetaMap solution for your case:</div><div><br></div><div>a) if spots are autonomous:</div><div>1. Car share operator publishes their data as OSM file. They need to do it for import anyways.</div><div>2. They put their URL to OMM data directory</div><div>3. Users (like OSM main Mapnik renderer) will find the latest situation it from there, and will add it as a data layer. I guess is this is your main reason to import it.</div><div><br></div><div>No data duplication, sync etc needed. </div><div><br></div><div>If the dataset is linked to existing OSM objects then it would be more complicated:</div><div>1. and 2. steps - same as above</div><div>3. you open JOSM and download both datasets (OSM and yours)</div><div>4. you merge data: select 2 points, click "Edit > Merge points". Resolve tag conflicts if found, check location. This will create OMM Links for you. You do exactly same amount of actions as you need to do with manual merging anyways.</div><div>5. Save data: OSM object will be updated if you moved point or changed tags, otherwise not. Mostly you save links to OMM.</div><div>6. Users will take data from OSM, your database and OMM Links, and merge them on the fly. Broken links are not rendered, just like with your import/sync script</div><div><br></div><div><br></div><div>Advantages:</div><div> - maintenance-free, no need to re-run sync scripts by data provider. Data gets rotten not only because there care no manual edits, but also because sooner or later you do not run the script anymore, so the foreign key tags in OSM will be outdated. </div><div> - Principal difference is that you will give full control over data links to the OSM community. If you are not there to update it, they will; at least if the data is really relevant for the community.</div><div><br></div><div>Disadvantages / limitations:</div><div>- much more tools/code needed than one Python script. Cannot be done today.</div><div>- one more trouble, decision to make, for OSMer: should my contribution added also to OSM, or kept in external dataset. There should be best practice guidelines for it, or maybe could make the decision before user. For the car sharing operator it does not really matter: they would get the contribution either way: from OMM or from OSM (with help of OMM) database.</div><div>- external API will be unavailable after some time. Maybe it takes years, but it will happen. For this OMM shall have "persistent cache" (archive) option, if data source allows it.</div><div><br></div><div>Jaak</div><div><br></div></body></html>