[Talk-us] OSM Data Quality

stevea steveaOSM at softworkers.com
Fri May 31 22:02:47 UTC 2013


Frederic:

Validator is an excellent tool, but currently only works with JOSM. 
I'd love to see Potlatch and/or iD do something similar.  True, many 
(most) ignore what Validator may report, and while Errors are always 
Errors, Warnings are a bit more subtle and really must be taken one 
at a time on a case-by-case basis.  Doing the right thing with a 
Validator Warning takes experience, and for ultimate data quality, 
Validator really needs to be paid attention to much more often than 
it is now.  However, you may argue that such entry-level editors do 
not lend themselves well to such an approach.  We might talk about 
that, as "done well," it could work.

I would also vote for experienced OSM importers "looking over the 
shoulder" of less experienced contributors as they import data.  We 
try to do this with the import guidelines, but there is nothing like 
an experienced OSM contributor who has faced (and overcome) difficult 
choices about data format translations, exactly what should be in 
what tags, what to do with fuzzily defined concepts (like landuse vs. 
landcover) issues, etc.  This really comes from building good OSM 
community, where the "Elmers" (an old ham radio term meaning "those 
more experienced") are around to answer questions, mentor and be a 
good example to the less experienced.  That's a tall order, and a 
little non-specific, I know.

The recent "game/goal-oriented" sub-projects (connectivity, Zorro...) 
have had fantastic results.  We could use more of these, as their 
success is proven.  Wider attempts like Operation Cowboy, not so 
much, however the "cake map" (http://http://mapcraft.nanodesu.ru/ ) 
used in Cowboy is an exceedingly useful tool when used properly (by 
an active, communicative OSM community -- I speak from personal, 
recent experience).

The OSM Inspector tools (http://tools.geofabrik.de/osmi/) I find 
highly valuable.  If we could get something like a Zorro/Cowboy 
approach to work with the first three tool categories (Geometry, 
Routing and Multipolygons), that would be fantastic.  This would have 
to be really, really well-prepped, and again, it does take experience 
to use this tool and "see what is wrong, then fix it to be right." 
However, if possible, (I think it is, but it is admittedly 
ambitious), imagine the results in data quality!

Clifford Snow writes:
>First you need to define what good data quality is and second, you 
>need to collect data to measure data quality. Once good data is 
>collect then start determining root cause of the problem.
>
>Most of what I see is anecdotal evidence of problems. Fixing the 
>cause of those problems is good, but it may not get at the 
>underlying issues.

I say +1 to this, but it is nebulous as to be only broadly helpful. 
Clifford, care to flesh that out a bit?

The USA OSM community is, as Martijn pointed out, lagging in many 
ways compared to those in Europe.  I say that not to disrespect us, 
but as I point out that we are "behind a few years," we have a much 
broader area (one of the most important reasons why, truthfully), and 
we have lower population densities (a corollary of, and another, more 
specific way of "broader area" just mentioned).  So the traction to 
get good mappers mapping is slower to grip and go.  We are doing the 
right things, we just seem to be getting slower results.  But our 
results are very good, even excellent in some cases.  Yet, per this 
thread, we really can do better.

Good thread!

SteveA
California


>I'm working on a presentation and interested to hear your thoughts. 
>What are the top 2-3 changes that could improve OSM data quality? 
>That could be processes, tools, methods, training, peer review, 
>attributes, etc.
>
>If this sort of info is available elsewhere let me know.
>
>Looking forward to your answers.
>
>Many thanks,
>
>Frederic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20130531/7e71f9f3/attachment.html>


More information about the Talk-us mailing list