<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font size="-1"><font face="Calibri">Hi Jean-Marc,<br>
<br>
Thanks for bringing up the topic in a constructive manner! I do
agree it's valuable to question and examine some of our basic
assumptions sometimes. </font></font><font size="-1"><font
face="Calibri"><font size="-1"><font face="Calibri">Please do
keep in mind that to some extent this is still a developing
field. Having access to this type & level of data we are
creating is novel in a lot of contexts, and creating as
comprehensive and reliable datasets as we can is also a
method of </font></font></font></font><font size="-1"><font
face="Calibri"><font size="-1"><font face="Calibri"><font
size="-1"><font face="Calibri"><font size="-1"><font
face="Calibri"> the making it possible for people to
start developing and implementing the use cases for
this data</font></font></font></font>.</font></font>
So to address the "why are we mapping buildings" question, let
me sketch two current use cases where the building footprint
data is being used by NGO and gov't partners:<br>
</font></font>
<ul>
<li><font size="-1"><font face="Calibri">Malaria elimination (and
several other health-related use cases). We've been working
in southern Africa and Mali with various partners to
digitize buildings. This data is amended with data
collection and field mapping exercises, where we record
(amongst other attributes) building and roof materials, number
of rooms, and the number of sleeping spaces (where the
latter two are not public/OSM data). The building outlines </font></font><font
size="-1"><font face="Calibri"><font size="-1"><font
face="Calibri">(and thus size and shape of buildings)</font></font>
in conjunction with this data allow for much better
extrapolation to inform what type of interventions to apply
to which building, to inform procurement and distribution of
bed nets, insecticide, logistics of spraying teams, etc (see
<a class="moz-txt-link-freetext" href="https://www.hotosm.org/updates/field-surveying-in-botswana-to-support-the-national-malaria-programme/">https://www.hotosm.org/updates/field-surveying-in-botswana-to-support-the-national-malaria-programme/</a>).<br>
</font></font></li>
<li><font size="-1"><font face="Calibri">Rural electrification
(including mini-grids and other sustainable energy options).
Information on estimated number of households, size and
density of villages, estimated number of
public/commercial/industrial buildings, estimated </font></font><font
size="-1"><font face="Calibri"><font size="-1"><font
face="Calibri">relative </font></font>economic activity/wealth
indicators, in combination with datasets on current
electricity grid and grid expansion planning feeds into
analysis on what which sites would be most attractive/feasible
for small, standalone solar, hydro and wind-powered grids.</font></font><br>
</li>
</ul>
<font size="-1"><font face="Calibri">In some areas, where just
having data is the priority and urgency, we do start out by just
marking `landuse=residential` afaik (see Congo/Ebola recently).
There are however also other datasets available that are
relatively reliable in identifying inhabited areas (such as
WorldPop, GPW, </font></font><font size="-1"><font
face="Calibri">HRSL, etc) that can also serve as the basis. So
following up and continuing with digitizing building outlines
where time and (relative) lack of urgency allows does provide a
much improved starting point for additional and more 'advanced'
use of these datasets. Even without any further data on building
use, type, or materials, what improves the use for these
analyses are having access to a) the size of the building, in
order to (for example) estimate which are residential, which are
too small & thus more likely storage/shed/pen etc, and which
are large & more likely to be commercial, industrial or
public buildings, and b) shape of the building (for example,
round vs square). </font></font><font size="-1"><font
face="Calibri"><font size="-1"><font face="Calibri">And to
acknowledge another point, yes, AI/ML will come into the
equation (relatively soon, even; way earlier than "ten
years") and we will need to think about how to deal with
this type of 'generated' data, with the OSMF.<br>
<br>
</font></font>Further down the line, the real value in having
a building dataset that includes geometry is that it allows you
much more accurately </font></font><font size="-1"><font
face="Calibri"><font size="-1"><font face="Calibri">attach
additional attributes/data to these polygons, in the process
creating a historical record of the existence of this
specific building (which is also useful for land rights/ownership
purposes), and</font></font> enter into a process of
refinement and enrichment of that data.I definitely agree that
trying to get "all" buildings mapped is a herculean task - how
many would there be in total, 3 billion or so? At which point we
get into the really difficult task of trying to keep this
dataset updated and accurate. That doesn't take away from your
point that 'low-quality' mapping, due to a number of reasons and
causes, is a large problem. We are/should be working to improve
mapper retention, upskilling, and make validation more
fun/attractive, but this is a topic others can speak to better
than me. Hope this helps a bit in understanding some of the
reasoning!<br>
<br>
best,<br>
Paul<br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 4-7-2018 10:16, Jean-Marc Liotier
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:593fb9836dcb428fc898d88f4ed3fea7.squirrel@webmail.grabeuh.com">
<pre wrap="">On Tue, July 3, 2018 7:20 pm, john whelan wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think my concern is more about the 'then a miracle occurs' in the
project plan to clean up the buildings.
</pre>
</blockquote>
<pre wrap="">
Yes because, among other reasons:
- For most people, verifying is not as gratifying as creating
- Correcting entirely incorrect geometries is many ways more work than
re-creating them from scratch
I am not concerned about the most egregious cases: cars & trucks modelled
as buildings, duplicates & superposed, rubbish heaps and vague shadows as
building=yes, buildings found in old imagery... Those I delete with no
hesitation.
I am not concerned either about minor simplifications or errors such as
the shape being traced on the roof of the building rather than its base -
those I let them be and correcting them capitalizes on a good foundation.
I am concerned about the cases where a building does exist in reality, the
shape is less than ten meters from its position, some of the shape
overlaps the building's position on the imagery and some of the shape
resembles some of the building. In those cases, there is some value in the
record: approximate position and area of the building. But there is also
the liability of having introduced a low-quality object in the database.
I am convinced that the immense majority of those buildings will never be
corrected. In ten years, we can expect massive campaigns of automated
image recognition to produce new building layers - but even then the
extensive conflation will be an horribly tedious job.
Meanwhile, for areas with reliable imagery, I can imagine Maproulette
jobs: something in the spirit of "Does this building at least partially
overlap one in the imagery and does it approximately resemble the one in
the imagery ?". Those jobs could be designed at national or regional
levels - under control of the local communities. They could be a way of
systematic quality control. But maybe I'm horribly deluded about how many
people would volunteer for such a mind-numbing task. Also, looking at
buildings one at a time is very inefficient compared to panning through an
area on JOSM - but then again, JOSM-enabled contributors that might be
motivated for this are not exactly in plentiful supply either.
And that does not even answer the question: what to do with the
"low-quality shape but actually exists" cases ? I am at a loss to answer
that.
_______________________________________________
HOT mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HOT@openstreetmap.org">HOT@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/hot">https://lists.openstreetmap.org/listinfo/hot</a>
</pre>
</blockquote>
<br>
</body>
</html>