[OSM-talk] Quality assurance strategy?

[Frederik Ramm]

Hi,

> Some time ago there was discussion about roads which really
> do not have names vs. roads which have names but they are not yet  
> entered.

A problem we'll see in many other places as well - e.g. a junction  
that has no turn restrictions vs. a junction that just doesn't have  
them entered yet. Which is the harder case since the majority of  
junctions don't have turn restrictions (whereas the majority of roads  
do have names).

> There
> is also a separate OpenStreetBugs service for informing on any  
> errors on the
> map. Tagwatch is another tool that can be used for QA. However, I  
> think that at
> the moment it is very hard to find out, let's say, all the features  
> in one city
> that needs verification.

Well, the ITO tools at least offer you a graphical representation of  
the "age" of mapping in a user-defined area so you can check whether  
it's fresh or not. Of course it would also be possible to generate  
lists of objects coming up for "revalidation" - restaurants once a  
year, roads once every 5 years, and pot joints once a week.

> Any thoughts about how to make it easier?  Should
> there be an annexed quolity control report that is linked to OSM  
> feautures by
> feature id?  Or could each tag has an quality assurance tag like  
> True='I know
> this information is OK', False='This information is uncertain'?

I would like to have that information separate from the rest because  
it is not data about the real world but data about our data. If I  
were to tag a way with the information "this way needs verification  
becaus it has not been edted in the last 2 years" then I would edit  
the way by doing so...

What you're speaking of is a huge amount of work if one wants to do  
it properly. I have no doubts that we'll manage to map the world  
once, but will we be able to map it again every 5 years, essentially,  
to verify? I don't know.

I have been thinking about a system where you do not wait for people  
to take responsibility and say "this way is correct as of <date>,  
signed <name>", instead turn this around: The quality of an area is  
not defined by the number of quality assertions, but by the absence  
of error reports!

Suppose you have a really easy error reporting mechanism right on our  
central map page, a big fat "report error here" button. Suppose that  
you cleverly analyse log files (and those of mirrors/caches  
obviously), so you know how many people have looked at a certain area  
within the last month (and perhaps even how long they have looked).  
Then you can say: "150 people have looked at the map you're seeing  
without reporting an error". Of course only a fraction of viewers  
will notice an error and only a fraction of those will report it, but  
if the numbers are high enough, you should get reliable statistical  
effects.

>  OSM quality supervisors

*shudder* ;-)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"