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 list [email protected] https://lists.openstreetmap.org/listinfo/talk-ca
