Le 30 octobre 2013 12:05, Pieren <pier...@gmail.com> a écrit :
> 2013/10/29 Guillaume Allegre <allegre.guilla...@free.fr>:
>
> > Voici donc la suite, un peu plus polémique (forcément), et parfois
> > franchement provoc (et sans doute un peu trop long)
> >
> http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/
>
> Je ne suis pas contributeur wikipedien et je suis donc mal placé pour
> critiquer ce côté là. Mais concernant OSM, il manque certains points
> importants dans la comparaison:
> - homogénéité : si la longueur des articles sur wikipedia et le niveau
> des détails dans OSM dépendent tous les deux directement du nombre de
> contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels
> écarts d'informations entre zones géographiques. Ces grands écarts
> entre zones qui ont "tout" (rues, adresses, POI) et celles qui n'ont
> "rien" empêchent toute exploitation à grande échelle. On peut juste
> espérer que ces écarts se comblent avec le temps mais rien n'est moins
> sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent
> d'OSM. Et sur ce point, ils ont raison.
>
Homogénéité d'exhaustivité... oui, c'est très variable sur OSM.
En même temps, une parfaite homogénéité d'exhaustivité peut être un énorme
frein pour avancer et innover. Le cas de l'IGN est intéressant. Sa mission
de service public l'oblige à traiter tout les territoires avec le même
niveau de détail (en théorie).
Donc avant de passer à un niveau de détail supplémentaire, il faut un
énorme travail pour l'atteindre à peu près partout.
OSM ne s'embarasse heureusement pas de ce traitement identique des
territoires. Si on avait mis en place une telle logique, on serait bloqués
à de nombreux endroits car d'autres n'ont pas atteint le niveau minimal
pour passer globalement au suivant.
Oui, du coup, rien qu'en France on a des zone hyper détaillées où il ne
manquera pas une bande podo-tactile sur un passage piéton alors un peu plus
loin il manque encore des routes départementales.
- vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne
> le pense parce que dans OSM, il est plus difficile d'avoir un suivi
> des transformations sur une zone que wikipedia sur un article. Et les
> outils de contrôle ont aussi des lacunes (voir dernier point) Si, par
> exemple, on peut voir une version T-n_days dans wikipedia en 2 clics
> de souris, retrouver les données d'une zone géographique à T-n_days
> dans OSM nécessite beaucoup de temps, de ressources et connaissances
> informatiques. Et pour le cas où un petit vandalisme ou disons,
> "altération négative" lorsque ça n'est pas volontaire, est détecté, il
> n'y a pas d'outil pour facilement revenir en arrière alors que le
> "undo" sur wikipedia se fait en deux clics de souris. Il y a donc un
> déséquilibre manifeste entre contributions positives et négatives
> puisque les outils manquent pour lutter contre les secondes. On peut
> alors assister à deux phénomènes : soit le contributeur abandonne le
> projet suite à une frustration légitime. Ou alors, il "délègue" cette
> tâche à d'autres, en passant par cette liste par exemple ou sur un
> forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis
> les débuts d'OSM et certains sont même satisfait de ce modèle. Mais
> cela ne marche que s'il y a suffisament de volontaires pour prendre en
> charge ces annulations et que si elles se font suffisament tôt
> (techniquement, plus on attends, plus c'est difficile, voire
> impossible). Et si le nombre de vandalismes venait à fortement
> augmenter, ce petit groupe ne sera plus capable de faire face. Un des
> gros points forts de wikipedia est que les annulations sont
> directement et facilement accessibles par tout le monde. C'est un
> point majeur pour les projets collaboratifs qu'OSM ne propose pas.
>
+1 !
Plutôt que de parler de vandalisme, je préfère la notion de dégradation
volontaire ou involontaire.
Les dégradations volontaires sont rares, très rares.
Les involontaires sont fréquentes chez les nouveaux contributeurs, mais pas
que. Il nous arrive à tous de faire des erreurs.
Nous manquons vraiment d'outils à ce niveau pour réparer, mais c'est vrai
aussi que ça limite les guerres d'édition et l'annulation presse-bouton un
peu facile. La principale difficulté étant je pense les données supprimées
et leur impact. Il reste par exemple encore pas mal de zones impactées par
la "redaction".
Je regrette aussi que l'API ne soit pas plus regardante sur les données
qu'on lui envoie.
Il n'y a quasiment aucun contrôle, ce qui permet de créer des way avec
moins de 2 nœuds, des ways non conformes (repassant par le même nœud), des
tags vides, etc.
Historiquement ça peut se comprendre sur le plan technique (capacité de
traitement limité sur les premières implémentations), mais cette absence de
tout contrôle ça semble être devenue un principe et je n'en vois pas le
bienfait.
- "sémantique" : les tags sont nombreux dans OSM, trop nombreux. Les
> erreurs de typo ne sont que lentement corrigés, voir pas du tout. Il y
> a, par exemple, 910 valeurs différentes de "highway" et 983 valeurs
> différentes de "landuse" alors qu'il y en a 20 fois moins de
> documentés. Un autre point est que les tags sont facilement mal
> interprétés d'un pays à l'autre ("amenity=college" , "power=station"),
> mal utilisés ("leisure=park" pour une plate-bande de fleurs) ou ne
> sont pas cohérents, même à l'intérieur d'une zone géographique (chacun
> a sa propre interprétation d'un "highway=tertiary" ou du
> "highway=path"). Ainsi, si dans wikipedia, on appelle un chat "un
> chat", dans OSM, une voie se verra affubler d'un
> "highway=residential", "highway=unclassified", "highway=track" ou même
> dans certains cas "highway=service" au choix et suivant le
> contributeur sans que cela ne soulève de protestations. J'ajouterais
> qu'une grande partie de ces problèmes ne sont pas détectables par des
> outils de qualité et qu'il faut mettre son nez dedans pour les trouver
> et ne pas tout voir au travers de la lorgnette d'osmose ou de
> keepright.
>
C'est le problème de l'interprétation du terrain et des zones grises où un
objet sur le terrain est un peu à cheval entre 2 valeurs.
Il y a aussi un manque d'homogénéité parfois entre pays car des
interprétations différentes y sont faites, parfois effectivement à cause de
faux-amis, mais aussi par manque de vision globale. Un exemple...
ref:INSEE, qui a des équivalents dans différents pays mais bien sûr avec à
chaque fois une clé différente alors qu'on aurait pu harmoniser tout ça
avec un nat_ref=*
J'ai eu besoin de travailler dernièrement sur les découpages administratifs
et c'est une galère pour s'y retrouver, chaque pays aillant des
classifications spécifiques (sans parler du manque de cohérence des
admin_level).
> - le "contrôle" : bien peu sont ceux qui contrôlent les données OSM en
> les téléchargeant dans JOSM. Alors que dans wikipedia, tout ce qui
> ajouté "se voit" immédiatement par tout lecteur, la plupart des
> erreurs dans OSM ne sont corrigées que si elles sont "visibles" donc
> "rendues" sur la carte principale. Les autres sont ignorées jusqu'à ce
> qu'un contributeur s'y intéresse, souvent par hasard, en passant en
> mode "édition" et qu'il voit soudainement l'ensemble des données.
>
Et encore... difficile même en mode d'édition de détecter des problèmes de
tags. Il faut sélectionner les objets un à un pour voir qu'il y a un
problème de tag.
On juge par contre plus facilement des incohérences géométriques.
JOSM devrait silencieusement passer un coup systématique de validator sur
tout ce qu'on charge ;)
--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
