Dega,
J'a interrogé la base OSM depuis 2013. Je ne vois pas de contributeurs locaux.
C'est un exemple où les données existent grâce aux contributeurs d'autres
régions et grâce aux imports Canvec. L'imagerie Bing n'est pas suffisamment
détaillée à cet endroit. Le mieux est de corriger le contour du lac au meilleur
de ta connnaissance et de raccorder le cours d'eau au lac.
Pour ce qui est de la route, il faut évidemment appliquer le même attribut tout
le long. Cela soulève un problème plus général, comment avoir une cohérence
générale sur un réseau. J'ai l'impression que l'on utilise trop d'attribut
tertiary. Il y aurait du travail à faire sûrement de ce côté. D'abord
s'entendre sur la classification, puis trouver des moyens de réaliser le
travail.
Pierre
________________________________
De : dega <[email protected]>
À : Pierre Béland <[email protected]>
Cc : "[email protected]" <[email protected]>; "[email protected]"
<[email protected]>
Envoyé le : Mercredi 8 janvier 2014 11h30
Objet : 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.24885
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,
effectivement Osmose est très utile. Par contre, pour certaines erreurs
mentionnés, il faut se demander s'il faut intervenir ou non. Je trouve aussi
discutable d'identifier comme erreur l'intersection d'un chemin et d'un cours
d'eau lorsqu'il n'es pas explicitement indiqué que la portion du cours d'eau
passe sous la route. En effet, par défaut on peut s'attendre que c'est le cas.
Il y a aussi beaucoup d'erreurs parce que il n'y pas systématiquement une ligne
au centre des rivières. Elle devrait aussi traverser les lacs. Cela a pour
objectif de constituer le bassin versant, de voir les différentes branches qui
se connectent à une rivière.
Pour ce qui est des abbréviations, on considère que l'on devrait toujours
écrire au long. Et l'algorithme d'Osmose indique donc comme erreur possible
toutes les abbréviations. Mais évidemment si c'est une abbréviation sur le
panneau.
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). 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 :
> 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.
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 suis abonné à talk-ca par l'intermédiaire des Digest. Or Mailman ne
traite pas correctement les accents dans Les Digest. Cela rend la lecture des
Digest très fastidieuse et ambiguë.
Les courriels et les archives sont OK. Seuls les Digest sont impliqués par ce
problème.
Est-ce que quelqu'un pourrait s'occuper de mettre à jour Mailman?
_______________________________________________
Talk-ca mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-ca
