On Jan 19, 2019, at 10:48 AM, john whelan <[email protected]> wrote: > There was an earlier discussion on talk-ca about how to handle this project.
There were MANY. Speaking for myself only, I urged a very cautious, go-slow approach, to edit the data into "improvement / harmony-with-OSM" as much as possible BEFORE they upload to be imported, (or document in the wiki HOW this was to happen), to use talk-ca, Tasking Manager and especially to develop and use a freshly-rewritten (and undergoing continuous improvement) wiki (this part was a/the major failing, imo) to communicate. But that is looking in the rear-view mirror, and I don't like to hear "told you so," let alone say it. > It is similar to CANVEC in the original data sources are municipal data > CANVEC uses a few other sources as well and it is released under exactly the > same license but by a different federal government department. CANVEC data are roundly criticized. And it doesn't matter where those data came from (CANVEC), nor where the present data come from (Stats Canada). They are now "in the wild" and from an OSM perspective (what matters here and now), their source is essentially meaningless, except for historical context. > There are 3,700 municipalities in Canada. How do you deal with that? With good planning, using the tenets of OSM (e.g. the Import process, gaining consensus, good communication and appropriate tools like wiki, Tasking Manager and JOSM plug-ins where they make sense). You DON'T try to short-circuit that by wholesale re-writing a re-write of the seed project wiki (now well-vetted, as if it were it were, and I tried, would have widely been seen as lacking), posting notice on talk-ca and waiting two weeks independent of their being very little feedback on so gigantic a process (a massive red flag). In short, this was a huge "failure of consensus." Look at the posts now which say "I woke up to a mess." That simply shouldn't happen. > A suggestion was made on talk-ca we have one import plan that way it would at > least be consistent and that's what we did. This import plan, coming from the BC2020 wiki, which as written by Julia left a LOT to be desired as to technical specifics. I characterized this as "cheerleading and buzzword-compliant," sorry Julia, but it was and hence was ineffective as a wiki for its intended purposes, which is to answer questions of those who need technical guidance in an endeavor to have their "how?" questions appropriately answered. That's what wikis do, they are good at it, OSM expects this, so when a wiki fails to deliver, the project experiences failures. That absolutely should not surprise. > Mentally I'd split the project into getting an import plan that met all the > requirements and the actual importing. Um, yeah. > To me the importing would be done by local mappers or mappers with a local > connection after a local discussion which is what happened in Kingston. For > locations that did not have such mappers then over time they could be tackled > at a distance. One comment I recall was this was more of a marathon and to be > honest we expected it to take place over a fair length of time. A lot of > buildings have gone in much faster than I expected. So, plan for that. Manage that. If it isn't happening, make it happen with outreach and OSM's usual tactics of "developing community." OSM has been doing this for over 15 years (and gets better at it), but it isn't "a hope and a prayer," it is continual engagement, effort (technical and social) and mid-course correction when necessary, all while keeping a hawkish eye on the finish line. > For the pilot project with Ottawa the local Ottawa mappers were heavily > involved. We learnt a fair bit on the way and that's why we basically cloned > the Ottawa import plan. We noticed a lot of additional tags being added to > the building=yes and that to be was a good thing in that it drew more people > into OSM. I'm much more interested in those additional tags than anything > else. Crowdsourced projects often yield unexpected positive results. This is what our project means when we say our data get used "in creative, productive, or unexpected ways." It happens (a lot), this is one of the best things about OSM. > As far as I am aware there is no list of local OSM communities in Canada and > to be honest many mappers simply map and do not gather once a month at OSM > meetings. So? We don't need no stinkin' meetings, though all are welcome at meetings. > I don't think we do an import plan every time we bring something across from > CANVEC. Shame on whoever does this, it is wrong (from OSM's perspective, and this is OSM). > Unfortunately there really is a demand for this sort of information. The > initial 2020 meeting that took place at Stats Canada during the HOT summit in > Ottawa had many people from government departments who were very interested > in the data and especially what I call enriched data, ie buildings with > addresses and other tags. Smaller school boards have expressed an interest > in routing school buses using this sort of data. There is an app for the > blind that guides you to the building but the building and address have to be > on the map. > > Should we care what end users are interested in? I think that is a separate > discussion. It both matters and doesn't matter. There is much right and nothing wrong with setting specific goals, yet there is also that "unexpected" factor that simply cannot be anticipated. And so, "not caring what end users are interested in" is a strong way of saying it, but it is allowed. And by "following the rules," we assure this (users BEING "interested" in our data) is more likely to happen rather than not. > There always has been a range of views within OpenStreetMap. I have > certainly been taken to task for changing a tag from traffic_lights to > traffic_signals. "I mapped it and I tagged it traffic_lights and it should > remain that way." Toronto was almost certainly going to be troublesome. I > recall someone saying once if you gather five book classifiers together they > will find six ways to classify a book. The Ottawa community is reasonably > small and many meet up from time to time. In a city such as Toronto my > expectation would be a much wider range of opinions. This makes it very > difficult to identify if something is approved or not. It also means that my > expectation that the importing mapper will use a bit of common sense and we > shouldn't need to spell out things like "replace geometry tool" other mappers > will have other expectations. I can't stop you from generalizing like this, nor on making hard-and-fast determinations of "approved or not." However, regarding the elusive quality of "quality," you know it when you see it and you know it when you DON'T see it. That sounds harder than it actually is, but quality isn't black-or-white, it is a spectrum. And, just as you can't predict those "unexpected" results, nor can you fully expect what you need to "spell out," so, in essence, in a gigantic, nationwide import, (where, almost by definition you will have mappers of ALL skill levels), the only solution is to "spell out" everything (or virtually everything, start with everything you know right now). It's tedious to do this "up front," but it's one of the few tried-and-true methods that will drive a project towards its goals (though, it's not guaranteed). > My understanding of importing or drawing a building outline from imagery is > it gets tagged building=yes and you can do no better from imagery. > Occasionally you might see a building in a residential area that has two > drives, I might just tag that semi. > > Then we throw in the 2020 project. Stats initial idea was to simply have > every building mapped in Canada with iD and mapathons were a wonderful idea. > Technically it is possible to accurately map a building from imagery with iD > I've seen it done. You may wish to talk to Pierre about data quality from > those mapathons. "Lack of politeness alert," talk-ca: I am tired of pointing out that "what Stats is interested in" matters very little here. This is OSM, the (ostensible) repository of all this beautiful data of Canada's. If Stats spent a fraction of time getting buy-in from OSM by respectfully following our processes while adhering to our tenets and realizing that it is we, the volunteers of OSM who own these data, well, the job might be done by now. Yet they "wish from on high" while what feels like seriously disrespecting how OSM accomplishes what we accomplish. I have tried to gently and politely correct this behavior (not often successfully) for going on two years. Maybe Stats needs to hire a Public Relations firm to better develop relationships with representatives from OSM — no, that's a terrible idea. So, really, the only result we are left with is "it doesn't matter what Stats wants: 'the data' are 'out in the wild,' now, and while Stats might have a historical context for publishing the data, it's all about how OSM will complete this." Roll up your sleeves, everybody, this still remains a gigantic task. Only, from now on, it WILL be done "the OSM way," because this isn't a Stats project, it is an OSM project. (I've been saying this since the first Canadian building data to have come from Stats were uploaded to our servers. Maybe now that will finally "stick.") > I had talked to Stats about getting the building outlines released under a > suitable license. It only took a year to persuade the City of Ottawa to > change their Open Data license to one that worked with OpenStreetMap. The work (and it was) to achieve a compatible license was substantial, but it did involve (imo) abusing OSM's Legal Working Group into submission when they had many other pressing matters and are one of the more under-resourced aspects of OSM. Many years of effort later, OSM DOES have legal compatibility with these data, but it wasn't pretty getting here. However, now that we're here, let's look forward, not in the rear-view mirror. > Stats came back some time later by releasing some building outline data under > the federal government Open Data license and that's where this bit started. > > The 2020 project has a lot of interest from GIS departments, High Schools are > thinking of how to get involved with their students. Adding tags is a lot > safer and less error prone than drawing buildings in iD. Education is one > area that Stats gets brownie points for so they like to promote it. You can give Stats brownie points all day long, I don't. I'll say "thanks for the data," (no brownie points, as the process was a mess) and let's get busy doing a bang-up OSM job of importing them well. We have a very long way to go. > Microsoft has been running the same algorithms on Canada as it has in the US. > We can expect their building outlines to be released shortly. This news flash is appreciated, yet to even begin to talk about them entering OSM, there would be the same discussion and work required for those data as any other import. The algorithms they use are not germane to this topic, thread or post. I'm not saying anybody should always-and-forever ignore this point, rather, "not relevant here." > Data quality, by the time its been converted from one format to another and > comes form a variety of systems some municipal data will be better than > others. The data I've looked at looks reasonable however my expectations and > your expectations maybe different. If it looks like a duck and quacks like one (high quality IS high quality; low quality IS low quality), it's a duck. Expectations have nothing to do with actual quality of the data, unless you are expecting high quality and get low quality, then it's "back they go for improvement." > You might like to add a step or two into the wiki. I've been trying to (and doing so) for going on two years. The goalposts keep moving. Stop importing (it looks like to some limited degree, at least in Ontario, you have). Update the wiki so it is a real wiki of a real import plan of a real project. It gets better, but we're not there yet. I'm exhausted trying and yet here I am typing with some spirit at dedication to seeing this project "resurrect" itself into something that I believe can (eventually) become a showcase of data in OSM for Canada. That might be generous on my part, but I'm an optimist. > We could do a table in the wiki with a list of communities that feel > comfortable with the import. That might be troublesome, two high school > students meet over coffee,"hey this is a great idea." they have osm > memberships and mark the community as having approved. Has the local > community approved or not? OK, make separate (provincial-level seems to make sense) wikis for this. It isn't necessarily about "community approval" it is about communicating "this is what we have now, this is what we have consensus-created into existence, this is the path along to our finish line..." and keeping the channels of discussion open while providing those who want to help specific steps in a good plan to get there. It isn't any harder than that. But it is at least that. > My feeling is there is a lot of support for the project, how do we tap into > that support and move forward? One step at a time: start small, building upon the many kernels of success enjoyed so far (lessons learned from Ottawa, what Yaro does in Ontario with aplomb...) and grow these "good seeds" into more and more volunteers replicating them, and hence their success. Grow these to the provincial level with good communication coordinating (wiki, Discussion pages within them, Task Manager, and talk-ca if necessary). Especially as the data are now "in the wild," the snowball is starting to roll downhill, gathering mass and speed. Course-correct when necessary and GROW this process as and how it is successful. Voila, a successful, nationwide massive import (project). It will be messy, it always is, but "deal with it" and you can get there. Good luck, Canada. Many believe in this and want to see it succeed (me included, despite what some might think is a sour or exasperated tone). SteveA California _______________________________________________ Talk-ca mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-ca
