On Jan 29, 2018, at 12:15 PM, john whelan <jwhelan0...@gmail.com> wrote: > · NRCan is working on a methodology to extract building footprints, > including topographic elevation and height attributes, from LiDAR > Traditionally OSM has not been happy with this sort of thing. The accuracy > can be poor.
I find it troublesome that John should even have to explain this to a single person on this list. However, maybe some here don't know this, so "OK." Warning: lukewarm screed ahead. I say this with all politeness intended: OpenStreetMap is not a dumping grounds for data which are open (OD) nor experimental from AI/machine learning results, then there is some vague and hand-waving future process which may or may not come along in the future and "fix them to meet OSM's quality standards." OSM is delighted to receive building data in Canada, truly we are. (Provided they are high-quality data). I have heard the process of entering data into OSM, especially "bulk import" OD (which must match license compatibility against OSM's license, our ODbL) described as "inside baseball." It is not. Every single person reading this list is either an OSM volunteer like me, or has an interest in OSM. (Signing up for this mailing list is my evidence for saying that). That means fully treating OSM as the "host project" for these data, simply put, because it is. Acting as if OSM is simply an airplane expected to fly, without following a flight plan nor contacting a control tower will get this project grounded, as OSM volunteers like me declare an emergency, seeing nobody in the pilot's seat, while all the passengers expect a free ride to their own distinct destinations. That simply "doesn't fly." Recently, many of us have become more aware of the history of StatsCan wanting to introduce building data to crowdsourcing and coming up with BC2020i (the i for "initiative"). Left quite unspoken was that "crowdsourcing building data from StatsCan" silently became "put building data into OSM." While there was traction to do this in 2016, many meetings, a fair amount of data entry and the beginnings of more established OSM-style process (writing a wiki or two, efforts to harmonize local OD licenses with ODbL...) in 2017, this "initiative" has now fully morphed into an OSM WikiProject, BC2020. This has its own wiki (https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020 being re-written now) and is getting on a better footing by discussing the huge number of moving parts both there and here in talk-ca. But, in my opinion, the project remains badly unfocused (slowly, it gets better). Building data in Canada entering OSM, whether by "manual" methods (e.g. tracing a Bing layer) or by "bulk import" from licenced OD is ongoing. However, it absolutely must hew to the tenets of OSM: good, wide-area coordination and communication, consensus, following the guidelines written into an Import Plan (if bulk importation of OD data happens) and keeping others informed of status (licence approvals, how far along manual methods are via the Task Manager...). This is NOT "inside baseball." It is OSM, plain and simple, through and through — this is because BC2020 is an OSM project. In my opinion (and if it isn't clear by now), this project suffers from a serious lack of Project Management. I do not wish to chide, rather to encourage. As OSM is "hosting" BC2020, I'd like to see more "cultural sensitivity" towards what OSM absolutely MUST DO on national-level projects: • we document our intentions with a well-written wiki (due to history, what we have was poorly done, though it is improving), • we publish Import Plans PER IMPORT (whether municipality, province or whatever), Ottawa's was good, others must grow from this, • we inform wider community (Canadian and worldwide OSM) with status, including licence and data entry progress, whether via Task Manager or otherwise, • especially in early stages (and we are here now), we guide and steer the project towards achievable goals and realistic timeframes, doing so applying knowledge gained from previous (especially national-level or very wide scope) OSM projects. This is not an exhaustive list. Please, for months I've been cajoling, back-channel-communicating, wiki-improving and friend-making my way (OUR way) towards a simple understanding (and declaration?) by all involved in BC2020 that it is an OSM project, that it must hew closely to OSM tenets and that that is not "inside baseball." OSM is simply the methods by which these Canadian building data find a home. I'd like to see "local stovepipes" of sub-project data entry efforts and no- or little-communication turn into talk-ca threads and new wiki sections in our wiki, so this project becomes much more transparent and wide-area. I'd especially like to see someone or some group (call it a "steering committee") step into the role of Project Manager(s), offering sorely-needed guidance, planning and direction to this project, WHILE MAKING IT MUCH MORE OSM. I don't like to shout with capital letters, my passion should be clear by now. If you are looking for BC2020i (WikiProject BC2020, whether that is widely seen or not) to provide the greater Canadian community with rich benefits, and I believe many reading this expect EXACTLY that, please step up and offer this project some needed care and guidance in its early days of takeoff. It is not an airplane which flies without a pilot. The project suffers from a serious lack of focus, planning and transparency, poor communication and widely scattered efforts which (on national-scope OSM projects) usually lead to poor results. WikiProject BC2020 needs the most rudimentary structure of project management, badly, and right now. Previous experience with national-level/wide scope projects in OSM is quite helpful, but only died-in-the-wool OSM volunteers need "apply" (themselves). Sincerely, SteveA OSM Volunteer since 2009 _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
