Serge Wroclawski writes: > This (and other experiences) lead me to the belief that unique object > identifiers or other tags can't be relied upon post import, and any > conflation steps need to be done using the same technique that one > might do if starting a conflation step from scratch.
Depends on how you look at it. Initially, an import will be effectively an overlay, with no shared data. If somebody never joins or merges the imported data into the existing data (perhaps it's just a big pile of bicycle racks in New York City), then the problem becomes this: Case 0: Nobody changed anything in the import. Delete and reimport. How do we merge the user's changes into the updates from the data source? In essence, this is the diff merge problem. Let's call this case 1. It's by far easier. Case 1A, then, says that we create a geodiff and delete all of the imported data. We import the current data, try to apply the geodiff (as best we can) (the problem being that whatever we edited may have already been noticed at the source and fixed)., then send a geodiff for what results back to the source of the data, saying "Hey, we got these changes made -- you might want to incorporate them." That is the same as sending patches upstream, and NOT doing this is considered a bad thing. Case 1B, we throw away the user's edits and just delete and reimport. Not advocating this. Case 1C, we don't send changes back. Not advocating that either. Case 2, the import has been integrated into OSM. http://www.youtube.com/watch?v=8WZr6fvtEgk -- --my blog is at http://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog _______________________________________________ Imports-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports-us
