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

My only technical comment regarding your script is that we usually put 
the source tag(s) on the changeset, not the individual node, nowadays.


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

More information about the Imports mailing list