Re: [Talk-ca] Pourquoi les imports doivent être régis
Voici un autre type d'erreur due aux importations Canvec: http://www.openstreetmap.org/#map=17/46.25047/-73.24885 Cette aberration aurait dû être corrigée par l'importateur. Pour bien comprendre la cause du problème, il faut aller en édition: http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.2488 5 On comprend alors que le lac a été coupé en 3 par les frontières de tuiles CanVec. Osmose ne peut pas détecter ce problème car il s'agit de 3 entités distinctes. Dans cette image, on peut aussi voir que les 2 segments de la Montée Ouest ne sont pas du même type. Un des segments provient de CanVec6 et l'autre de CanVec7. Il est probable que seul un contributeur local peut corriger ce problème mais si ce contributeur existe, il préférera probablement tout effacer et recréer la Montée Ouest avec ses propres données GPS. dega Le 8 janvier 2014 00:49:46 Pierre Béland a écrit : Bonjour Dega, Ce qu'il est possible de faire, c'est de repérer le type d'erreur dans la liste à gauche. On peut soit décocher un type d'erreur pour ne pas voir par exemple les croisements routes et cours d'eau, ou au contraire tout décocher et ne cocher qu'un seul type d'erreur. Dans ce cas, si l'on veut travailler uniquement sur les polygones où il y a doublon, on pourra travailler beaucoup plus rapidement, puisque l'on ne travaillera que sur un type d'erreur (sélectionner dans la première section Structurel, multipolygone[1]). J'ai essayé aujourd'hui et je pouvais rapidement repérer les différents polygones avec doublon. Et j'ai constaté que c'est souvent la même personne qui commet ces erreurs. Cela arrive probablement lors du traitement individuel des objets, lorsqu'on les fusionne à un autre calque. On ne le voit pas lorsqu'il y a superposition de deux polygones. Ce qui est curieux, c'est que le deuxième polygone n'a aucun attribut. Une bonne solution serait de développer un style Mapcss pour JOSM qui identifierait diverses erreurs dont les polygones en double. Lorsqu'un type d'erreur assez identifiable se répète, il peut être avantageux de traiter autrement que via Osmose. On peut par exemple extraire les données à l'aide de l'excellent service http://overpass-turbo.eu/ et ensuite amener les données dans JOSM pour traitement. J'ai fait cela pour tous les chemins où il y avait deux espaces blancs. J'ai pu faire une requête où je sélectionnais tous les chemins ayant ces deux espaces dans le nom. De même, si l'on trouve des attributs oneway=no. un attribut que l'on ne devrait pas trouver. Pour ce qui est du traitement de certains éléments tels 1ère, ce que tu peux faire c'est d'essayer d'en discuter sur le irc osm-fr /irc/:///irc/.oftc.net#/osm/-/fr/. Évidemment, il faut discuter le matin ou l'après-midi, puisqu'en soirée il est très tard chez eux. Sinon discuter sur la liste de discussion talk-fr https://lists.openstreetmap.org/pipermail/talk-fr. S'ils sont réticents à faire des exceptions parce que trop lourd à maintenir, il nous faudrait recopier le tout et gérer des bases de données, des serveurs, des scripts d'extraction. */Pierre /* Le 7 janvier 2014 15:34:00 Pierre Béland a écrit : davantage s'en servir. Les polygones en double y sont notamment couverts. Bonjour Pierre Merci! Je ne connaissais pas Osmose. Merci d'être intervenu auprès d'OSM-France pour l'inclusion du Québec. J'ai regardé le rapport d'erreurs dans la région des Laurentides. Il y a un nombre élevé d'erreurs. La plus courante de ces erreurs concerne l'intersection d'un chemin et d'un cours d'eau (fanion jaune). J'y vois 3 causes possibles: - il manque un pont (dans OSM) - le lac est décalé par rapport à la réalité et, par conséquent, le chemin de ceinture passe au dessus du lac. C'est un problème courant avec les données Canvec. - dans certains cas, il y a aussi en node partagé entre le cours d'eau et le chemin. C'est une erreur discutable. - Par contre, je ne considère pas que c'est une erreur lorsque le chemin passe au dessus d'un ruisseau. Il n'y a alors qu'une canalisation de béton ou de pierre. Je ne crois pas qu'on doive les identifier comme des ponts. Qu'en pensez-vous? D'autres cas ont attiré mon attention. Ce sont des fanions rouges. - Plusieurs d'entre eux concerne mon utilisation de l'abbréviation Imp. (pour Impasse). Osmose reporte une erreur. Pourtant, c'est bien l'abréviation utilisée par la municipalité de Lac-Supérieur. Est-ce eux qui sont erronés? Si non, est-ce qu'on ne devrait pas aviser OSM-France que le Québec utilise Imp. comme dénomination acceptée pour Impasse? Le même problème se pose avec l'abréviation de Première. Osmose refuse 1ère et recommande 1re. De très nombreuses municipalités du Québec utilisent 1ère. Nous serions très mals vus si on tentait de les convaincre de remplacer leur panneaux. Ne devrait-on pas en glisser mot à OSM-France? Je continuerai à utiliser Osmose. C'est un outil très utile. dega PS: je
[Talk-ca] Pourquoi les imports doivent être régis
Le 7 janvier 2014 12:00:01 talk-ca-requ...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Pourquoi les imports doivent être régis
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=16lat=46.65962lon=-76.09482layers=B00FFTitem=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 gade...@gmail.com À : jfd...@hotmail.com Cc : talk-ca@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-requ...@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
Re: [Talk-ca] Pourquoi les imports doivent être régis
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 pierz...@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=16lat=46.65962lon=-76.09482layers=B00FFTitem=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 gade...@gmail.com *À :* jfd...@hotmail.com *Cc :* talk-ca@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-requ...@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
Re: [Talk-ca] Pourquoi les imports doivent être régis
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 gade...@gmail.com *À :* jfd...@hotmail.com *Cc :* talk-ca@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-requ...@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@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 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Pourquoi les imports doivent être régis
On 14-01-07 12:25 PM, Adam Martin wrote: 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 was going to write my own bit, but Adam said what I was going to say, except more clearly than I could. … Do it without mentioning it to the group and the change is considered unintentional vandalism and erased. … though maybe I wouldn't go that far. I'd rather have an unaudited import than blank map. I'd rather have careful local mapping than an import. But given the size and population density* of Canada, that can't happen everywhere. cheers, Stewart *: or lack of it. Taken as a whole, Canada's essentially unpopulated, except for a few awkward edge cases ☺ ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
