[Talk-ca] Pourquoi les imports doivent être régis

Adam Martin s.adam.martin at gmail.com
Tue Jan 7 17:25:48 UTC 2014


Darren,

I'd also like to hear what the consensus is on this point. Generally, a GPS
trace is optimal, but not always possible. Personally, I find that tracing
the satellite imagery tends to provide a good result. I've performed some
localized tests to ensure that these traced roads are comparable to GPS
data and the results have been positive.

More on the topic of whether to use the Canvec data or not - I live in
Paradise in Newfoundland (
http://www.openstreetmap.org/#map=13/47.5340/-52.8825) and have been
contributing to the map as a hobby. Other users imported the Canvec data
for the area which has provided a good stepping stone for my work. I've
adjusted the shape of the roads to align them to the surroundings and added
the land use designations in the area. The user(s) that imported the data
wisely chose to exclude the land designations and take only the network,
lakes, rivers and special features (names of bays or mounts). Buildings
were not imported nor any other fine detail like that.

In my opinion, it's worked well in that way. The importer seemed to know
what they were doing and picked the through the Canvec data carefully.
Looking in some other areas, I noticed errors in the Canvec data - even
with the simple "Wood" areas. The polygons are inaccurate and oddly shaped,
with sharp borders resulting from the use of the Canvec Tiles. Some areas
have road networks composed of dozens of isolated segments as was mentioned
- one of these I painstakingly corrected by deleting and redrawing the
roads in that area (Meadow Lake in Saskatchewan for those interested -
http://www.openstreetmap.org/#map=14/54.1255/-108.4490).

In all, use of importation for the data should be allowed, but controlled.
Those that do it need to be skilled at the process and mindful of the
errors in the data. Above all else, they should respect the work of the
other mappers in that area. I'd hate to have the work I've done so far to
be haphazardly erased because someone wanted to import (and then abandon) a
pile of data over those areas. Maybe we just need to be more involved in
the imports. This is a community so why not make such importation a
community decision. No lone guns as it were - if you want to import, you
pass it by the rest of us. No objections = go ahead. Do it without
mentioning it to the group and the change is considered unintentional
vandalism and erased.

Just a thought.

Adam


2014/1/7 Darren Wiebe <darren at aleph-com.net>

> I'd like the communities input.  I work in Lloydminster, AB (
> http://www.openstreetmap.org/#map=9/53.4594/-109.4980) and we're using
> OpenStreetMap in my job to provide mapping to our service trucks and
> provide customer locations, etc.  Over the last year and a half I've been
> working on expanding the OpenStreetMap coverage in my area.  Some of this
> has come from roads I've personally driven on but much of it in
> Saskatchewan has come from Canvec.  I'm picking away at keepright in the
> area as well.  I don't want to load a lot of junk into the map but the
> canvec roads are very close and with roads the map is of no use.
>
> Should I be importing just the roads or is there a better data source?  Or
> what other option am I missing?
>
> Darren Wiebe
>
>
>
> 2014/1/7 Pierre Béland <pierzenh at yahoo.fr>
>
>> OpenStreetMap est un projet collaboratif. Il y a un côté social qui peut
>> vraiment ajouter au plaisir de cartographier.  Par contre, si chacun
>> travaille de son côté sans coordination, si les nouveaux ne sont pas
>> minimalement encadrés, nous devons nous attendre à toutes sortes de
>> problèmes.
>>
>> Pour progresser et développer une meilleure carte, nous devons avoir
>> réussir à constituer une communauté davantage organisée, qui identifie les
>> problèmes de façon plus systématique, qui trouve des outils pour les
>> régler, qui assure un minimum de suivi des contributeurs.  Il faut avoir du
>> plaisir à travailler ensemble.  Regardez comment nous réussissons à
>> stimuler les contributeurs et réaliser des projets tels que pour le typhon
>> Haiyan aux Philippines.  Il serait intéressant de faire de même pour la
>> communauté du Québec, de se donner des objectifs et travailler tous
>> ensemble à les réaliser.
>>
>> La communauté OSM-france a développé des procédures pour l'import de
>> données et fait un suivi beaucoup plus systématique que nous. Ils ont aussi
>> développé l'outil Osmose pour la validation / correction des erreurs. Nous
>> avons obtenu que le Québec soit couvert par cet outil. Il faudrait
>> davantage s'en servir. Les polygones en double y sont notamment couverts.
>>
>> L'exemple suivant montre un polygone de lac importé en 2009 à partir de
>> Canvec. Le même contributeur a créé un doublon en 2011. Dans ce cas-ci ce
>> n'est pas l'import canvec qui est à blamer et c'est le même contributeur
>> réussit à créer un tel doublon et sans y ajouter d'attributs.
>> voir
>> http://osmose.openstreetmap.fr/fr/map/?zoom=16&lat=46.65962&lon=-76.09482&layers=B000000FFFFFFFFFFFFFFFFFFT&item=xxxx&level=1,2,3
>>
>> L'outil Osmose permet également à un contributeur de voir la liste des
>> erreurs liées à des objets qu'il a édité.
>>
>> Comment pouvons-nous progresser, améliorer notre carte, avoir le plaisir
>> de travailler ensemble et de progresser ? Des idées là-dessus?
>>
>>
>> Pierre
>>
>>   ------------------------------
>>  *De :* dega <gadelap at gmail.com>
>> *À :* jfd553 at hotmail.com
>> *Cc :* talk-ca at openstreetmap.org
>> *Envoyé le :* Mardi 7 janvier 2014 9h47
>> *Objet :* [Talk-ca] Pourquoi les imports doivent être régis
>>
>> Le 7 janvier 2014 12:00:01 talk-ca-request at openstreetmap.org a écrit :
>> > Saying that data import is harmful to OpenStreetMap project and harmful
>> to
>> > its community sounds like sharing a belief.
>> > Please, provide us with concrete examples to make all of us understand
>> why -
>> > not only believe - that imports are harmful...
>>
>> Je n'ai aucun avis à propos des données de New-York mais j'ai de trés
>> mauvaises expériences avec les imports Canvec.
>>
>> À mon avis, les données Canvec sont, dans plusieurs cas:
>> - désuètes
>> - erronées
>> - imprécises
>> J'ai des exemples à fournir à propos de chacun de ces qualificatifs.
>>
>> J'ai aussi des problèmes avec les importateurs Canvec.
>> Le site OSM recommande qu'un importateur s'associe à un mappeur local. À
>> ma
>> connaissance, cela ne se fait pas. Dans plusieurs cas, des données
>> invalides
>> sont été importées qui écrasent des données valides qui avaient été créés
>> par
>> un contributeur enthousiaste.
>> Si les importateurs n'ont aucun respect pour les données des
>> contributeurs, il
>> sera très difficile d'augmenter la participation populaire à OSM.
>>
>> J'entend souvent: "les données Canvec sont erronées mais il y aura des
>> petits
>> singes pour les corriger". Je ne crois pas que ce soit une bonne
>> approche; les
>> contributeurs enthousiastes préfèrent créer des bonnes données plutôt que
>> de
>> corriger les laxismes des autres.
>>
>> Les importateurs utilisent ouvent la méthode du "tabula rasa" et
>> détruisent
>> ainsi des données ramassées avec beaucoup d'efforts. S'ils ne respectent
>> pas
>> les données des autres, les importateurs ne doivent pas s'attendre à être
>> respectés par  les contributeurs.
>>
>> S'ils n'ont pas tout effacé au préalable, les importateurs devraient
>> avoir la
>> responsabilité de faire le ménage. Ce n'est pas fait! Dans les
>> laurentides (et
>> probablement ailleurs), on trouve souvent 2 définitions du même lac qui
>> se
>> superposent. La question n'est pas de savoir laquelle de ces 2
>> définitions est
>> la bonne mais plutôt de mettre l'emphase sur le fait qu'une carte de
>> qualité
>> ne contient ce type de duplicata.
>>
>> Doit-on empêcher les importations Canvec. Non! Canvec contient trop de
>> données
>> uniques et, par conséquent, précieuses. Le problème est plutôt du côté
>> des
>> importateurs qui favorisent le volume des données au détriment de la
>> qualité.
>>
>> Je n'ai pas de problème avec les données de forêt (relations "wood"), au
>> contraire. Mais je crois que l'importateur devrait fusionner les zones
>> contigues de façon à éliminer les contours de tuiles qui sont
>> particulières à
>> Canvec.
>>
>> Je vois pas l'intérêt d'importer les rues de Canvec. Elles sont anonymes
>> et
>> composées de petits segments ingérables. Personnellement, je ne vois pas
>> d'autres stratégie que de les effacer et de les recommencer. Qui plus
>> est, la
>> rue est probablement l'élément qui est le plus facilement apporté par le
>> contributeur enthousiaste. Pourquoi ne pas lui laisser le plaisir de
>> contribuer?.
>>
>> Je ne vois pas l'intérêt d'importer les bâtiments de Canvec. Ils sont de
>> mauvaise qualité. À première, ils laissent croire que la carte est bien
>> étoffée
>> mais les contributeurs expérimentés savent qu'il faut généralent les
>> effacer.
>>
>> Les données de lacs et rivières de Canvec sont imprécises (probablement
>> créées
>> à partir d'une imagerie satellite désuète). L'importateur ne se donne pas
>> la
>> peine de corriger l'offset et il arrive trés souvent que la route qui
>> devrait
>> ceinturer le lac traverse le lac. Lorsqu'on utilise des données de lac
>> qui
>> sont précises à +- 22m on peut s'attendre à des conflits avec les chemins
>> qui
>> sont précis à +- 6m. Cela laisse une impression désagréable.
>>
>> Pour conclure, je crois qu'il n'est pas trop tard pour qu'on définisse
>> quelles
>> sont les données de Canvec qui valent la peine d'être importées. Il
>> faudrait
>> aussi définir des cadres (limitatifs ou suggestifs) destinés aux
>> importateurs.
>>
>> dega
>> Contributeur depuis 2007
>>
>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>
> _______________________________________________
> 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/20140107/1e115903/attachment.html>


More information about the Talk-ca mailing list