Bonsoir, Pieren a écrit : > Il me demandait si la grande quantité de données et leur mauvaise > qualité ne nuisait pas au final au projet et ne rebutait pas de > nouveaux contributeurs potentiels comme lui l'a été sur cette commune. > Qu'en pensez-vous ? Que peut-on faire pour réduire cette mauvaise > impression ?
Pour ce qui est de la quantité de données, ce n'est pas vraiment un problème en tant que tel. Sur ma machine, JOSM commence à ramer lorsque je dépasse les 40 à 50 000 points selon le nombre d'objets associés à ces points, ce qui représente un joli quartier en ville. Certes, au fur et à mesure que l'information se densifie, les zones éditables se réduisent mais cela me semble inévitable et je ne vais pas me plaindre de la densification de l'information tant que celle-ci reste pertinente. Par contre, il m'arrive de travailler de manière « thématique » : je me concentre sur les bâtiments ou sur les routes ou sur l'occupation des sols. À chaque fois, je télécharge une foule de données qui ne m'intéressent pas, que je n'ai pas l'intention de modifier sur l'instant mais qui alourdissent considérablement les traitements (à commencer par l'affichage). Que la densité d'information limite ma capacité d'édition d'un quartier à un quart de kilomètre carré, ce n'est pas un problème lorsque je travaille sur le bâti. Par contre, c'est un vrai problème si je travaille sur l'occupation des sols, surtout lorsque je tombe sur un méga-polygone dont l'aire représente des dizaines, voire des centaines de kilomètres carrés... Si je prends un peu de recul, je constate que le problème vient du fait que je manipule pêle-mêle des objets géographiques qui ne sont absolument pas de même nature et, surtout, pas du même ordre de grandeur : un point remarquable, un bâtiment, une rue, une forêt et un département ne couvrent pas du tout la même surface. Mais pour faire simple, tous les objets d'un même type sont du même ordre de grandeur et sont décrits par des données de densité équivalente. Si je pouvais choisir de ne télécharger que le bâti, que les axes routiers, que les polygones d'occupation du sol, je pourrais éditer une zone dont la surface est compatible avec la taille de l'objet manipulé et je pense que la plupart de mes problèmes seraient résolus. Je considère donc qu'il y a un travail à faire sur l'API OSM qui devrait permettre la sélection des données téléchargées par mon application. Sans cette sélection, la manipulation de certaines données (notamment les polygone d'occupation du sol) devient un vrai calvaire et j'ai jeté l'éponge plus d'une fois. Mais pour en revenir à la qualité des données, les problèmes sont à mes yeux très différents selon que l'on parle du cadastre ou des polygones issus de CLC. * Cadastre Du point de vue de l'occupation réelle des sols, la description des cours d'eau fournie par le cadastre est des plus farfelues (mais je suppose que cette description répond à des critères précis pour le cadastre). J'ai donc tendance à ne jamais traiter les extractions décrivant les cours d'eau et je n'hésite pas à effacer l'existant quand je constate qu'il ne cadre pas du tout avec la réalité. Concernant le bâti comme les cours d'eau, j'ai plus d'une fois pesté ici et ailleurs contre les contributeurs qui ne veulent faire que du chiffre et ne prennent même la peine ni de fusionner leur import avec l'existant ni de recaler les routes (sans parler de nettoyer et de simplifier les données avant injection). J'essaie de temps à autres de faire preuve de pédagogie mais, en réalité, je ne sais comment remédier à cette ridicule course à l'échalote. Les propositions séduisantes de Guilhem Bonnefille me semblent difficiles à mettre en pratique. Ne nous reste que l'espoir d'outils capables de détecter toujours plus d'anomalies et d'attirer notre attention sur les zones calamiteuses afin que les contributeurs de bonne volonté remédient aux problèmes les plus grossiers qui desservent OSM et discréditent notre travail. * CLC Je ne suis pas choqué par l'imprécision native des polygones issus de CLC. D'une part, sauf erreur de ma part, ces polygones résultent du traitement d'images radar dont la résolution est de l'ordre de plusieurs dizaines de mètres. D'autre part, l'occupation du sol est parfois très mouvante, notamment à proximité de villes, et les données de CLC ont déjà 5 ans. Ce qui me chagrine par contre ce sont les méga-polygones dont le contour est décrit par plusieurs milliers de points et qui comportent parfois des dizaines de trous. Je trouve ces polygones très difficiles à éditer, surtout lorsqu'il s'agit de les scinder en plusieurs polygones parce que la continuité annoncée n'existe pas. J'aimerais les voir fractionnés en polygones plus petits. Cela n'alourdirait pas beaucoup la base et tout le monde y gagnerait. Je pense qu'une personne sachant adresser ce type de problème pourrait nous faire un outil des plus utiles. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
