<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">When you look at importing Montreal you might like to look at the following first.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><a href="https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants">https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants</a></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Note if the Montreal data in available through Stats Can and the federal government open data license it might be better to use that data source from a licensing perspective.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Although data can be given to OpenStreetMap I don't think there in a foolproof method of recording the fact. If one person has the paper record fine but if they are no longer part of the community then there maybe a problem if the license is challenged.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Cheerio John<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 10 Feb 2019 at 00:04, Tim Elrick <<a href="mailto:osm@elrick.de">osm@elrick.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_-977679983682700784moz-cite-prefix">Hi all,</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">After following the building import
discussion for a while now, I wanted to chime in as well.</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">After moving to Montréal from Germany
recently, I got more engaged with the local mappers here in MTL
(beforehand, I was more analysing OSM data scientifically).</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">I took part in the initial meeting of
the Building Canada 2020 initiative, in which great interest in
the project was expressed by many institutions, organizations and
businesses. However, apart from Statistics Canada, municipalities
and OSMappers no one seemed to be willing to invest into the
effort to support the initiative with manpower or funding (to my
knowledge). Therefore, I found it quite impressive what StatCan
has achieved with the Open Building Database and do not share the
view of some on this list that the initiative got off on the wrong
foot; but that all water under the bridge now. <br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">So, yes, there seems to be some
interest to use the data from the Open Building Database in OSM
easily. However, I am also hesitant, that one massive import can
be the answer.</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">I'm generally hesitant with imports as
such, maybe because I was acculturated in OSM in Germany where
OSMappers value original entries much more than secondary data.
Further, I'm skeptical, that secondary data is necessary better
than original data (even from mapathons). I initiated two
mapathons with university students in the context of Building
Canada 2020. Both mapathons resulted in mostly nice buildings, I
would say - and, when there is the odd not-so-nice building, there
is still the validation step as we always used the tasking manager
[1]. By the way, both mapathons used the ID editor; and, of
course, you can square buildings in ID as well; so, I don't really
understand the ID editor bashing that appears on this list here
now and then. That said, of course, I prefer JOSM over ID as it is
the more versatile tool, but to introduce interested persons to
editing in OSM, ID is really nice.<br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">I'm even more skeptical about imports
after Yaro pointed us to the Texas import [2]. I wonder why there
was no outcry there (or maybe there was and I did not hear about
it) - the imported data is terrible: no parallel to street
buildings, no right angles, sometimes even not the right size of
building parts. Fact is that secondary data buildings footprints
can be from many different data sources - from AutoCAD, handdrawn
by a municipal GIS experts to photogrammetric and satellite
machine learning sources; all those sources have their
peculiarities, which I think, you cannot satisfy in one import
plan fits all - especially, as the Open Building Database in
Canada is stitched together from those very different sources.</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">In Montreal, e.g., the source for the
Open Building Database is the données ouvertes des batiments. This
is photogrammetric imagery probably turned into AutoCAD files,
which then were exported to a shapefile and geojson. The building
outlines are impressively precise, however, the open data files
contain building blocks not single buildings [3], however, offer
building dividers in a separate shapefile (I assume due to the
export from AutoCAD, see second image in [3]). Unfortunately, the
Open Building Database only included those building blocks in
their data set, making it not very easy to import into OSM (as
they do not include the building dividers). Hence, a bit of
non-trivial pre-processing of the original données ouvertes des
batiments would be necessary to import them into OSM (as the
building divider file does also include roof extensions and roof
shapes). The local OSM group is discussing this pre-processing for
a while now at their local meetings (we started discussing this
even before the Building Canada 2020 initiative started). As the
City of Montreal has granted OSM the explicit use of their open
data file, the way forward, we think, is to pre-process the
original files. Further, there is extensive overlap of existing
buildings with the open data file. Therefore, the imports in
Montreal would have to happen in very small batches to not destroy
the work of other OSMappers.<br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
I am also pretty skeptical about the simplification of the secondary
data before importing that was suggested on the list here. As the
data sources of the Open Building Database are very diverse, one
simplification method cannot fit all data sources and can lead to
harming the ground-truth principle. This even happened when Nate
tried to simplify buildings by hand in Toronto [4], as pointed out
by Yaro. There might be the odd case, where secondary data has too
many nodes in a straight line, but, usually, I would assume, that
most data sources stem from GIS experts or machine learning
algorithms; neither would include more nodes than necessary for a
building outline. And honestly, I don't buy the argument of 'too
much data clutters our planet dump'. Storage space and processing
power is no longer an issue, and I would like to see the world as
precisely represented as possible in OSM; in many parts of the OSM
world you now find single trees, mailboxes and lamp posts in OSM;
isn't that great? As for buildings, I would like to see all the bay
windows, nooks and crannies - even in Canada. <br>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">How to proceed? For Montréal: After we
looked more into the challenges of pre-processing the Montreal
open dataset, I guess, we will propose a separate import plan. If
anyone would like to join us in discussing the pre-processing,
please contact me and we can continue on the Montréal OSM list.
Oh, and by the way, while we all were discussing the import since
December almost 3,000 buildings were mapped by hand in the Greater
Montreal region [5].<br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">That all being said, I do not want to
stop anyone of you from importing buildings. I just think, that we
have to do this more bit by bit to cater for all the peculiarities
of the heterogeneous data sources of the Open Building Database.</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">Happy mapping to everyone,</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">Tim<br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">[1] see e.g.
<a class="gmail-m_-977679983682700784moz-txt-link-freetext" href="http://tasks.osmcanada.ca/project/91" target="_blank">http://tasks.osmcanada.ca/project/91</a></div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">[2] <a href="https://www.openstreetmap.org/#map=19/32.97102/-96.78231" target="_blank">https://www.openstreetmap.org/#map=19/32.97102/-96.78231</a></div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">[3] <a class="gmail-m_-977679983682700784moz-txt-link-freetext" href="https://imgur.com/a/S8Nq5rg" target="_blank">https://imgur.com/a/S8Nq5rg</a></div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">[4] <a href="https://i.imgur.com/H10360K.png" target="_blank">https://i.imgur.com/H10360K.png</a></div>
<div class="gmail-m_-977679983682700784moz-cite-prefix">[5] <a class="gmail-m_-977679983682700784moz-txt-link-freetext" href="http://overpass-turbo.eu/s/FWH" target="_blank">http://overpass-turbo.eu/s/FWH</a><br>
</div>
<div class="gmail-m_-977679983682700784moz-cite-prefix"><br>
On 2019-02-03 18:35, Yaro Shkvorets wrote:<br>
</div>
<div class="gmail-m_-977679983682700784replaced-blockquote" type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Having reviewed the changeset, here are my 2
cents. OsmCha link for reference: <a href="https://osmcha.mapbox.com/changesets/66881357/" target="_blank">https://osmcha.mapbox.com/changesets/66881357/</a></div>
<div dir="ltr"><br>
<div>1) IMO squaring is not needed in most of those
cases. </div>
<div>- You can see difference between square and
non-square ONLY at high zoom level. And even then, it's
not visible to the naked eye. We are talking about
inches here. </div>
</div>
</div>
- Sometimes squaring is plain wrong to be applied here. Even
though you paid very close attention you managed to square a
couple of non-square buildings. Like this facade is not
supposed to be square for example: <a href="https://i.imgur.com/H10360K.png" target="_blank">https://i.imgur.com/H10360K.png</a> I
might be OK with squaring almost-square angles if there is a
simple plugin for that. The way you propose to do it, by going
building-by-building and pressing Q is completely
unsustainable and sometimes makes things bad.<br>
- Another thing, this particular neighbourhood is pretty dense
and mature and therefore has mostly square buildings. I can
only imagine how bad it would become if you ask people to
square things in newer developments where buildings often come
in irregular shapes.
<div>- Like mentioned above, many successful import didn't
require squaring. In this Texas one, 100% of buildings are
not perfectly square: <a href="https://www.openstreetmap.org/#map=19/32.97102/-96.78231" target="_blank">https://www.openstreetmap.org/#map=19/32.97102/-96.78231</a><br>
<blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px">
<div><br>
</div>
</blockquote>
<div dir="ltr">
<div dir="ltr">
<div>2) Simplification is good to have, sure. Obviously
standard Shift-Y in JOSM is a no-starter. If we can
find a good way to simplify ways without losing
original geometry and causing overlapping issues we
should do it. But even then, reducing 500MB province
extract to 499MB should not be a hill to die on.</div>
<div><br>
</div>
<div>3) Manually mapping all the sheds and garages is
completely unsustainable. Having seen over the last
couple of years how much real interest there is in
doing actual work importing buildings in Canada
(almost zero) adding this requirement will undoubtedly
kill the project. Sure you will meticulously map your
own neighbourhood, but who will map thousands of other
places with the same attention to details? Also, you
did rather poor job at classifying buildings you add,
tagging them all with building=yes. Properly
classifying secondary buildings like sheds and garages
in a project like this is pretty important IMO. I
agree with John, we should leave sheds to local
mappers to trace manually.</div>
<div><br>
</div>
<div>To sum up, yes we can do better. But this is the
perfect example when "better" is the enemy of "good".</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Feb 3, 2019 at 12:34
PM Nate Wessel <<a href="mailto:bike756@gmail.com" target="_blank">bike756@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Hi all,</p>
<p>I had a chance this morning to work on cleaning up some
of the already-imported data in Toronto. I wanted to be a
little methodical about this, so I picked a single typical
block near where I live. All the building data on this
block came from the import and I did everything in one
changeset: <a class="gmail-m_-977679983682700784gmail-m_2570815994900691427gmail-m_-4280084153721892123moz-txt-link-freetext" href="https://www.openstreetmap.org/changeset/66881357" target="_blank">https://www.openstreetmap.org/changeset/66881357</a><br>
</p>
<p>What I found was that: <br>
</p>
<p>1) Every single building needed squaring</p>
<p>2) Most buildings needed at least some simplification. <br>
</p>
<p>3) 42 buildings were missing. <br>
</p>
<p>I knew going in that the first two would be an issue, but
what really surprised me was just how many sheds had not
been imported. There are only 53 houses on the block, but
42 sheds/garages/outbuildings, some of them quite large,
and none of which had been mapped. <br>
</p>
<p>I haven't seen the quality of the outbuildings in the
source data, and maybe I would change my mind if I did,
but I think if we're going to do this import properly,
we're going to have to bring in the other half of the
data. I had seen in the original import instructions that
small buildings were being excluded - was there a reason
for this?<br>
</p>
<p>I also want to say: given how long it took me to clean up
and properly remap this one block, I'll say again that the
size of the import tasks is way, way, way too large. There
is absolutely no way that someone could have carefully
looked at and verified this data as it was going in. I
just spent a half hour fixing up probably about
one-hundredth of a task square. <br>
</p>
<p>We can do better than this!<br>
</p>
<div class="gmail-m_-977679983682700784gmail-m_2570815994900691427gmail-m_-4280084153721892123moz-signature">--
<br>
Nate Wessel<br>
<span style="font-size:10px;color:rgb(119,119,119)">Jack
of all trades, Master of Geography, PhD candidate in
Urban Planning<br>
<a href="http://natewessel.com" target="_blank">NateWessel.com</a></span> <br>
<br>
</div>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail-m_-977679983682700784gmail-m_2570815994900691427gmail_signature">
<div dir="ltr">Best Regards,<br>
Yaro Shkvorets</div>
</div>
<br>
<fieldset class="gmail-m_-977679983682700784mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-977679983682700784moz-quote-pre">_______________________________________________
Talk-ca mailing list
<a class="gmail-m_-977679983682700784moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org" target="_blank">Talk-ca@openstreetmap.org</a>
<a class="gmail-m_-977679983682700784moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca" target="_blank">https://lists.openstreetmap.org/listinfo/talk-ca</a>
</pre>
</div>
<p><br>
</p>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote></div>