[OSM-talk-fr] Import fichier CSV OSM

Philippe Verdy verdyp at gmail.com
Mar 15 Déc 04:15:00 UTC 2020


Ce CSV peut cependant être utile à des outils de rapprochement existants,
comme Osmose qui *propose* (mais ne fait pas) de l'intégration. On a le cas
par exemple pour l'intégration des écoles et de toutes sortes
d'équipements, dont de nombreux sont déjà dans OSM, mais ne demandent qu'à
être rapprochés et validés.
De même pour ce sujet des adresses, on a l'intégration BANO: n'est-il pas
plus simple alors de rapprocher ce CSV venant de l'office du tourisme du
fichier produit par la mairie pour la BAN, sachant qu'au final il y aura
rapprochement entre la BAN et BANO pour une intégration OSM ?

Dans ce cas on peut inviter l'office du tourisme à se rapprocher du/des
mairie(s) concernées pour voir comment ils peuvent tous se synchroniser et
"accorder leurs violons", afin que chacun s'enrichisse directement (il faut
savoir que l'intégration d'OSM vers les autres sources est très difficile,
et très long, le guichet d'échange BAN/BANO ne fonctionnant bien que dans
un seul sens, BAN vers BANO et pas l'inverse, même quand on fait les
signalements dans l'outil adhoc créé pour la BANO, il faut des mois ou plus
pour voir les différences disparaître ou pour que celles-ci soient
requalifiées une fois un accord trouvé).

Donc je pense qu'il est plus prudent pour l'office de tourisme de se
rapprocher avec la BAN s'il veut une intégration plus rapide, mais si ça
bloque sur ce point, il peut faire un second rapprochement ensuite avec les
outils BANO (qui affichent déjà les différences BAN/BANO, et permet
justement de trouver ce qui devrait être vérifié en priorité dans les
autres bases à rapprocher. Si l'office de tourisme pense qu'il a de
meilleures données qualifées que la mairie pour la BAN, alors il peut
contribuer directement dans OSM sur ces points particuliers, et il mettra
donc assez vite à jour le rapprochement BAN/BANO vers un peu plus de
convergence.

Mais tout ce processus de convergence est long, il faut être patient et
accepter des marges acceptables de différence correspondant à l'emploi de
chaque base de données: souvent un office de tourime n'a pas besoin par
exemple du même degré de précision spatiale, et il peut communiquer aussi
sur des noms et orthographes proches correspondant à un usage local ou
fréquent ou lié à d'autres langues : OSM a déjà pas mal de champs pour ces
variations de noms, mais rien pour les variations de géométrie, le seul
critère à retenir étant le facteur d'échelle de la carte qu'on veut
réaliser et afficher: un office de rtourisme n'a pas forcément besoin d'un
point très précis pour faire une carte de tout son territoire couvert (à
l'échelle d'une ou plusieurs communes, ou à l'échelle d'un site particulier
avec ses zones de service liées : hôtels, restaus, campings, accès et
réseaux de transport).

En revanche il peut être intéressant pour lui de voir comment mieux
qualifier les tags de nomenclature OSM afin de correspondre aux usages,
notamment pour les recherches thématiques. OSM est riche sur ce point, mais
il peut y avoir des surprises : les outils de recherche par tag d'OSM
permettent de faire le point de ce qui manque ou serait en trop (et aussi
des outils comme UMap qui peuvent faire cette recherche et l'afficher à la
fois sur une carte et dans un tableau de données, qu'on peut alors exporter
facilement pour le comparer à un autre fichier externe). Qui sait, vous y
trouverez sans doutes des points et données dont vouxd n'aviez pas idée ou
que vous avez oubliés aussi: une petite enqupête de votre côté et vous
pouvez les valider dans vos fichiers et les faire remonter et rapprocher
avec d'autres bases.

Tout ceci participe d'un échange participatif où chaque acteur peut
travailler et contribuer. Au final cela vise à la convergence, mais on
n'aura jamais une convergence absolue, automatique et instantanée (même
pour ds données dites "réglementaires" et supposées à déclaration
obligatoire, car il y a aussi des délais légaux pour le faire et des délais
de rectification) car tout finit par changer un jour et tout le monde ne
sera pas au courant en même temps ni n'aura encore pu vérifier de son côté.
Il est donc important dans toute base de garder un suivi daté des
modifications afin de savoir ce qui a été validé et quand et estimer la
fraicheur relative de ce qui est présent dans une base : cela permet aussi
de planifier et étaler dans le temps les travaux de revérification et
correction sans avoir tout à faire tout de suite et être pris à agir dans
l'urgence (ce qui peut demander un travail énorme et de gros moyens humains
et en temps dont chacun ne dispose pas).



Le ven. 27 nov. 2020 à 12:42, Marc_marc <marc_marc at mailo.com> a écrit :

> Bonjour,
>
> Le 27.11.20 à 10:26, Maïtena HARISTOUY a écrit :
> > Dans le cadre de mon activité professionnelle au sein de l'OT Pays
> > Basque, je fais partie des contributeurs OSM et je me demande s'il est
> > possible d'importer un fichier CSV dans OSM afin de mettre à jour OSM.
>
> les imports suivent une procédure très carré
> https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines
>
> Cependant je doute fort qu'un office du tourisme
> dispose d'un jeux de donnée dont tout est absent ou faux dans osm.
> il va donc falloir intégrer l'un à l'autre cad ignorer
> ce qui est commun aux 2, compléter l'un quand l'autre est déjà présent
> mais avec moins d'information, ajouter quand cela manque totalement.
>
> avant de se lancer dans ce genre d'opération,
> je vous conseille fortement de contribuer à la main
> cad aller sur openstreetmap.org, repérer l'emplacement
> d'une des rues dont vous avez une donnée libre, repérer si elle
> existe dans osm, ajouter le nom manquant ou corriger.
> ce n'est qu'ainsi qu'on se rend compte qu'importer un csv n'a
> pas de sens dans l'écosystème et qu'on découvre ce qui
> serra nécessaire pour les opérations à plus grande échelle tel
> que les notions de point, ligne, clef, valeur, le fait qu'une
> rue "dans la vrai vie" peux avoir plus d'un objet dans osm (un tronçon
> éclairé, un autre non, ou un tronçon pour la partie oü passe
> un bus, un autre tronçon pour la partie oü le b us ne roule pas...)
>
> à noter que si vous données sont déjà remontée
> dans les méandres de l'administration,
> https://bano.openstreetmap.fr/fantoir/ devrait vous être utile
> pour comparer les rues entre osm et les bases publiques.
>
> Cordialement,
> Marc
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20201215/ed345df4/attachment.htm>


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