[Talk-ca] OSM Canada building import

Sat Jan 26 18:55:40 UTC 2019

Hi there to all,

Really interested in this thread as we are precisely a community in contact
with National Statistics Offices (NSOs) like Stat Can and we see a growing
interest in OSM's geodatabase.

I can tell the interest will remain in the coming years and we need to be
prepared. As NSOs are planning their censuses for 2020 (and onwards) like
in the case of Uganda: https://opendri.org/uganda-open-mapping-for-resilience/
, the geo open data concept will prevail.

Other insights, anyone?

Regards
[image: geocensos]
*Javier Carranza** Tresoldi** CEO*

*, GeoCensosLic. en EconomíaMSc. in Geoinformation Twente UniversityM.A. in
Economics Georgetown University at geocensos*Skype: javiercarranza

https://www.youtube.com/watch?v=B7TKVurhKoU
<https://www.youtube.com/watch?v=B7TKVurhKoU&authuser=1>
https://www.youtube.com/watch?v=9cfdYdQHZVY
https://www.youtube.com/watch?v=gJQzhM52Zp0 <https://youtube/HrGIA5Zzpc0>
https://www.youtube.com/watch?v=HrGIA5Zzpc0 <https://youtube/gJQzhM52Zp0>
Colombia  (57) 1 4595159
Mexico:(52) 1 55 35436613
Panama Mobile: (507) 688 - 04892
www.geocensos.com
*Lets map together a better world*
<https://sites.google.com/a/geocensos.com/mapps/> [image: Twitter]
<https://twitter.com/GeoCensos> [image: LinkedIn]
<http://co.linkedin.com/in/carranzatorres>

"La información aquí contenida es para uso exclusivo de la persona o
entidad de destino. Está estrictamente prohibida su utilización, copia,
descarga, distribución, modificación y/o reproducción total o parcial, sin
el permiso expreso del representante legal de Fundación Geocensos, pues su
contenido puede ser de carácter confidencial y/o contener material
privilegiado. Si usted recibió esta información por error, por favor
contacte en forma inmediata a quien la envió y borre este material de su
computador. La Fundación GeoCensos no es responsable por la información
contenida en esta comunicación, el directo responsable es quien la firma o
el autor de la misma."

On Sat, Jan 26, 2019 at 11:49 AM OSM Volunteer stevea <
steveaOSM at softworkers.com> wrote:

> 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 <jwhelan0112 at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20190126/a76959fd/attachment-0001.html>