<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>On 2017-05-14 13:08, Mike N wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><span style="white-space: nowrap;">On 5/13/2017 6:27 AM, Andy Mabbett wrote:</span>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><span style="white-space: nowrap;">On 13 May 2017 at 10:06, michael spreng <<a href="mailto:talk@osm.datendelphin.net">talk@osm.datendelphin.net</a>> wrote:</span><br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><span style="white-space: nowrap;">private ones are a clear no like this navads_shell</span></blockquote>
<span style="white-space: nowrap;">A "clear no" in the sense that some of us think they're perfectly acceptable</span></blockquote>
<br /> Acceptable, yes. But having any value to OSM - no. Consider the real life cases.<br /><br /> 1. After the import, a mapper sees a new station just opened, so they add it to the map. Without an id.<br /> 2. After the import, a mapper spots a closed station, so they delete the node or delete the information and mark it as disused.<br /><br /><span style="white-space: nowrap;"> Database ids don't help resolving those common cases.</span><br /><br /> So even with the best case of trying to apply a future import update by running a diff against the original import data, it is still necessary to run a conflation against OSM's data.<br /><br /></div>
</blockquote>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">It would however make it a whole lot easier. Assuming the majority will be unchanged (depends on the update frequency, but petrol stations don't tend to be very volatile, if you will excuse the pun) doing this conflation will highlight cases where a change has apparently taken place which can then be checked manually if required. An ID in the updated source file that can't be found in OSM might indicate a new station, or one that has changed branding. An ID in OSM that can not be found in the updated source file, indicates a station which has closed or changed branding. Flag these cases up with notes and (with a bit of luck +/- a bit of poking) the community can soon remove the uncertainty.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Instead of pointing out that an approach is not 100% perfect and casting it aside for that reason, I would prefer to find a way to make use of the 90% goodness. It is a fact of life that OSM (or any other database for that matter) is of limited use if it is a "data island". What makes or breaks it, is how it can be integrated with other data. That is where the "foreign keys" come in.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">--colin</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
</body></html>