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
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
