[OSM-dev] Reverts from the woodpeck_repair account
roland.olbricht at gmx.de
Wed Jan 2 20:07:26 GMT 2013
> The second problem is the automated editing. Perhaps now as OSM becomes
> more and more popular it is time to start looking at some more general
> solutions to these kind of problems with data and bots.
The solution is simple and straightforward: A database design must be able to
cope with the the edits that are uploaded. If you don't consider all edits
valuable, you are free to drop data in the target database.
By contrast, any additional decision logic in the main API does really clutter
OSM because the main database as sigle point of failure gets more prone to
errors. More important, it may shy away mappers if they found that their
particular situation on the ground cannot be mapped properly.
SomeoneElse got his work damaged by other mappers, for no important reason. A
less self-confident mapper may have been lost at that point.
That's the reason why we have freedom of expression in tagging and mostly in
producing changesets. Data consumers still have all freedoms to process the
data to any rules they may find suitable, but no harm is done to the community
or the core database.
More information about the dev