On Fri, May 12, 2017 at 12:08 PM, Ilya Zverev <i...@zverev.info> wrote:
> * "The general view seems to be against IDs like this": what has happened > with the principle "any tags you like"? Did we saturate the key space and > not accepting new keys anymore? Can I read that "general view" documented > anywhere? The "ref:navads_shell" key is the only one that is not verifiable > on the ground, and is clearly added so the further updates do not have to > rely on matching. > That's a point on which many importers go badly astray. The problem is that no foreign key in OSM, without matching and conflation, can be used for a further import. A local mapper may modify the object in arbitrary ways while leaving the foreign key in place, so you can't be sure when re-importing that you're still dealing with the same object. Matching and conflation are really the only safe way to keep reimports from stepping on the hard work of local mappers. Where such foreign keys are useful is in the case where they tie into external databases that have information that is not mirrored in OSM. The most obvious examples of this sort of thing are external website links, Wikidata links, and Wikipedia article titles. In imports that I've run, I've also retained other foreign-key information that identifies items in databases that I import from. But I never, ever depend on that information to give me a reliable match between OSM and the external database. Importing data that will grow stale, languish and die for lack of maintenance is not much of a benefit in the long run. Maintaining an import is considerably more work than most first-time importers imagine. This does not in itself say that imports are bad - I maintain a couple myself - but to me, the assertion that maintaining a foreign key will aid in future importing is a distinct "red flag" that will make me look at the maintenance plan a lot more closely. For what it's worth: there were mechanical edit scripts that helped substantially with the workflow, but every change in the last round of updates from http://www.openstreetmap.org/user/ke9tv-nysdec-lands/history#map=8/43.446/-74.192 was matched by geometry and examined by eyeball for changes to both geometry and tagging. In some cases I bypassed edits because local mappers had already made the relevant changes or had introduced substantitve changes to the geometry that I could not verify from database comparisons. This is a situation where Frederik and I have an uneasy truce. He's pretty much against all imports, feeling that they damage the local community of mappers. But he does recognize that at least I do imports of live data that I use and intend to maintain, and that I respect local mappers and go to fairly intensive lengths not to overwrite their work. There is no local mapping community to speak of, nor is there the infrastructure to support one. People expect the administrative boundaries of their public forests and parks to be mapped - and for the moment, I don't see any other way of mapping them. Frederik and I both agree that it's awkward at best to maintain these data as an import - where we part company is that I see it as infelicitous but necessary, and he sees it as entirely unacceptable. He draws the line short of reverting the import, which is all that I ask of him.
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
