OpenStreetMap

J’ai entamé un travail de mise à jour dans OpenStreetMap des arceaux à vélo de la métropole de Lyon. Il reste beaucoup à faire.

À cette heure je compte 4.091 objets dans le jeu de la métropole versus 3.351 dans le jeu OpenStreetMap. Après analyse le greffon Conflation de JOSM annonce ces chiffres :

  • 2.846 correspondances, avec des écarts allant jusqu’à 40 mètres (la limite que j’ai fixée pour le rapprochement)
  • 1.245 objets présents uniquement dans le jeu de la métropole
  • 505 objets présents uniquement dans le jeu OpenStreetMap

Quand les positions correspondent et que c’est pas déjà renseigné, j’ajoute systématiquement la référence (le champ “nom” du jeu de la métropole) en tant que ref:FR:GrandLyon. Ceci permettra un rapprochement plus fiable par la suite.

Positionnement : Pour les objets que j’ai traités, l’erreur de positionnement se situe parfois dans les données OpenStreetMap, parfois dans les données Métropole, voire parfois dans les 2. Quand les arceaux étaient visibles j’ai recalé les positions dans OSM. J’ai laissé une note=positionnement corrigé par rapport à l'open-data en espérant que ça remonte peut-être un jour à la métropole. Et pour éviter qu’à chaque comparaison on se demande qui a raison. Malheureusement je ne l’ai pas fait au début et il en manque. Je referai une passe.

Suppressions : Il y a des arceaux qui disparaissent suite à des réaménagements de voirie. Ils sont supprimés du jeu Métropole mais ils sont encore présents dans les données OpenStreetMap. Quand j’ai un doute je laisse un fixme=resurvey, que je double avec une note demandant de confirmer si les arceaux existent encore. Ça peut faire doublon mais le fixme est plus facile à utiliser pour les requêtes, tandis que la note est plus visible pour les contributeurs qui sont sur le terrain.

Non référencés : À l’inverse il y a des arceaux présents sur OpenStreetMap (souvent du type Wilmotte typique de la métropole), mais qui ne sont bizarrement pas référencés dans le jeu Métropole. Dans ce cas j’ai laissé une note=absent du fichier open-data en déc. 2021 ce qui permettra à la métropole de les vérifier. Il y a aussi des doublons, créés par des contributeurs qui ont ajouté les arceaux sans vérifier qu’ils étaient déjà renseignés avec quelques mètres d’écart ; dans ce cas un ménage s’impose. Enfin on trouve des arceaux probablement installés par des écoles, des entreprises, des commerces, etc.

Capacité : Enfin, la capacité (nombre de vélos acceptés) évolue dans le temps. Souvent vers le haut, parfois vers le bas.

Tout ça donne le sentiment d’un travail fait en double de manière inutile. À la source, la métropole publie ce jeu de données mais leurs modifications ne sont pas répercutées ou alors tardivement dans OSM. De l’autre côté il y a un travail intéressant de la part des contributeurs qui corrigent certaines erreurs de position et qui ajoutent des arceaux non référencés mais la métropole ne bénéficie pas de ces contributions.

Il ne faut pas oublier que pour le vélo OpenStreetMap est aujourd’hui LA référence. Toutes les applications majeures utilisent ces données ; que ce soit GéoVélo, Strava, OsmAnd, OrganicMaps, etc. En termes pratiques pour les cyclistes et en termes d’image pour une métropole qui se veut pro-vélo, il est souhaitable que les nouveaux aménagements réalisés soient référencés rapidement tout en étant précis.

Rien que pour les arceaux à vélo parle de plus de 4.000 objets qui évoluent dans le temps. Si on ajoute les pistes et autres bandes cyclables alors la quantité d’informations à gérer devient énorme. Les pistes représentent une information encore plus demandée que les arceaux. Il serait souhaitable de trouver un système qui permette de collaborer efficacement. Dans l’idéal il y a l’option prise par la métropole de Montpellier : les agents saisissent directement dans OSM, avec un import contrôlé dans leur système. Le Grand Lyon n’en est pas là, au moins à court terme. Est-ce qu’il y a d’autres solutions envisageables ?

À minima on pourrait imaginer se baser sur la date de dernière modification et ne traiter que les objets qui sont plus récents dans l’open-data. Aujourd’hui cette date n’existe pas dans le jeu open-data. Elle existe à coup sûr dans le système, il faudrait peut-être envisager de la publier. Le suivi des évolutions est (un peu) facilité mais la mise à jour d’OSM reste manuelle et désynchronisée.

Les propositions sont les bienvenues.

Location: 69002, Rhône, Auvergne-Rhône-Alpes, France métropolitaine, 69002, France

Discussion

Comment from frodrigo on 20 December 2021 at 14:59

Il existe déjà des comparaisons de ce type d’objet dans Osmose-QA. http://osmose.openstreetmap.fr/fr/issues/open?item=8150

Il faut créer ce genre de configuration https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_cycle_parking_FR_bm.py

Ça peut traiter tous les cas de différences que tu signales https://github.com/osm-fr/osmose-backend/blob/master/doc/4-Merge.md

Comment from Gonéo on 20 December 2021 at 17:03

Merci :-) Il faudra que je prenne le temps de regarder ça en détails. À première vue ça cible les ‘nodes’. Ça sera déjà un progrès pour les parkings à vélo, toilettes publiques, et autres POI.

Je suppose que ça ne fonctionne pas pour les ‘ways’ (segmentation différente). Il y a quelque chose pour les pistes cyclables ?

Comment from frodrigo on 20 December 2021 at 17:09

Pour les données OSM ça peut marcher avec des nodes des ways ou relations, ça se configure. Pour les données OpenData, oui, que des points.

Comment from BenRib on 27 December 2021 at 13:41

Merci pour ton retour d’expérience, super intéressant.

Malheureusement, les collectivités ont des positionnements différents concernant OSM. Certains l’ignorent tout simplement et publient éventuellement leurs propres données en OpenData et d’autres l’utilisent à fond comme un outil de mise à jour et référence.

Je fais évidemment partie de ceux qui pensent qu’il faudrait mettre à jour OSM puis importer / contrôler les données pour un usage interne à la collectivité, mais le gros du travail c’est surtout de convaincre les collectivités….

Un des arguments qui pourraient pencher en faveur d’OSM c’est justement les objets présents uniquement dans le jeu OpenStreetMap et qui sont bien existant sur le terrain –> Ca montre ainsi que la fiabilité des données, qui est l’excuse souvent citée pour ne pas s’occuper d’OSM, est discutable, et qu’on ferait mieux de réfléchir à l’homogénéisation des outils.

Log in to leave a comment