Le 11 décembre 2013 22:35, sly (sylvain letuffe) <lis...@letuffe.org> a écrit :
> Le mercredi 11 décembre 2013 21:26:43, Stéphane Péneau a écrit : > > J'ai en tête l'exemple de 5 ou 6 communes voisines dont le cadastre > > raster est décalé, et une frontière départementale avec. Je le mets où > > le fixme ? Si je décide d'un emplacement, je suis sur à 99% que sur une > > zone aussi vaste, il ne sera jamais vu par la personne qui pourrait en > > avoir besoin. > > Tout à fait d'accord. Comme dis dans un autre mail, la technique du fixme > qui > pendouille à un point pour parler d'une zone est très merdique. (vu que tu > sors des chiffres tiré du chapeau, moi aussi ;-) ) Mais en choisissant d'en > faire une note à la place, tu as 99.5% de chance qu'elle ne soit jamais vu > cumulé à 50% de chance qu'elle soit fermée "n'est pas un problème sur la > carte" > La question reste donc ouverte, ou mettre cette info sur la zone ? > Comme le font certains pays (particulièrement ceux ayant une couverture très parcellaire en imagerie de bonne qualité, notamment en Afrique ou Europe orientale), il y a dans la base OSM des polygones délimitant les sources d'imageries et leurs mises à jour. C'est sur ces polygones qu'on peut mettre des annotations. Il faudrait toutefois qu'un schéma commun se dégage pour unifier ces polygones (afin qu'ils ne soient pas définis comme des boundary=administrative+admin_level=2, comme on en trouve par exemple en Ukraine où il sont confondus avec les frontières administratives du pays, dans un joyeux "bordel", et plus récemment aux Philippines avec les sources d'imagerie haute résolution pour le projet temporaire HOT). Ce schéma commun éviterait de réutiliser des rendus existants des frontières administratives, en permettant un rendu sur une couche spécifique mais commune entre les pays, afin de rendre compte des sources d'imagerie possibles, leurs versions et mises à jour, et les corrections géométriques à appliquer ou ne pas appliquer dans les autres données OSM. Sinon on pourrait vouloir que les logiciels d'édition sachent charger et modifier des données sur une autre base que la seule base OSM (possible avec des greffons pour JOSM par exemple, mais pas encore pour iD et sans doute bon nombre d'autres éditeurs et outils) afin que ces polygones ne polluent pas la base OSM elle-même. Un vœu un peu pieux quand on voit les difficultés à travailler avec de nombreuses sources de données différentes et quand bon nombre d'outils comme iD (hormis JOSM et les outils GIS commerciaux) ne disposent pas de la possibilité d'y inclure facilement des greffons spécifiques pour connecter certaines bases tierces (sans tout mélanger dans une base "pilote" fourre-tout) et travailler en couches séparées, avec des opérations de fusion mieux contrôlées assurant la compatibilité mutuelle (si possible dans les deux sens) entre les schémas des bases interconnectées. A l'heure où, ici, on entend vouloir remonter des corrections depuis OSM vers les SIG des collectivités ou l'IGN, le développement de ces greffons d'échange de données, de comparaison et de "fusion contrôlée" devient de plus en plus d'actualité. Jusqu'ici, on a surtout développé ici des échanges unidirectionnels (des bases OpenData publiques pour un "import" vers OSM, mais beaucoup trop peu dans l'autre sens). Cela traduit un comportement d'OSM pouvant être perçu comme individualiste, centralisateur et seul normalisateur... alors qu'on pourrait travailler de façon plus équitable et mieux concertée sans laisser la charge du développement des greffons en sens inverse aux seules collectivités et organismes publics qui n'ont pas les moyens de le faire aussi vite et avec autant de moyens humains, voire même matériels et financiers, que la communauté OSM. Au final, les échanges mutuels étant facilités, on bénéficierait aussi de l'accélération des mises à jour mutuelles, à moindre coût de chaque côté (en terme de travail à faire) et donc des cartes certes différentes dans leur contenu et classification spécifique, mais bénéficiant d'une base commune élargie plus précise et de meilleure actualité. Par exemple les collectivités ont des besoins de gestion des historiques, de la continuité des données, et de la planification des futurs aménagements, qui entrent mal dans les données prise en charge par OSM ; il en est de même les statisticiens, les centres de recherche, les historiens, les agences et assos de préservation, conservation ou développement en matière environnementale, culturelle, sociale, touristique ou économique, etc. Ces besoins, même utilisant des données ouvertes (OpenData), ne peuvent pas être couverts par OSM dans ses missions et limites actuelles. OSM ne peut donc pas être normalisateur pour tout. OSM tend à vouloir trop simplifier les problèmes uniquement, uniquement en faveur de ceux liés aux seules données qu'il tient à intégrer. Les échanges et adaptations dans l'autre direction sont nécessaires : on devrait apprendre à ne pas seulement aller "se servir" gratuitement dans les données OpenData (et en faire tout ce qu'on veut) mais aussi à permettre ou faciliter des remontées des infos OSM dans l'autre sens. Développer un greffon ou outil destiné à importer des données dans un sens ne suffit pas, les mêmes développeurs devraient se demander comment faire la conversion inverse. Ce qui nous permettrait aussi d'avoir d'autres analyses sur la qualité de nos propres données par rapport à nos fournisseurs, et de les corriger dans notre base avant même que les collectivités nous signalent le problème ou viennent à nous critiquer publiquement sur nos propres erreurs et omissions inévitables : contre ce genre d'attaque, au lieu de répondre par des critiques sur les défauts des autres solutions et nous "fabriquer des ennemis", on démontrerait notre capacité à répondre à ces erreurs et collaborer avec ceux qui développent les autres solutions ou les vendent (et à soutenir la comparaison sur ce point où ils ont encore de l'avance sur OSM et où ils sont encore plus efficaces que nous).
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
