[Imports] New module to merge-sort imports over time (osmfetch python)
frederik at remote.org
Fri Aug 26 14:59:59 UTC 2011
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.)
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the Imports