(Reposting without quoted message to avoid message length limitation) Those of us who do imports have been improving our tools continually, in order to be able to import responsibly according to current import guidelines and current mapping practice.
Pieter Vander Vennet describes virtually the identical process to the one I use in updating the boundaries of New York State public lands. In my case as well as that of the Belgian mappers, the update is continuous, at least in concept. (I tend to run updates only about annually, but work on them sporadically over a period of weeks or months.) The Belgians are dealing with a much larger number of objects than I address, although mine are much larger and have much more complex topology (which makes the idea of 'just' matching the geometry even harder!) In both use cases, the major purpose of the foreign key is to avoid manual review in the case where OSM will not be updated. If an object (retrieved by key) is unchanged since the last import, in both OSM and the external database, then there is no work to be done. (This is the case for the overwheming majority of managed objects.) Otherwise, whatever is done gets manual review. This process is impossible without some tag that follows the imported object, because without one there's no handle by which it can be grasped. The only effect that having a mapper modify the tag or modify the tagged object will be that it will trigger manual review. Since the manual review is work, removing the tag for no reason is impolite, but it won't trigger any cascade of bad data, cause changes made by human mappers to be overwritten, or any of the disasters that some posters appear to envision. Because in my pipeline every imported object is reviewed manually, there's no issue with a deleted object reappearing. I've already observed this case in practice in my workflow with the New York State public lands. I have repeatedlyu done manual review of the Lake George Islands State Campground https://www.openstreetmap.org/relation/6385471 (*), because it includes several islets that were washed away in a hurricane in 2011. The fact that I do *not* find an individual item is itself cause for performing a manual review, not cause for automatically reinserting it. (I also, for this case, insert ways like https://www.openstreetmap.org/way/542355389 to warn mappers away from tracing the destroyed islet from orthoimages.) I agree with the Belgian mappers in every particular. (*) Side note: I do not agree with all the tagging on that particular relation, but local mappers have requested that a. I refrain from putting 'name=*' on it, since that causes at least one renderer that they care about to render that name in preference to the names of individual islets. b. I refrain from marking the whole area 'amenity=camping_site' even though it is designated as a campground, and refrain from using 'leisure=nature_reserve' tagging for legacy renderers, because the locals wish to map individual tent sites and picnic areas within it.
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
