[OSM-dev] Data source for robot

[Steve Singer]

On Wed, 13 Oct 2010, Jonathan Bennett wrote:

> Are you willing to check, by hand, every single change made by this bot? If 
> not, how can you be sure it hasn't created as many problems as it has solved? 
> That's the problem with automated edits -- people assume they're 100% correct 
> when experience has shown this not to be true.
>

When you manually edit a part of the map how can you be 100% sure your not 
creating a problem? You can't.  Hand editting creates errors and problems as 
well, that doesn't mean we should stop doing it or ban it.  Any large enough 
set of edits done manually or by a script will introduce some problems and 
mistakes.  I know from experience that most times I spend an afternoon 
mapping I introduce a few errors into the map that I don't usually find out 
about until months after (either when I see someone else fixing the issue or 
if I revisit the area and notice it). I'm sure I introduce a lot more errors 
that don't get caught (and don't even get me started on the errors people 
introduce tracing places from Yahoo images that they've never visited). 
Does this mean I shouldn't be able to hand-edit the map? no. Your standard 
is unreasonable.

The standard for an import or a hand editing session should be based on 
does the edit/import/script make the map on substantially better off than it 
was without the edit.  We have an editable map we can always fix the 1% of 
mistakes if the other 99% of the work is an improvement.

Having said that the import has to be aiming to do something that there is a 
consensus for.  You can't just run a script to add highways to relations if 
there isn't a broad agreement that highways of that type should be added to 
those relations.  Building this type of consensus in the OSM community can 
take a long time (months).  You can't just write your script and run it on 
the live database.

I agree with another poster on the thread that most time spent on doing an 
import is spent fixing the problems the bugs in your script created. 
Importers must have the technical skills to do able to deal with these 
things and be prepared to spend the time fixing them.

OSM isn't just about providing a place for mappers to map, we are primarily 
in the business of providing map data that people can freely use to make 
maps.  Big blank pages with a few lines going through them don't make very 
good maps. Many people use OSM data who don't want to run around with a GPS 
they just want a free map and thats okay.

Outside of Western Europe a lot of the world is sparsely populated.  Imports 
have given us maps of places that roads don't lead to.  Even with OSM's 
exponential growth it would probably take decades until much of rural North 
America was mapped without some form import and the same probably applies to 
Australia or Russia.

What we should be doing is trying to figure out what tools, procedures and 
processes can be put in place to make imports work smoother instead of 
bashing anyone who shows an interest in doing an import with 'imports are 
evil'


> What's getting missed in all this is that it's far less important that OSM 
> uses a particular data structure (that's probably isomorphic to the 
> alternative anyway) than that the data is an accurate representation of 
> what's on the ground. That needs people to check it, and it's a far greater 
> job than a quick tag fix-up.
>
> By all means run the experiment off-line and publish the results, just don't 
> assume you've thought of everything, and nothing can go wrong.
>
> Jonathan.
>

Steve