[OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?

Philippe Verdy verdy_p at wanadoo.fr
Jeu 12 Déc 00:17:50 UTC 2013


Le 11 décembre 2013 22:35, sly (sylvain letuffe) <liste2 at 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).
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20131212/2d5fc01f/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr