[Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[James]

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

On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel <bike756 at gmail.com wrote:

> 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).
>
> We might also need to generate some building relations for more complex
> features.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>
> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
> It's not in the import wiki though since whoever wrote it didn't know
> about it at the time.
> 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.
>
> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel <bike756 at gmail.com> wrote:
>
>> Hi Yaro,
>>
>> 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?
>>
>> 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?)
>>
>> Thanks,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com <http://natewessel.com>
>>
>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>
>> Jarek,
>> 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.
>>
>>
>> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski <jarek at piorkowski.ca>
>> wrote:
>>
>>> Some more thoughts from me.
>>>
>>> Building outlines, particularly for single-family subdivisions as seen
>>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>>
>>> My parents' house is now on OSM - accurately. They live in a city with
>>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>>> been completed manually in the next 5 years.
>>>
>>> An option to do this automatically with a computer algorithm detecting
>>> objects from imagery could be suggested, but this has not been very
>>> accurate in OSM in the past, even when there is decent imagery. The
>>> only other feasible data source is government, where they have such
>>> data more or less.
>>>
>>> The alternative is of course the opinion that we should not have
>>> building outlines until someone goes through and adds the buildings
>>> manually. In practice what I've seen done in Toronto is that bigger
>>> buildings are mapped on best-effort basis from survey and imagery,
>>> while areas of single-family houses are left blank. This isn't
>>> _wrong_, and maybe some prefer this.
>>>
>>> I would also like to note that building outlines will _never_ be
>>> completely verifiably up to date. I can't go into most people's
>>> backyards and verify that there isn't a new addition on their house. A
>>> building might be legally split into two different properties without
>>> it being evident from the street. Imagery is out of date the day after
>>> it's taken, and proper offset can be difficult to establish in big
>>> cities where GPS signal is erratic. Pragmatically, I can tell you from
>>> personal experience that building data in lovingly-mapped Berlin is
>>> also worse than 1 meter accuracy. So again: best effort.
>>>
>>> What do we get from having buildings? A sense of land use (arguably
>>> replaceable with larger landuse areas). A way to roughly estimate
>>> population density. A way to gauge built-up density. A data source for
>>> locating buildings in possible flood zones, or fire risk. Statistics:
>>> as open data, queryable by APIs that are already used, in format
>>> more-or-less common worldwide.
>>>
>>> Examples were given of rowhouse- or de-facto rowhouse-buildings where
>>> a part is attached to the wrong building. This does not alter any of
>>> the above examples. It's wrong, but is it substantially more wrong
>>> than a blank subdivision, or one with only a few buildings mapped? Is
>>> it better to have a null, or be off by 5%? The legal truth is in
>>> property records, and we can't measure houses with a ruler, so OSM can
>>> only be a statistical source. And then there's the question of
>>> verifiability - some of these buildings are connected to their
>>> neighbour building inside. I've really struggled at distinguishing
>>> what exactly is a "building" on Old Toronto avenues even with
>>> street-side survey.
>>>
>>> Bluntly, OSM is not perfect in Canada. I have pet peeves I can quote,
>>> and I'm sure many of you do as well. If we import, the question is:
>>> are we making it better?
>>>
>>> 1. Do we want this data?
>>> 2. Is it generally of acceptable quality?
>>> 3. Is there a mechanism to spot and reject where data is particularly
>>> bad?
>>>
>>> Cheers,
>>> Jarek, who should really get back to updating built-last-year stuff at
>>> Fort York
>>>
>>> On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall <kyle.nuttall at hotmail.ca>
>>> wrote:
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > Cheers,
>>> > Kyle
>>> >
>>> > On Jan. 18, 2019 05:40, James <james2432 at gmail.com> wrote:
>>> >
>>> > 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.
>>> >
>>> > On Fri., Jan. 18, 2019, 12:59 a.m. Alan Richards <alarobric at gmail.com
>>> wrote:
>>> >
>>> > 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.
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > alarobric
>>> >
>>> > On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski <jarek at piorkowski.ca>
>>> wrote:
>>> >
>>> > On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
>>> > <steveaOSM at softworkers.com> wrote:
>>> > > 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.
>>> >
>>> > Thank you for this commitment. I wish others shared it. Unfortunately
>>> > the reality I've been seeing in OSM is that edits which are 90+% good
>>> > (like this import) are challenged, while edits which are 50+% bad
>>> > (maps.me submissions, wheelmap/rosemary v0.4.4 going to completely
>>> > wrong locations for _years_) go unchallenged or are laboriously
>>> > manually fixed afterward.
>>> >
>>> > --Jarek
>>> >
>>> > _______________________________________________
>>> > Talk-ca mailing list
>>> > Talk-ca at openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-ca
>>> >
>>> > _______________________________________________
>>> > Talk-ca mailing list
>>> > Talk-ca at openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-ca
>>> >
>>> >
>>> > _______________________________________________
>>> > Talk-ca mailing list
>>> > Talk-ca at openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>> _______________________________________________
>>> Talk-ca mailing list
>>> Talk-ca at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>>
>> --
>> Best Regards,
>>           Yaro Shkvorets
>>
>> _______________________________________________
>> Talk-ca mailing listTalk-ca at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> --
> Best Regards,
>           Yaro Shkvorets
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20190124/6806daf0/attachment-0001.html>