As a point of information the 2020 web page I think was started by Julia and very heavily edited by Stevea. I think we are now agreed that the 2020 project with its idea of mapping buildings in iD is not optimal. However Julia's style did make its mark with many students and educators and caught their imagination.
The import plan is not the 2020 web page, it is something different. The 2020 web page has a pointer to it and it is the import plan or the import we are talking about here. The decision was taken by the small group who are putting this lot together, to keep the 2020 as part of the name in order to link the two together. A large part of the 2020 project was enriching the building outline data and that I think was and still is important. What would be interesting is to hear from Canadian mappers what their current thoughts are. The earlier talk-ca comments are still in talk-ca but remember some time has passed since they were made. Certainly Nate for one was not around in talk-ca when the matter was discussed. Cheerio John On Sat, 19 Jan 2019 at 15:40, OSM Volunteer stevea < stevea...@softworkers.com> wrote: > On Jan 19, 2019, at 10:48 AM, john whelan <jwhelan0...@gmail.com> 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 Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
