[Imports] New module to merge-sort imports over time (osmfetch python)

[Frederik Ramm]

Hi,

Bryce Nesbitt wrote:
> But if the fast-food chain claims a store is closed, well... I'd go with 
> that as first cut.

Ok for the first import, but if subsequently a mapper tags it as closed, 
then for OSM it is closed.

> 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.

Maybe. But if on day A you import that there's a "Prius" and a 
"Batmobile", then later a mapper changes this to something different, 
and then even later you re-run your script and override the mapper's 
information with yours (which by all means might be even more stale) 
then that's not right.

> The car share data produced by the community process was highly spotty. 
> The reservation system data is complete.

The records of a company can always be erroneous, or old, or tainted by 
wishful thinking or some crazy idea of the PR department. Yours is an 
extreme example because even *if* there was a Ford Mustang at that 
location and the mapper correctly added that to the list, it would not 
be bookable through the booking system because of the data error, and 
therefore the data recorded by the mapper would be useless for someone 
who wants to book a car (OTOH maybe useful for someone who wants to take 
a photo of a Ford Mustang). But there are many many other examples where 
a company would like to be the authoritative source of something but our 
mappers might think different.

And our mappers should always have precedence; OSM is not a cheap 
publishing system for corporate data. If someone wants to be the master 
of their own data, then don't upload to OSM - set up your own rendering 
chain and mix in your information into your very own maps. Under no 
circumstances automatically override changes made by OSM mappers.

(At one point you mention "what if being the master for the X, Y, and Z 
tags is a condition of the car sharing company for the release of their 
data - to why my reply is, either you release data under our license or 
you don't but there's no conditions you could apply.)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"