[Imports] New module to merge-sort imports over time (osmfetch python)
Frederik Ramm
frederik at remote.org
Thu Aug 25 22:27:48 UTC 2011
Bryce,
Bryce Nesbitt wrote:
> The goal of this module is to help make imports more robust and correct
> over the long haul. As a side effect the module makes imports dead
> easy to code.
One of the problems of imports is that they, more often than not, have
technical flaws. If you manage to reduce that by having a good framework
then that is certainly an advantage (even though many imports might be
more complex, involving line and area geometries).
Another problem which you don't seem to solve is the relationship of
imported and already existing data; it seems that in your particular
case you evaluated the situation by hand before importing. This is often
one of the more complicated things to do with imports, and it is
important to stress that even if you have your code right you still have
to do this analysis. We must not give people the impression that
importing was easy if only you have the right tool.
As you know, I am of the opinion that there should be no data in OSM of
which our mappers are not masters. If, in your specific case, a mapper
were to change the list of vehicles at a car sharing location, I would
consider it inacceptable to override this change from the external
source. If you want the external source to be the master then mix it in
at production stage, don't dump it on OSM.
And finally, we have a policy that says every import should be discussed
*before* it happens on a suitable mailing list or forum; even if your
180-node car sharing station import may fly under the radar, please do
your bit to ensure that everyone who uses your software follows the
guidelines.
My only technical comment regarding your script is that we usually put
the source tag(s) on the changeset, not the individual node, nowadays.
Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the Imports
mailing list