[Imports] Importing fuel stations in UK and future similar imports

Colin Smale colin.smale at xs4all.nl
Sun May 14 12:51:43 UTC 2017


On 2017-05-14 13:08, Mike N wrote:

> On 5/13/2017 6:27 AM, Andy Mabbett wrote: On 13 May 2017 at 10:06, michael spreng <talk at osm.datendelphin.net> wrote:
> 
> private ones are a clear no like this navads_shell A "clear no" in the sense that some of us think they're perfectly acceptable

 Acceptable, yes.   But having any value to OSM - no.  Consider the real
life cases.

  1.  After the import, a mapper sees a new station just opened, so they
add it to the map.   Without an id.
  2.   After the import, a mapper spots a closed station, so they delete
the node or delete the information and mark it as disused.

  Database ids don't help resolving those common cases.

  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.

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.


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. 

--colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20170514/d03608f2/attachment.html>


More information about the Imports mailing list