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

Thu Jan 24 17:01:14 UTC 2019

>>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).
Yes, that's what I usually do. I also sometimes delete non-important
building parts that don't add anything valuable to the map but only
complicate things. Not sure how to better explain that in the wiki, it's a
personal judgement thing I guess.

On Thu, Jan 24, 2019 at 11:49 AM 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
>
>

-- 
Best Regards,
          Yaro Shkvorets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20190124/e233d045/attachment-0001.html>