> In any case all of the above potentially lead to your private fork of the > planet getting out of sync real fast with the original, implying that > applying diffs will become > more problematic over time. So you wouldn't be able to take you fixed and > known good planet fork, apply only good diffs, and expect to be able to > continue to do that > for a year or so. No, that's not the idea at all. It's to download planet files regular, identify problematic recent changes, revert only those. You still need a history to revert. Contribute back to the OSM community what the problematic attributes/object are, and a human can revert them. > IMHO the only thing that could really work in the OSM model is reverting real > fast in the -original- dataset. Fixing the original dataset *is* paramount. However, it's important to understand that there's this transitional problem; that, any given version of the dataset will have defects, and to catch the most egregious of these - particularly from vandalism is really the only goal here. Not every use of OSM data will be pulled with high frequency from the database; there are offline applications where it's "pull once, use for a few years". You may be able to rely on the community to repair persistent high-profile issues, but these transitory issues are another matter. > Naturally there is the other aspect that we want our contributors to gain > experience and become better mappers over time. You are only going to get > that if leave the > opportunity to make mistakes open and don't robo-fix > everything that goes wrong
It's not robo-fixing, it's "robo-flagging for moderation". Fundamentally different thing. Something that has be vetted could certainly violate any rules this flagging uses. -Alan
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
