I’m an occasional humanitarian and agree with Pete that I’ve never heard serious complaints from humanitarian actors about the quality of the OSM data. Certainly no one has said it would be preferable to having no data at all.
However, we need to be sensitive to the local OSM communities who will clean up any bad data mess we leave behind. I live in Nepal now and recently did some mapping work in an area traced by HOT after the Nepal earthquake. The quality was sometimes bad and cleanup was time consuming. I recognize that it was much, much better to have the data there during the response. It was much, much better to have the data there for my project even. But that’s no reason not to aspire to better data in the long term. OSM is not just a humanitarian platform, it’s also a worldwide community with many non-humanitarian uses. As heavy users we have a special obligation to respect that and maybe work a little harder to get our data to “good” instead of “good enough”. I don’t know whether that’s possible but we should at least try. I don’t mean this to take away from the positive discussion with lots of interesting ideas here. I completely agree that we should stay as open as possible to new mappers and while making HOT mapping a more guided process with appropriate safeguards. On Thu, Oct 13, 2016 at 3:54 PM Joseph Reeves <iknowjos...@gmail.com> wrote: > Hi all, > > "Having said that, I'd like to punt this back to Phil and Sev as I speak > to people in the field, who use the data, on a regular basis. Data quality, > so far, has almost never come up as an issue. Do you guys have different > experience or feedback from field teams? It would be useful to know > specifics if you have." > > This was the question I've been thinking about for a while now and now > might be an appropriate time to bring it up. Pete said it better than I > could! > > In short - do square buildings matter for disaster relief mapping? Is > there an acceptable trade-off between mapping quality and response time? > > That's a general question which I think needs to be informed with more > specifics to this case, starting with: > > What is the OpenStreetMap data going to be used for? > If we're creating population estimates of an area, is it enough to know > the number of buildings or will the geometries be important? > What organisation requested the data? > What feedback have you received from people on the ground? > > Sev, you've said "Mapping in OSM in crisis response is not an exciting > one-shot hobby", which I can agree with, but if we're going for > professionalism I think we should consider the above questions, and plenty > more than I'm sure others will have. Anyone can install a copy of the > Tasking Manager and get together a skilled group of OSM Humanitarian > mappers to engage in crises response, but without a requesting organisation > providing goals and feedback it's surely still just a well organised hobby? > > Personally I've always wondered if we could just use nodes for buildings. > We'd get the work done much quicker that way, but it may not look so good > on map! > > Cheers, Joseph > > > > > On 13 October 2016 at 07:43, Pete Masters <pedrito1...@googlemail.com> > wrote: > > Hi all, > > Data quality is a major issue I think. And I think especially validation. > Firstly, that validators are barely recognised in the current tasking > manager and secondly that anyone can validate. > > In MSF, people who are unfamiliar with OSM are much reassured that there > is a validation process. However, a short browse of the tasking manager > tells you that many projects are not totally validated (despite the > incredible efforts of the validators in the community). For me there is a > significant risk here of losing the trust of the people who use the data. > > Having said that, I'd like to punt this back to Phil and Sev as I speak to > people in the field, who use the data, on a regular basis. Data quality, so > far, has almost never come up as an issue. Do you guys have different > experience or feedback from field teams? It would be useful to know > specifics if you have. > > Cheers, > > Pete > > On 13 Oct 2016 07:31, "Robert Banick" <rban...@gmail.com> wrote: > > Hi all, > > HOT is clearly one of, if not the, most successful crowdsourcing projects > for humanitarian response in the world. Success means not just contributors > but also use of the data by actual humanitarians. It’s unsurprising we’re > encountering some limits to the approach and need to evolve it. > > I like Phil and John’s automated approach to these things. I think the > Tasking Manager has proven that the best way to manage these interactions > is through an automated platform. My only concern is making what’s > currently straightforward overly complex and intimidating for new users. > But that’s a call for good design and introductory materials, not dumbing > down our approach. > > However, it’s the middle of a disaster and clearly not the time for > wholesale changes. I suggest we flag these thoughts for the forthcoming > Tasking Manager redesign and embrace makeshift systems in the meantime. > > Cheers, > Robert > > On Thu, Oct 13, 2016 at 8:31 AM Phil (The Geek) Wyatt < > p...@wyatt-family.com> wrote: > > Hi Folks, > > > > I am a retired long time map user, occasional mapper (in QGIS, Mapinfo) > and supporter of the OSM mapping project. It seems to me that the issue of > poor mapping, especially for HOT projects, is coming up on such a regular > basis that it's time to consider some mandatory training for users before > they get to map under the HOT task manager. I don't think this would be too > difficult for most volunteers and it could ensure that at least a certain > level of competency is attained before being exposed to complex tasks. If > people know that in the first place then they can make a choice as to > whether they commence or continue to map. > > > > I have no idea how this could be accomplished as I know little of the > linkages between OSM and the HOT Task Manager, but restricting HOT tasks to > those with some defined training could improve the results. > > > > Let's say as a minimum you train folks on roads and residential area > polygons - that might be level 1 (ID Editor) > > Level 2 could be after training for buildings, tracks, paths (ID or JOSM) > > Level 3 for validation (JOSM) > > > > In this way HOT tasks simply get assigned at each level and you know you > have the right people doing the tasks at hand. The task manager could also > only highlight jobs at their assigned level until they do the next level > training. > > > > You might even consider, as part of validation, dropping people from a > higher level to a lower level if they continually fail to produce results > at the desired consistency. > > > > Just my thoughts as a casual mapper. > > > > > > Cheers - Phil > > > > Thin Green Line Supporter <http://www.thingreenline.org.au/>, Volunteer > Mapper (GISMO) - Red Cross <http://www.redcross.org.au/volunteering.aspx> > > > > > > *From:* Severin Menard [mailto:severin.men...@gmail.com] > *Sent:* Thursday, October 13, 2016 4:34 AM > *To:* hot@openstreetmap.org > *Subject:* [HOT] OSM humanitarian mapping and its learning curve > > > > The edits on hotosm.org job #2228 <http://tasks.hotosm.org/project/2228> > have started and now happens what I feared. There is no mention of what are > the necessary skills and newbies are coming with a lot of enthusiasm but > with almost no OSM experience. A quick analysis of the first 29 > contributors shows that 20 of them have created their OSM account less than > one month ago. Some did it yesterday or today. Wow. > > The result of that : obviously, crappy edits are coming, spoiling what we > have been doing over the last few days : now we have building as nodes > where shapes are totally visible, un-squared bad shaped buildings and the > main landuse area is self-cutting in various places (see there > <https://leslibresgeographes.org/jirafeau/f.php?h=26gWjHki&p=1>). > > Nothing new under the sun : it was already the case for Haiti EarthQuake > 2010. Quite a pity that six years after, despite the OSM tools have > improved a lot, it remains the same. It is though quite simple to fix the > most part of it: > do-not-invite-newcomers-to-map-over-complex-crisis-contexts. > > I guess some will argue that the OSM newcomers are people of good will and > that they just want to help and that they my feel offended/discouraged. Of > course their intentions are high and yes they may feel a bit hurt. But this > is really a classic in humanitarian response: people with the best > intentions in the world may not fit for it, just because they are not > experienced yet. > > > > Mapping in OSM in crisis response is not an exciting one-shot hobby : it > does have its learning curve and it is key to learn how to map correctly > before being dropped over complex humanitarian contexts. This is why I > mentioned three sets of necessary skills for the jobs I created these last > days on http://taches.francophonelibre.org. And the beginner mappers who > joined the job that fitted for beginners are people that already have a few > months of OSM experience, not newcomers. Newcomers should be driven over > non urgent fields. > > If someone is not interested to learn first in not a mass media covered > crisis context : this is not a problem, it is actually a good way to see > real motivations. I personally prefer to get one mapper that will become a > huge, excellent contributor, 3-4 more occasional but still producing neat > data, than to lose 10 that would create crappy objects and just leave > forever afterwards anyway. > > > > I guess the resulting need of duplicating the number of necessary edits > (crappy ones then corrections) to get a clean data is a rather a good way > to grow the number of total contributors and the number of total edits > created through the # of the HOT TM instance that seems to be so important > for the board of HOT US Inc (two current directors have contacted me for > this purpose) to make communication and raise funds from the figures. But > what is at stake here is to provide good baseline data for humanitarian > response, not distorted metrics. > > Séverin > _______________________________________________ > HOT mailing list > HOT@openstreetmap.org > https://lists.openstreetmap.org/listinfo/hot > > > _______________________________________________ > HOT mailing list > HOT@openstreetmap.org > https://lists.openstreetmap.org/listinfo/hot > > > _______________________________________________ > HOT mailing list > HOT@openstreetmap.org > https://lists.openstreetmap.org/listinfo/hot > > >
_______________________________________________ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
