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 [email protected] ## N49°00'09" E008°23'33" _______________________________________________ Imports mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports
