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 <bike...@gmail.com <mailto:bike...@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
    <ja...@piorkowski.ca <mailto:ja...@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.nutt...@hotmail.ca <mailto:kyle.nutt...@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 <james2...@gmail.com
        <mailto:james2...@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
        <alarob...@gmail.com <mailto:alarob...@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
        <ja...@piorkowski.ca <mailto:ja...@piorkowski.ca>> wrote:
        >
        > On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
        > <stevea...@softworkers.com
        <mailto:stevea...@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 <http://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@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
        > https://lists.openstreetmap.org/listinfo/talk-ca
        >
        > _______________________________________________
        > Talk-ca mailing list
        > Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
        > https://lists.openstreetmap.org/listinfo/talk-ca
        >
        >
        > _______________________________________________
        > Talk-ca mailing list
        > Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
        > https://lists.openstreetmap.org/listinfo/talk-ca

        _______________________________________________
        Talk-ca mailing list
        Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
        https://lists.openstreetmap.org/listinfo/talk-ca



-- Best Regards,
              Yaro Shkvorets

    _______________________________________________
    Talk-ca mailing list
    Talk-ca@openstreetmap.org  <mailto:Talk-ca@openstreetmap.org>
    https://lists.openstreetmap.org/listinfo/talk-ca
    _______________________________________________
    Talk-ca mailing list
    Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
    https://lists.openstreetmap.org/listinfo/talk-ca



--
Best Regards,
          Yaro Shkvorets
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Reply via email to