Well this is drifting off the original topic but... Greg Morgan <dr.kludge...@gmail.com> wrote: > This is nothing more than an uneducated attack on my favorite part of the > US tax code, 501.c3. This is also nothing more than an attack on a group > trying to build the OSM community.
Seems a bit strong. Some folks need to try harder to understand the issues of data quality that we have. Even with validation steps in place, we produce fairly poor quality data sometimes. Jean-Marc is not making that up. We want to continue welcoming lots of new contributors and recognising that they will make mistakes, but validation and eventually converging on good quality data is something we still need to get better at. No need to take this as an attack, although... > Jean-Marc Liotier <j...@liotier.org> wrote: > If one needs number to report back to donors, then integrate this sort of > thing with the task manager - and explain to donors how erroneous data is> > sharply negative value I think this little "number to report back to donors" comment does betray a belief I've heard expressed quite often in the wider OSM community, that humanitarian mappers are allowing OpenStreetMap to be co-opted by large aid organisations (to various evil ends?!) This all seems very cynical and glass-half-emtpy to me, but I ask myself whether there's anything to be done to allay those fears. Probably not a lot. I've heard some surprising concern (and cynicism) about who is designing task manager projects and why. To me this suggests we could do a better a job of describing the "why" story behind the projects sometimes. Jean-Marc is making a technical suggestion which I want to echo. >"Integrating within the task manager the tracking of the quantity of Osmose >defects would go some way towards addressing the monitoring of actual quality" I like this idea. It doesn't necessarily need to be osmose, but I definitely feel like we could weave in more automated data checks. Imagine a count of data bugs between each comment/action on the timeline of a task square, so we can see errors increasing as a beginner adds lots of new data, and hopefully reducing as validators fix or give feedback (Not that all types of human validation work would be reflected in automated checks but...) These tools have been known in OSM as "Quality Assurance" tools. To Frederik's point, personally I actually think *this* naming, which we settled on a long time ago, is weirdly over-broad. We should have called them "data checks" or "data bugs" or something, because surely "quality" of a map is much more than counting up how many data glitches there are, and surely it *does* include how complete the map is (e.g. complete with more rich POI coverage) Which brings me onto my last point. Actually when I look back at the MapCampaigner tool (Yes. That's what we were supposed to be commenting on here!) I'm surprised to find that it seems to have little to do with our most quantity-heavy remote building mapping TM projects. So that's all a bit off topic. The example trackers on there are for progress with on-the-ground POI mapping. Good stuff! While some folks will still fear that this aid organisation work is evil somehow, I generally feel that on-the-ground mapping by aid organisations is precious and to be celebrated and boosted as much as possible. Harry _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
