Data is currently stored in OSM by mappers this way, regardless of the source. I don't think a height or which part is needed to use the building part tags. It provides the basis for later additions should a mapper be so inclined to add it.
------- Kevin Farrugia On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel <[email protected] 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected] >>> 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 <[email protected]> >>> wrote: >>> > >>> > On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea >>> > <[email protected]> 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 >>> > [email protected] >>> > https://lists.openstreetmap.org/listinfo/talk-ca >>> > >>> > _______________________________________________ >>> > Talk-ca mailing list >>> > [email protected] >>> > https://lists.openstreetmap.org/listinfo/talk-ca >>> > >>> > >>> > _______________________________________________ >>> > Talk-ca mailing list >>> > [email protected] >>> > https://lists.openstreetmap.org/listinfo/talk-ca >>> >>> _______________________________________________ >>> Talk-ca mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-ca >>> >> >> >> -- >> Best Regards, >> Yaro Shkvorets >> >> _______________________________________________ >> Talk-ca mailing >> [email protected]https://lists.openstreetmap.org/listinfo/talk-ca >> >> _______________________________________________ >> Talk-ca mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-ca >> > > > -- > Best Regards, > Yaro Shkvorets > > _______________________________________________ > Talk-ca mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-ca >
_______________________________________________ Talk-ca mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-ca
