[OSM-talk] [OSM-dev] Developers requested to help provide "completeness" tools

[Andy Allan]

On Mon, May 12, 2008 at 8:16 PM, David Earl <david at frankieandshadow.com> wrote:

>  I think it is terribly hard to know whether you have all the footpaths,
>  and I think we'd hardly ever mark anywhere "complete" if we did that.

I think it's terribly hard to know when a map is correct and complete,
regardless of what you're considering.

In fact, as something I've floated with some people before, I think
the idea of "completeness" is the wrong way round. I think we should
be considering where a map is *incomplete*.

Think about it. If you are presented with a map of your village and
asked whether it's right, it's very unlikely that you know all the
roads and all the names and how everything connects and be sure of
yourself. But it's quite likely that what you'll spot (if anything) is
a mistake or a missing road. I can do this with TIGER stuff for
example - I can't tell you if the map is correct, but I can definitely
find bits that are definitely wrong.

I've been considering what I'd do to Wandsworth and Fulham (my local
areas) if someone asked me to mark which areas are correct. I think
there's very little value in me doing so, since most roads I've only
been down once and hardly likely to check the name from memory. But
there's a couple of bits that are definitely wrong, and I can point
them out easily.

It's just another way of thinking about it, but I think that
neutral/wrong is probably more useful than neutral/complete when
considering maps. And it certainly cuts out trying to define
'complete', since whichever reason something is wrong (name,
connectivity, missingness) it's very easy to state why it's wrong. And
rather than more and more being complete (for this, that and the other
definition of complete) there'll be fewer and fewer bits that are
wrong.

Nobody ever looks at a map and remarked how many bits were correct.
Nor does any software product keep a list of lines of code that are
working. Or it's an 'exception driven' way of considering things.

Cheers,
Andy