Effectivement, on en revient aux discussions d'il y a quelques mois. Nous avons
indiqué dès le départ que ce projet était très ambitieux et qu'il y avait des
risques importants sur la qualité de la données si on s'appuyait principalement
sur des groupes inexpérimentés via les universités, etc.
John mentionnait la réponse pour le Népal. Nous venions de terminer la réponse
pour l'Ébola après près d'un an de cartographie intensive. Nous avions
plusieurs défis à surmonter avec l'absence d'imagerie récente, des communautés
isolées en montagne, des communications interrompues. A cela s'est ajoutée la
vague déferlante des carto-parties. Les médias avaient beaucoup parlé de la
réponse humanitaire OSM aux diverses crises humanitaires. Beaucoup de groupes
étaient intéressés à collaborer. Encore plus que pour Tacloban aux Philippines
et pour l'Ebola. Les statistiques montraient des records de participation de
nouveaux contributeurs. En contrepartie, John et d'autres qui validaient les
données, rapportaient continuellement des problèmes de qualité de la donnée.
Nous avons vécu le même problème avec Haiti en octobre 2016.
Il faut une part de réalisme. Pour bien coordonner, il ne suffit pas de créer
une tâche et d'inviter à participer. Nous ne sommes pas une communauté
structurée au niveau national. Je comprends que diverses universités
s'intéressent au projet OSM et aimeraient initier leurs étudiants à ce projet.
La meilleure solution je pense c'est de se mettre en contact avec la communauté
OSM locale et s'assurer de bien encadrer la formation et les premiers jours de
participation à OSM.
Les contributeurs sont davantage actifs dans leurs communautés locales ou selon
leur divers intérêts liés à leur travail ou loisir. Personne n'est prêt à
s'engager à coordonner un tel projet au niveau national.
Des personnes comme John et moi avons consacré beaucoup de temps à coordonner,
supporter les réponses humanitaires OSM au niveau international. Nos propos
prudents visent à en venir à une approche réaliste. Il vaut mieux partir sur
des bases solides, initier quelques projets au départ si des communautés sont
prêtes à les supporter.
Pierre
Le lundi 29 janvier 2018 18:57:14 HNE, john whelan <jwhelan0...@gmail.com>
a écrit :
The idea behind the building project is good. Basically you need a mixture
of accurate building outlines and tags. From there the statisticians can work
their magic. This is true in Canada as well as other parts of the world. With
OSM buildings and tags combined with open source stats software R (R.org) you
get ground floor GIS planning tools and they are badly needed in Africa etc.
If we can pull it off this is good.
First Pierre's point that machine learning and imagery is a little different to
using radar type technology. If we would have had it available in Nepal it
would have saved a lot of problems. Even today in Africa the standard of
building mapping would be much improved by the use of such technology.
It isn't yet accepted by OSM as mainstream. That is an issue we need to get
round before we can use the stuff.
However Canada has always been in the forefront of imports. We have a history
of using NCR Canada’s data ie CANVEC and we are comfortable using it. Some
parts we recognise are better quality than others. We also have within the
mailing list some deep technical expertise which can be used to evaluate the
radar type technology for detecting building outlines. I think it will take
time to get this technology accepted by OSM and that is the point of this
thread.
I think we have to accept that the BC2020i project is one that was not dreamt
up by the OSM community. I think the idea came out of Alessandro of Stats
Canada and my understanding is the web page was put together by a single person
with little experience of OSM, the processes and politics involved. There is
demand for the data but OSM is more geared towards mappers than customer
demands.
What we have ended up with is a project with lots of words and aspirations but
little apparent understanding of what is involved. The idea has been picked up
by High Schools and Universities and we are now getting inexperienced mappers
in with little training adding buildings to the map in iD and the data quality
is poor for some and that is an issue since it reflects on the project itself.
There seems to be no project manager and that is an issue. We’ve cleaned up
the wiki page to some extent. There is a demand from schools and Universities
to get involved. We need someone to put together guidance for these people.
I take Pierre’s point that in an ideal world experienced local mappers would
map locally and take responsibility for their area importing when appropriate.
Unfortunately we do not live in an ideal world.
Cheerio John
On 29 January 2018 at 17:59, OSM Volunteer stevea <stevea...@softworkers.com>
wrote:
On Jan 29, 2018, at 2:35 PM, Stewart C. Russell <scr...@gmail.com> wrote:
> On 2018-01-29 04:37 PM, OSM Volunteer stevea wrote:
>>
>> 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.
>
> If you're gonna quote me, at least try to understand me, please.
Stewart, I apologize if I misquoted you or took it out of context, that was not
my intention.
> The open data / OSM dialogue in Canada has been going something like
> this, ever since I started working with municipal groups in 2011 or so:
>
> Municipal data advocate: Please use our data! It's under an open
> licence!
>
> OSM volunteer: But our licences aren't compatible!
>
> Municipal data advocate: But it's an open licence! Our lawyers say
> you'll be fine!
>
> OSM volunteer: But we need … (starts to reel off list of additional
> supporting docs)
>
> Municipal data advocate: Companies like Google and Nokia use our data
> with no problem. Use our data! We are giving it to you!
> Don't complain!
>
> OSM volunteer: but but the licence …
>
> (Municipal data advocate storms off in search of a someone more likely
> to give them corporate recognition.)
>
> Some very tenacious OSM people and some very adaptable government people
> have made things work in a few places in Canada.
I both salute these efforts and bow deeply in obeisance at the good work done
here by them. These are the important seeds of the future, the acorns from
which mighty oaks shall grow. Yes, it will take time, effort, coordination,
management and documentation.
Simply put, (and I don't wish to be rude), "municipal data advocates" cannot
assume that OSM is a "free ride," without some front-loaded effort at planning
and further project guidance along the way. We have our culture and methods in
OSM, and that's the way it is. I am hopeful, as inter-community cooperation is
something Canada has been and is quite good at doing for its entire history.
> Only when we have a way
> forward on data licensing, then BC2020 would be an OSM project.
I respectfully disagree. Yes, "ways forward on data licensing" is vitally
important, as it is a major obstacle. However, BC2020, and the way that it has
morphed into becoming by its very nature using OSM as a repository of data, IS
an OSM project. Therefore, it must hew to OSM tenets, like transparency, good
communication, wiki updates, and in a project of scope this wide, sane and
steady planning and project management.
You can say that license compatibility is "slow going" (and you'd be right) but
OSM is "up to" three cities (from one, Ottawa). Rome wasn't built in a day and
Canada's building data won't be entered into OSM in a day, either. HOWEVER, as
they are being entered now, some "manually," some (few) via OD licence, and
some as simple improvements ("Hey, I'm going to tag this a café because I'm a
local OSM user and I know it is one!"), these efforts MUST BE coordinated (or
managed, I keep saying, though I'm not particularly enamored of the word as it
seems non-OSM, yet on national-scope projects, something like "management"
really is required, even if it is "loose but effective coordination").
Building data being entered into OSM do not have to be part of BC2020i, what is
now WikiProject BC2020: if I simply tag a building polygon amenity=cafe, I
don't become part of a coordinated effort. However, to the extent they strive
to be part of the coordinated effort to enter nationwide building data,
following the guidelines in our wiki of what we mean by acceptable-quality
data, with acceptable tags, they really, really should. Such coordination
benefits everybody, and at minor "cost" (follow some nationwide guidelines,
stay communicative with your status...). Is that so difficult a point upon
which to agree?
Thank you for continuing good dialog,
SteveA
______________________________ _________________
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap. org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
