Sam Vekemans writes: > What this did was sparked some major issues that need to be addressed. > I think this is more important, than going deeper on that rant.
I'm new to the innards of OSM, so I may be saying something stupid or obvious. Just step on me if I am. OSM already contains two kinds of data: data entered into OSM, and data imported into OSM from elsewhere. Of the data imported into OSM, there are two kinds: data "thrown over the wall" to OSM, and data from an entity which wishes to cooperate with OSM. When the entity wishes to cooperate with OSM, the course is clear: when someone edits a node which originated with the entity, make a note, and pass it back to them. When next they hand over data, replace all data which originated with the entity -- even if edited by an OSM editor -- with the update from the entity. If the cooperative entity uses the OSM edit, it's because they felt it was right. If they don't use the edit, then they think it was a mis-edit. If they keep getting the same ignored edit back, then maybe there's something wrong with their data verification procedures? Of the data "thrown over the wall", again, we can make two distinctions: one-time data imports, and data of which we expect updates. The one-time data import we can treat as a gift to OSM just as we do all the other volunteer improvements. Import it (dealing with existing data -- a different problem), edit it, and life goes on. The really big problem is data that gets imported, where the source of the data doesn't want our edits back, and where they continue to make changes and make new data available to OSM (this approximates the situation with TIGER, which is of interest to me.) One possiblity is to write-protect that data. That seems like anathema to me. What's the point in having read-only data in a publicly-maintained editable database? All we would be doing is making it easy for OSM-using software to access that data. We're telling our users "screw you, we don't want your edits", because that's what the source entity is telling us. But in a sense write-protecting the data is merely reflecting the reality that user edits aren't a part of that data. On the other hand, perhaps the solution is to treat OSM edits as a patch to the data that comes from the source. When an update comes along, only delete the previous data that haven't been edited. Whatever's left will need hand fixing; either to delete the (wrong) new data or to delete the current edit. (But that would also mean undeleting deleted nodes from the older data, and marking them as having been deleted -- this to allow deletion of similar nodes in the matching updated data). Am I on the right track, or am I off in the weeds? -- --my blog is at http://blog.russnelson.com | Delegislation is a slippery Crynwr sells support for free software | PGPok | slope to prosperity. 521 Pleasant Valley Rd. | +1 315-323-1241 | Fewer laws, more freedom. Potsdam, NY 13676-3213 | Sheepdog | (Not a GOP supporter). _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
