[OSM-dev] Data source for robot
ssinger_pg at sympatico.ca
Wed Oct 13 03:04:54 BST 2010
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
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
> 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.
More information about the dev