On Tue, 7 Feb 2012 17:49:24 +0100, Pieren wrote:
2012/2/7 Christian Quest <cqu...@openstreetmap.fr>:

+1


-1 (comme d'hab)

+1 avec pieren

par contre, j'ai justement corrigé pas mal de truc de ce genre dont l'auteur etait le pieren_bot... ;)

j'essaye de faire en sorte qu'il n'y ai plus d'erreur validator/JOSM quand j'importe du bati.
Ou tout du moins que je ne rajoute pas d'erreurs.


Corriger le bâti ne nécessite pas tant de travail que ça.

ca depend des communes....
quand il y a +300 erreurs, c'est un peut decourageant.



Pensez à
tous les autres pays qui font ça à la mano en traçant sur l'imagerie
et vous comprendrez...
L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
si en plus, on ne corrige pas les erreurs géométriques, ça va être
encore pire pour notre (déjà mauvaise) réputation. Une critique que
j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres
polygones landuse (sans doute suite à une intervention manuelle, soit
dans l'import, soit dans la création du doublon) et qui perdure dans
la base pendant des années.
Je ne fais évidemment pas partie du camps des "anti-import" mais il
faut toujours exiger un minimum de qualité. Déclarer "un script s'en
chargera plus-tard", c'est prendre le risque que les erreurs ne soient
jamais corrigées (c'est un peu ce qu'on lit entre les lignes, "après
tout, ça n'est pas si grave"). Et à partir de quel pourcentage on
considère que le chevauchement est "grave", donc "une erreur" ou un
"doublon" ? Faudra-t-il aussi accepter ce genre de chevauchements pour
d'autres entités comme les landuse ou les boundaries ?
Certains regrettent d'avantage les imports sans voirie, ou sans
correction sur les voiries qui se croisent alors avec le bâti. Mais
c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
s'en chargeront plus-tard. Notre "discours" dans ce domaine doit
vraiment rester dans la recherche constante de l'amélioration des
données et non du statu quo (c'est aussi très important vis-à-vis des
nouveaux arrivants qui peuvent nous lire).

Pieren

_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Répondre à