<div dir="auto">That is incorrect, some building parts could be bigger if they are surrounding the building as an overhang etc. You can't assume building will be bigger</div><br><div class="gmail_quote"><div dir="ltr">On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel <<a href="mailto:bike756@gmail.com">bike756@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Is it sufficient to tag fragments as building:part without
indicating which part or how many stories? If the data is properly
structured, this seems like something that could be handled in
preprocessing by checking for overlapping polygons. It looks like
perhaps we might just have to find the largest part for the
footprint (building=yes) and any intersecting smaller buildings
(building:part=yes).</p>
<p> We might also need to generate some building relations for more
complex features.<br>
</p>
<div class="m_-6862194445823564595moz-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" target="_blank" rel="noreferrer">NateWessel.com</a></span>
<br>
<br>
</div>
<div class="m_-6862194445823564595moz-cite-prefix">On 1/24/19 11:40 AM, Yaro Shkvorets
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>OSM wiki: <a href="https://wiki.openstreetmap.org/wiki/Key:building:part" target="_blank" rel="noreferrer">https://wiki.openstreetmap.org/wiki/Key:building:part</a></div>
<div>It's not in the import wiki though since whoever wrote
it didn't know about it at the time.</div>
<div>Here's what I mean by mapping 3D features in our case.
Say there is a residential tower on a podium. In the
StatsCan data usually you would find both of these
outlines - large podium outline and smaller tower outline
inside it. They would both be tagged with "building=yes"
tag. Obviously we can't upload that as-is. We can either
just remove tower outline leaving only 2D podium outline.
Or, we can tag the tower outline with "building:part=yes".
Someone local can add other tags to it later on, such as
"building:levels", "building:material",
"building:min_level", "addr:housenumber" (if there are two
towers on one podium with different house numbers for
example), etc. I find the latter approach to be the right
one.</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="m_-6862194445823564595gmail_attr">On Thu, Jan 24, 2019 at 11:15
AM Nate Wessel <<a href="mailto:bike756@gmail.com" target="_blank" rel="noreferrer">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 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="m_-6862194445823564595gmail-m_277083992809862550moz-signature">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" rel="noreferrer">NateWessel.com</a></span> <br>
<br>
</div>
<div class="m_-6862194445823564595gmail-m_277083992809862550moz-cite-prefix">On
1/18/19 2:48 PM, Yaro Shkvorets wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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 noreferrer" target="_blank">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" rel="noreferrer">Talk-ca@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer noreferrer" target="_blank">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" rel="noreferrer">Talk-ca@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer noreferrer" target="_blank">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" rel="noreferrer">Talk-ca@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer noreferrer" target="_blank">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" rel="noreferrer">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer 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="m_-6862194445823564595gmail-m_277083992809862550gmail_signature">
<div dir="ltr">Best Regards,<br>
Yaro Shkvorets</div>
</div>
<br>
<fieldset class="m_-6862194445823564595gmail-m_277083992809862550mimeAttachmentHeader"></fieldset>
<pre class="m_-6862194445823564595gmail-m_277083992809862550moz-quote-pre">_______________________________________________
Talk-ca mailing list
<a class="m_-6862194445823564595gmail-m_277083992809862550moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org" target="_blank" rel="noreferrer">Talk-ca@openstreetmap.org</a>
<a class="m_-6862194445823564595gmail-m_277083992809862550moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca" target="_blank" rel="noreferrer">https://lists.openstreetmap.org/listinfo/talk-ca</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank" rel="noreferrer">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer 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="m_-6862194445823564595gmail_signature">
<div dir="ltr">Best Regards,<br>
Yaro Shkvorets</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank" rel="noreferrer">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote></div>