I'm changing the Subject to delete "Stats Can" as this is an import into OSM, not a Stats Can import. True, they published the data, so "thanks for the data," but Stats Can isn't a part of this conversation, they merely published the data. I say it like this to emphasize that OSM is quite aware of a good analogy: the US Census Bureau, who published the TIGER data which was imported massive road and rail data into the USA (roughly, many agree), had nothing to do with the import, nothing to say about it and don't to this day: they merely published the data into the public domain (as the federal US government do all their/our data, except when it is "classified") and OSM chose to import the data. OSM wishes in retrospect we had done a better job of it, as we improve it to this day (and will for years/decades, likely) and OSM has learned from this. Please, Canada, see this import as the opportunity it truly is: do NOT be in a rush to import lower-quality, not fully community-vetted data, or you will be quite sorry at the mess you'll have to clean up later. Doing that would be much more work than the dialog we are having now to prevent this. It is worth it to have these dialogs and achieve the consensus that the data are as we wish them to be. Are they yet? It sounds like they are not (Nate's four points).
On Jan 26, 2019, at 7:49 AM, John Whelan <jwhelan0...@gmail.com> wrote: > Currently we seem to be at the point where some on the mailing list feel > there wasn't enough discussion on talk-ca before the import. MANY agree there wasn't enough discussion. But that was before. Rather than looking back (though there is nothing wrong from learning from missteps), we are in a "now" where that is changing. So, we continue to discuss. That's fine. That's actually excellent. > Quebec I think we should put on one side until the Quebec mappers feel more > comfortable. OK, so we await Québécois suggestions / improvements to the process to their satisfaction, their input that they are (widely amongst themselves) with "comfortable to where it has finally evolved" (but I haven't heard that yet), or both. Usually in that order, but certainly not "well, enough time has elapsed, yet we haven't heard much, so let's proceed anyway." That doesn't work, that won't work. > Nate I feel has been involved in a smaller import before and in that case > there was benefit by simplifying the outlines. In this case verifying > nothing gets screwed up adds to the cost. Nate has done a lot of things in OSM, including a very positively-recognized (award-winning?) Ohio bicycle map that included very wide coordination with other OSM volunteers, the academic world and local community. (It is absolutely delicious; take a look at it). Another example of what a single person in OSM who reaches out to the community with a vision and a plan can achieve — given planning, the time it really takes and wide consensus. > Buildings not absolutely square, yes but different GIS systems use different > accuracy so if the incoming data has a few more decimal places then rounding > will occur which can lead to minor inaccuracies. I feel the simplest is just > to leave them. Others seem to feel that these inaccuracies are too rough (data quality too poor) to enter OSM. And "different GIS systems" only matter in a historical context (as in, for example "these data came from QGIS" or "these data were run through GDAL and turned into a shapefile" or many other workflows). The only "GIS system" that matters is OSM. Each individual contributor who enters data into OSM is responsible for entering high-quality data, or risks having those data redacted by the community (though that means the process was broken to begin with) — that's simply how OSM works. Again, this is an OSM project: a data import, which follows rules and community standards judging its quality as much as the individual entering the data itself. If the data should and can be improved before they enter (especially with a "data-wide" application of some algorithm), like "this squares buildings and we want to do this" or "this turns a true rectangle into four nodes instead of eleven and we should do this to reduce the amount of data and simplify future edits" then we should. This isn't being "anti-import." It IS about "data which ARE imported must be high-quality," so let's discuss what we mean by that in the case of these data. That's what we're doing now. > Selecting everything and squaring is really a mechanical edit and you can get > some odd results which again would need to be carefully compared and adds to > the workload. Sometimes "mechanical edits" are OK, sometimes they are not. It seems John is saying "these are not." Whether this adds to the workload or not is moot, the workload will be what it takes for high-quality data to enter, and "what that means" is achieved by the discussions we have had, have now and what consensus emerges from that. It's part talk-ca, part Yaro and Danny (and others) thrusting some data forward, part one step backwards, part several steps forwards in the Import wiki, part community building, mostly discussion, agreement and therefore, consensus. > California Steve has put forward some proposals in the 2020 page of the wiki > which to me amount to minor variations on what we were doing. The intent > always was to involve local mappers but locating them is not always easy. "Locating them" seems to me (SteveA is my moniker here) a "lost in the weeds" way to put how OSM builds community, especially in the context of a nationwide import. Perhaps this explains the "not always easy" aspect. Usually (I speak from experience), a lot of planning, often wiki and data massaging takes place first, and while some "outreach" can be a flavor of "locating them," MOSTLY what happens is THEY find YOU. (Or the project/import/OSM). Sure, you can simply "go out and recruit" and maybe find some people willing to help. Or, you can be an attractive, well-planned project with desirable goals and helpful people, good documentation and project management that is so successful and virtually invisible that it makes things FUN, literally drawing people in who crave to be a part of it. The latter works. The former, not so much. > The 2020 project is about not only adding building outlines but also about > enriching the tags on them and that to me is more important. Great. Say so. In the wiki. Along with how. Then, you make it likely that YOUR important aspects might be addressed: you've done positive things / your best to assure that might happen, so maybe it even will! This is how crowdsourcing works. Embrace it. > I'm not hearing specific concerns which can be addressed and I'd like to hear > them. > > So question to Daniel Begin, Andrew Lester and Pierre what can we do to > improve the project? This seems an odd way to address things, but it does "go to the source of the concerns," so I'm listening. Asking them directly "what would fix the project to address your concerns?" is an approach with merit, yet another is to identify what their concerns are, understand them, and widely discuss potential solutions to them, eventually achieving consensus. SteveA <remainder redacted> _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
