[OSM-talk] Automated edits code of conduct

[Andy Townsend]

On 14/07/2016 16:19, Éric Gillet wrote:
> So if the changeset correct 300 restaurants but 2 are "damaged" by the 
> automated edit, would the edit be bad enough to be reverted or not be 
> done in the first place ?

I'd revert it.  It's essentially the same as the "trees" example 
upthread (where the mechanical editor thought incorrectly that deciduous 
implied broadleaved, and vice versa).  It's easy for people processing 
OSM data to say "obviously these are mistaggings; I'll assume that 
people have just got it wrong".  However, going to Burkina Faso (in the 
Mac Donald example) is inherantly much harder; we need to respect 
someone who's actually been there.

Where there a small number of potential mistaggings the correct approach 
would be to _ask the previous mapper_ or if that doesn't work _ask 
someone else in the area_.  OSM provides tools that makes it really easy 
to do exactly that.

You might argue "but surely if more data is corrected than damaged the 
overall quality is improved?" but you'd be wrong.  It's important to 
leave as much original data there as possible for downstream 
processing.  I spent a good few years in the 80s and 90s arguing the 
superiority of statistical approaches to data interpretation over 
rule-based ones.  To cut a long story short, there's a reason why e.g. 
the anti-spam measures used with email today are Bayesian (statistical) 
- it works.  Don't second-guess what data consumers might need if you've 
not been one.

That doesn't mean that if you see that someone has mapped an obvious 
primary highway as "highway=pirmary" that you shouldn't change it - but 
do always ask yourself if by "tidying up" you're actually removing 
information from OSM, even if that information is "there is some doubt 
as to whether the original mapper knew what they were doing".

Best Regards,

Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20160714/6c0b309e/attachment.html>