Je vous partage ma vision pour cette base navigable avec les réflexions qui l’ont alimentée.
Cette base aurait pour but principal et initial de permettre:
- des calculs d’itinéraires
- des calculs d’isochrones
- de gérer différents modes de transport
- du guidage sur les itinéraires
À plus long terme, on peut inclure des données sur la circulation voire en temps réel, mais c’est encore plus ambitieux et peu envisageable à court terme. J’ai tenté d’explorer ce champ avec OpenEventDatabase, dont on pourra reparler plus tard si besoin.
Quelles sont les données libres disponibles ?
- BD Topo IGN (peut-être un peu plus dans la BD Uni ?)
- données OSM
Forces et faiblesses des données de la BD Topo:
- filaire très complet, très bonne exhaustivité
- mise à jour contrôlée, à priori
- description sémantique limitée
- absence d’éléments impactant un calcul d’itinéraire (présence de feux de circulation, d’interdictions ou d’obligations de tourner, absence de stop/cédez le passage/ passage piétons/ralentisseurs)
- absence d’informations pour le guidage (panneaux directionnels)
- très centré sur l’usage VL (peu d’infos vélo comme les voies dédiées, les DSC, etc)
- France uniquement
Forces et faiblesse des données OSM:
- richesse sémantique
- couverture continue au-delà de la France (même modélisation)
- non limité VL, beaucoup de données vélo, voire piétons
- présence de nombreux éléments impactants, mais non-exhaustive
- présence d’infos pour le guidage (description des panneaux, des files de préselection) mais aussi non-exhaustive
- moins exhaustive sur le filaire même (des tronçons de voiries manquent encore, mais de moins en moins)
- mise à jour libre, contrôle à postériori
Que faire ?
Créer une base nouvelle, qui mélange les deux ?
Oui, c’est une option, mais cette base sera forcément sous licence ODbL, comme OSM, elle n’apporte donc rien sur le plan licence.
Sa constitution sera sûrement complexe et les mises à jour régulières de ses deux sources qui continueront à évoluer seront sans arrêt à réconcilier. Ceci nécessitera une énergie non-négligeable, difficile à tenir en continu.
Imaginer une fusion initiale plus ou moins automatique puis une mise à jour plus ou moins manuelle me semble aussi assez peu réaliste. Qui va y contribuer ? Un contributeur OSM ne contribuera pas deux fois.
Il ne faut en effet pas négliger dans nos réflexions que les “communautés” ne sont pas extensibles à l’infini, c’est pour cela d’ailleurs qu’on se regroupe, plutôt que de faire une base carto chacun de notre côté.
Le besoin en calculs d’itinéraires est déjà là, or le temps nécessaire à la constitution de cette “3ème base” risque d’être assez long. En attendant, toujours pas de service à proposer de mieux que ceux actuels.
Ne pas créer de nouvelle base, mais compléter OSM
Intégrer dans OSM les données IGN pour combler les faiblesses, pour être plus exhaustif, pour utiliser le référentiel de la BD Topo comme base de comparaison des écarts sur ce point-là et sur quelques attributs (par exemple les voies à sens unique). On a par exemple 100 000 tronçons de la BDTopo à intégrer d’après une de nos analyses Osmose qui compare les deux bases.
Un recalage géométrique n’est pas du tout indispensable, il impacte peu les calculs d’itinéraires, c’est la topologie et les communications entre tronçons qu’il faut bien avoir ainsi que les éléments impactants les temps de parcours. Là OSM, aujourd’hui, a bien plus de données, vu que côté IGN, je ne crois pas qu’elles soient collectées.
On peut dès à présent calculer des itinéraires et des isochrones, vu qu’on a en plus les outils pour cela, adaptés au données au format OSM. L’IGN a d’ailleurs dû convertir ses données dans un format très proche osm pour alimenter un moteur tel qu’OSRM.
Des services de secours l’ont d’ailleurs déjà compris. Ce n’est sûrement pas parfait, mais c’est ce qui est le plus complet et directement améliorable sans compter l’amélioration continue par les contributeurs réguliers.
Les mises à jour pour tout ce qui touche la navigabilité se feraient directement dans OSM.
Une interdiction de tourner à ajouter → OSM.
Changement sur des feux de circulation, des ralentisseurs, des stop → OSM
Regardons les choses en face, OSM est bien plus qu’un MVP de cette base navigable.
Qu’est-ce qui coince au juste ?
Le contrôle à postériori sur des données en changement perpétuel ?
Qui a entendu parlé de “daylight” ?
C’est une version des données OSM produite par Facebook, qui applique dessus un processus de contrôle qualité, de vérification de cohérence. Ceci leur permet d’utiliser pour leurs services des données contrôlées à posteriori plutôt que celles en “live”.
Il repartagent bien sûr le résultat (merci le partage à l’identique !), et pour éviter de refaire sans arrêt les mêmes corrections, il corrigent aussi en amont dans OSM. Tout le monde y gagne.
Une approche de ce type limitée au données routières en ferait une excellente base routière navigable comme celle recherchée.
Autre chose coince ? Merci de préciser.
Mieux à proposer ? N’hésitez-pas à partager votre vision.
(je charrie) - blague à part, admettons: les agents IGN viennent alimenter OSM pour parvenir à faire naître ce « commun navigable » :