Forum GéoCommuns

Une vision pour la base navigable

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” ?

https://daylightmap.org/

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.

5 Likes

Complément de réflexion sur les contributeurs et leur densité.

OSM a une forte densité de contributeurs en zones urbaines.

Du point de vue données de navigabilité, ce sont les zones les plus complexes car on y trouve l’essentiel des interdictions de tourner, des voies avec pré-sélection, des feux de circulation, passages piéton, panneaux directionnels et autre, des voies cyclables, etc.

C’est aussi en zone urbaine qu’il y a le plus de changements sur ces données et donc besoin de jardinage permanent.

Calculer un itinéraire proche de la réalité en rase campagne n’est pas vraiment un problème, mais en zone urbaine dense, oui.

C’est sûrement une force supplémentaire à prendre en compte et une forme de complémentarité avec la collecte plus homogène en zone rurale comme peut le faire par exemple l’IGN.

Tu dis plus haut que tout ce qui touche à la navigabilité « se ferait directement dans OSM » : comme un contributeur OSM, un collecteur IGN ne fera pas non plus de double saisie…. Des lors, comment le faire contribuer à OSM en même temps qu’il met à jour la BD topo dans geoconcept? (Demain qgis peut être)
Cela étant, tes idées pour la constitution de cette base sont inspirantes, très OSM centrées :smirk: (je charrie) - blague à part, admettons: les agents IGN viennent alimenter OSM pour parvenir à faire naître ce « commun navigable » :
comment ensuite faire bénéficier ce travail à la BD TOPO ?
En matière de diffusion (et là on va repartir sur le fil ODBL versus LO) comment contenter ceux qui ne veulent pas intégrer de l’ODBL ? (Je pense pas au GAFAM hein?)

Qu’on ne se trompe pas… le sens des contributions ne peut aller que BDTopo → OSM et pas l’inverse pour cause de licence.

Donc c’est l’inverse, comment quand quelqu’un contribue à la BD Topo peut-il être guidé pour reporter un éventuel changement nécessaire dans OSM ?

Nous faisons déjà côté OSM des analyses croisées avec la BD Topo pour signaler aux contributeurs des tronçons de route manquants.

C’est une première étape, on peut aller beaucoup plus loin (conformité des noms, du type de voie, du sens de circulation ou d’autres attributs).
L’intégration peut être plus poussée dans les outils d’édition (mais cela suppose je pense pas mal de développement à faire), ou bien on peut aussi imaginer qu’une deuxième passe de report est faite par des agents dont ce serait le rôle principal et uniquement sur les différences.

A qui penses-tu ?

Un réutilisateur qui choisit de ne pas rentrer dans une logique de partage (donc qui refuse d’utiliser des données ODbL) s’exclut lui même du commun et de ses bénéfices.

Pour les AFAM (oui, sans le G ou alors G pour Grab qui est un Uber asiatique), tous contribuent à OSM et utilisent OSM. Google est l’exception, mais la porte leur est ouverte comme à tout le monde si ils respectent le commun (donc l’ODbL).

Les données sous ODbL n’empêchent toutefois pas de calculer des itinéraires et des isochrones (entre autres) qui ne seront pas sous ODbL car ce ne sont pas des bases de données.

Question relative à la communauté autour de la BDTopo/Uni (?).
En fait, je ne connais pas la communauté autour de la BDTopo, qui y contribue, quels sont les parcours de contributions, de validations.
Mais aussi comment cette communauté autour de la bdtopo s’articule aux frontières avec les éventuelles autres bases navigables en Europe (est-ce que cela existe d’ailleurs ?) et donc les autres instituts nationales ? (oui je découvre l’immensité de mon inculture :D)

1 Like