<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Yaro, <br>
</p>
<p>I just had a chance to look at the documentation on the source
data and I wasn't able to find anything about 3D features or parts
of buildings being mapped separately. Are you guessing here, or is
there documentation on this? If so can you point us to it?<br>
</p>
<p>In any case, the big shapefiles from StatsCan don't provide
enough information to reconstruct any 3D geometries, so I'd be
inclined to remove these from the import unless they can be
brought in from another source with better documentation /
attribute tagging. (i.e. City of Toronto?)<br>
</p>
<p>Thanks,<br>
</p>
<div class="moz-signature">Nate Wessel<br>
<span style="font-size:10px;color:#777">Jack of all trades, Master
of Geography, PhD candidate in Urban Planning<br>
<a href="http://natewessel.com">NateWessel.com</a></span>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 1/18/19 2:48 PM, Yaro Shkvorets
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGCEwguf1FOXfcS4X6ZRxVo4fKN3Ka-D3dydC4zRYQ8q5Ye7NQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Jarek,
<div>There is no question we want this data. I went through
much of it in Toronto and Kingston and I found it to be very
good, consistent and precise. Time-wise it's somewhat
current with 2016 ESRI imagery (sometimes ahead, sometimes
slightly behind) and is well-aligned with it. It offers 3D
features (when several buildings appear overlapped in the
dataset) but you just need to be familiar with
`building:part` tag to sort through it. I haven't looked at
other provinces but in Ontario I really have no complaints
about dataset quality whatsoever. Also I don't get Nate's
"wildly unsimplified geometries" comment. IMO geometries are
just perfectly detailed.</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski
<<a href="mailto:jarek@piorkowski.ca"
moz-do-not-send="true">jarek@piorkowski.ca</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">Some
more thoughts from me.<br>
<br>
Building outlines, particularly for single-family subdivisions
as seen<br>
in Canadian suburbs, are extremely labour-intensive to map
manually.<br>
<br>
My parents' house is now on OSM - accurately. They live in a
city with<br>
about 10,000 buildings, and about 0.5 active mappers. This
wouldn't<br>
been completed manually in the next 5 years.<br>
<br>
An option to do this automatically with a computer algorithm
detecting<br>
objects from imagery could be suggested, but this has not been
very<br>
accurate in OSM in the past, even when there is decent
imagery. The<br>
only other feasible data source is government, where they have
such<br>
data more or less.<br>
<br>
The alternative is of course the opinion that we should not
have<br>
building outlines until someone goes through and adds the
buildings<br>
manually. In practice what I've seen done in Toronto is that
bigger<br>
buildings are mapped on best-effort basis from survey and
imagery,<br>
while areas of single-family houses are left blank. This isn't<br>
_wrong_, and maybe some prefer this.<br>
<br>
I would also like to note that building outlines will _never_
be<br>
completely verifiably up to date. I can't go into most
people's<br>
backyards and verify that there isn't a new addition on their
house. A<br>
building might be legally split into two different properties
without<br>
it being evident from the street. Imagery is out of date the
day after<br>
it's taken, and proper offset can be difficult to establish in
big<br>
cities where GPS signal is erratic. Pragmatically, I can tell
you from<br>
personal experience that building data in lovingly-mapped
Berlin is<br>
also worse than 1 meter accuracy. So again: best effort.<br>
<br>
What do we get from having buildings? A sense of land use
(arguably<br>
replaceable with larger landuse areas). A way to roughly
estimate<br>
population density. A way to gauge built-up density. A data
source for<br>
locating buildings in possible flood zones, or fire risk.
Statistics:<br>
as open data, queryable by APIs that are already used, in
format<br>
more-or-less common worldwide.<br>
<br>
Examples were given of rowhouse- or de-facto
rowhouse-buildings where<br>
a part is attached to the wrong building. This does not alter
any of<br>
the above examples. It's wrong, but is it substantially more
wrong<br>
than a blank subdivision, or one with only a few buildings
mapped? Is<br>
it better to have a null, or be off by 5%? The legal truth is
in<br>
property records, and we can't measure houses with a ruler, so
OSM can<br>
only be a statistical source. And then there's the question of<br>
verifiability - some of these buildings are connected to their<br>
neighbour building inside. I've really struggled at
distinguishing<br>
what exactly is a "building" on Old Toronto avenues even with<br>
street-side survey.<br>
<br>
Bluntly, OSM is not perfect in Canada. I have pet peeves I can
quote,<br>
and I'm sure many of you do as well. If we import, the
question is:<br>
are we making it better?<br>
<br>
1. Do we want this data?<br>
2. Is it generally of acceptable quality?<br>
3. Is there a mechanism to spot and reject where data is
particularly bad?<br>
<br>
Cheers,<br>
Jarek, who should really get back to updating built-last-year
stuff at Fort York<br>
<br>
On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall <<a
href="mailto:kyle.nuttall@hotmail.ca" target="_blank"
moz-do-not-send="true">kyle.nuttall@hotmail.ca</a>>
wrote:<br>
><br>
> The pilot project that took place in Ottawa for all these
building imports is what got me hooked into OSM in the first
place. I would make only very minor changes here and there. I
even attempted to draw building footprints but got burnt out
after only doing a single street, which was very discouraging
for me to continue.<br>
><br>
> When I saw the entire neighbourhood get flooded with new
buildings that weren't there before, I was entirely intrigued
and actually got on board with the locals to help with the
process. I've been hooked since and have been to many meetups
afterwards. Helping out with projects completely unrelated to
the initial building import.<br>
><br>
> I'm entirely of the belief that it is much more
encouraging for a new user to make a minor change (eg.
changing `building=yes` to `building=detached`) than it is to
add every single minor detail to each object from scratch
(visiting the location, drawing the building footprints
manually, adding address data, etc.). It's just overwhelming
for a new user.<br>
><br>
> It is very much a cat-and-mouse type scenario with
community driven projects like OSM. Apparently the issue with
this import is the lack of community involvement but I can for
sure tell you that this import will help flourish the
community in the local areas. Especially if they only need to
add or change minor tags than if they would have had to create
all of this data by hand. With an import this size there is
bound to be some errors that slip through. That's where the
community comes through to correct these minor things.<br>
><br>
> This is the whole point of OSM. A user creates an object
with as much information as they know and the next user comes
and adds onto that, and the next user adds and/or updates even
more. Neither of those users on their own could have added as
much detail as all of their knowledge combined.<br>
><br>
> Are we supposed to just wait for a user who can add every
single building with centimetre precision and every bit of
detail simply because we can't? No, of course not. We do the
best we can and have other users who know more than we do
build on that.<br>
><br>
> I fully endorse this import because I would love to see
what it does for the local communities that apparently need to
figure this import out for themselves.<br>
><br>
> Cheers,<br>
> Kyle<br>
><br>
> On Jan. 18, 2019 05:40, James <<a
href="mailto:james2432@gmail.com" target="_blank"
moz-do-not-send="true">james2432@gmail.com</a>> wrote:<br>
><br>
> As Frederik Ramm once said(sorry i'm paraphrasing from
memory please don't shoot me) There has never been a GO-Nogo
for imports, you bring it up on the mailing lists with
reasonable delay, is there no objections(in this case no one
was saying anything about it for 2-3 weeks) then email the
list that the import would start.<br>
><br>
> On Fri., Jan. 18, 2019, 12:59 a.m. Alan Richards <<a
href="mailto:alarobric@gmail.com" target="_blank"
moz-do-not-send="true">alarobric@gmail.com</a> wrote:<br>
><br>
> Along the lines of what Jarek said, sometimes silence
just means tacit acceptance, or that it's not that
controversial. There's quite a bit of government data here
that is supposedly "open" but unavailable for OSM, so I'm very
glad Stats Can was able to find a way to collect municipal
data and publish it under one national license. I was
surprised myself it hadn't got more attention, but I'm firmly
onboard with more imports if done with care.<br>
> Manually adding buildings - especially residential
neighborhoods, is about the most boring task I can think of,
yet it does add a lot to the map.<br>
><br>
> I'll admit I hadn't looked at the data quality myself,
but I just did review several task squares around BC and they
look pretty good. Houses were all in the right place,
accurate, and generally as much or even more detailed than I
typically see. Issues seemed to be mostly the larger
commercial buildings being overly large or missing detail, but
in general these are the buildings most likely to be already
mapped. To a large degree, it's up the individual importer to
do some quality control, review against existing object,
satellite, etc. If we have specific issues we can and should
address them, but if the data is largely good then I see no
need to abort or revert.<br>
><br>
> alarobric<br>
><br>
> On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski <<a
href="mailto:jarek@piorkowski.ca" target="_blank"
moz-do-not-send="true">jarek@piorkowski.ca</a>> wrote:<br>
><br>
> On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea<br>
> <<a href="mailto:steveaOSM@softworkers.com"
target="_blank" moz-do-not-send="true">steveaOSM@softworkers.com</a>>
wrote:<br>
> > Thanks, Jarek. Considering I am a proponent of
"perfection must not be the enemy of good" (regarding OSM data
entry), I think data which are "darn good, though not perfect"
DO deserve to enter into OSM. Sometimes "darn good" might be
85%, 95% "good," as then we'll get it to 99% and then 100%
over time. But if the focus on "how" isn't sharp enough to
get it to 85% (or so) during initial entry, go back and start
over to get that number up. 85% sounds arbitrary, I know, but
think of it as "a solid B" which might be "passes the class
for now" without failing. And it's good we develop a
"meanwhile strategy" to take it to 99% and then 100% in the
(near- or at most mid-term) future. This isn't outrageously
difficult, though it does take patience and coordination.
Open communication is a prerequisite.<br>
><br>
> Thank you for this commitment. I wish others shared it.
Unfortunately<br>
> the reality I've been seeing in OSM is that edits which
are 90+% good<br>
> (like this import) are challenged, while edits which are
50+% bad<br>
> (<a href="http://maps.me" rel="noreferrer"
target="_blank" moz-do-not-send="true">maps.me</a>
submissions, wheelmap/rosemary v0.4.4 going to completely<br>
> wrong locations for _years_) go unchallenged or are
laboriously<br>
> manually fixed afterward.<br>
><br>
> --Jarek<br>
><br>
> _______________________________________________<br>
> Talk-ca mailing list<br>
> <a href="mailto:Talk-ca@openstreetmap.org"
target="_blank" moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
> <a
href="https://lists.openstreetmap.org/listinfo/talk-ca"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
><br>
> _______________________________________________<br>
> Talk-ca mailing list<br>
> <a href="mailto:Talk-ca@openstreetmap.org"
target="_blank" moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
> <a
href="https://lists.openstreetmap.org/listinfo/talk-ca"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
><br>
><br>
> _______________________________________________<br>
> Talk-ca mailing list<br>
> <a href="mailto:Talk-ca@openstreetmap.org"
target="_blank" moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
> <a
href="https://lists.openstreetmap.org/listinfo/talk-ca"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
<br>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank"
moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">Best Regards,<br>
Yaro Shkvorets</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Talk-ca mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org">Talk-ca@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca">https://lists.openstreetmap.org/listinfo/talk-ca</a>
</pre>
</blockquote>
</body>
</html>