[HOT] OSM humanitarian mapping and its learning curve
iknowjoseph at gmail.com
Thu Oct 13 10:09:28 UTC 2016
"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
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 13 October 2016 at 07:43, Pete Masters <pedrito1414 at googlemail.com>
> 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.
> On 13 Oct 2016 07:31, "Robert Banick" <rbanick at 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.
>> On Thu, Oct 13, 2016 at 8:31 AM Phil (The Geek) Wyatt <
>> phil at 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
>>> 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
>>> *From:* Severin Menard [mailto:severin.menard at gmail.com]
>>> *Sent:* Thursday, October 13, 2016 4:34 AM
>>> *To:* hot at 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
>>> 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
>>> 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.
>>> HOT mailing list
>>> HOT at openstreetmap.org
>> HOT mailing list
>> HOT at openstreetmap.org
> HOT mailing list
> HOT at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the HOT