Forum GéoCommuns

Feuille de route IGN navigabilité

Bonjour,
il s’avère qu’IGN a commis une espèce de version martyre d’un document qui s’appelle pompeusement une “feuille de route” sur la navigabilité. Ca trace les limites actuelles de la base IGN et ça esquisse des solutions pour l’améliorer. C’est très incomplet (on n’y parle pas du tout licence, par exemple), très IGN centré, et ça vise accessoirement à répondre en particulier à un cas particulier. Nous l’ouvrirons volontiers à relecture/commentaire. Quel est (techniquement) le meilleur moyen de le faire à vos yeux? (=je le mets où, mon doc Word?)

4 Likes

Le passer en PDF ou .odt et il sera accepté ici (icône image / joindre un fichier).

Ca va pas être un must de relecture collaborative! On s’ouvre un Resana Géocommuns? :wink:
Je mets le PDF en PJ…
FdR-navigabilite_V1-2.pdf (509,7 Ko)

3 Likes

La même chose reprise en Markdown pour plus d’accessibilité.

Feuille de route

« Base Routie re Navigable »

Les travaux pour le projet NexSIS ont permis de poser le constat que, dans son état actuel, le réseau
routier de la BD Topo avait une qualification insuffisante pour répondre aux attentes de l’ANSC en
termes de navigabilité. Dans le même temps, les sollicitations autour de cette problématique de
navigabilité se sont multipliées ces derniers mois.

Le présent document décrit les limites du référentiel actuel et propose de solutions avec, en
particulier, un engagement de premier produit pouvant être viable pour NexSIS à court terme.

1 Contexte

1.1 Historique IGN

1.1.1 Données

Jusqu’au début des années 2000, IGN a produit une base de données Géoroute, dédiée à la
navigation. Ces données ont d’ailleurs servi à la constitution initiale des bases du marché Here et
TomTom. Lors de la mise en place de « BD Uni », Géoroute a été apparié avec le réseau routier de la
BD Topo, mais l’IGN s’est peu à peu désengagé du marché. Certaines informations ont été
abandonnées (celles relatives aux vitesses) et les autres (non-communication et sens de circulation
en particulier) ont donné lieu à une moindre priorité de mise à jour.

L’étude utilisateurs réalisée lors des travaux autour de la BD Uni V2/BD Topo V3 en 2015 a révélé une
appétence moyenne des utilisateurs pour une information navigable, avec une préoccupation faible
pour la notion de souveraineté (« que l’IGN fasse bien ce qu’il est supposé faire avant d’aller faire ce
que des acteurs privés font déjà bien »). IGN travaillait déjà pour la DSR à l’époque et un besoin de
navigabilité était cependant nettement identifié. L’IGN a fait le choix de rendre la BD Topo V
structurellement navigable, sans pour autant engager d’investissement important pour collecter
l’ensemble des informations nécessaires pour qu’elle soit « effectivement » navigable.

Les faiblesses identifiées sont les suivantes :

  1. Vitesse - Le réseau routier de la BD Topo porte un attribut « Vitesse moyenne VL » qui est
    calculé de manière un peu rudimentaire. Globalement, on va trop vite sur la BD Topo.
    D’autre part, l’IGN ne dispose pas d’une information relative aux vitesses règlementaires
    (vitesses limites autorisées, VLA) (panneaux).
  2. Restrictions - Les informations de restrictions sont imparfaites :
    a. Elles sont d’un niveau de qualité convenable sur les sens de circulation. Les matrices
    de confusion issues des contrôles qualité sont bonnes.
    b. L’information est « moyenne » (et non contrôlée) sur les non communications.
    L’entretien de cet attribut par l’IGN n’est pas une priorité aujourd’hui, et sa qualité
    est de fait hétérogène.
    c. La collecte des restrictions de hauteur/largeur/poids n’est également pas une
    priorité pour le collecteur IGN, le niveau de qualité s’en ressent.
  3. Points d’intérêts - Au-delà de ce qui est strictement « réseau routier », l’offre IGN souffre
    d’une faiblesse sur les points d’intérêt (POI). Les POI « publics » sont honorables (mairie,
    école…), les POI « privés » sont globalement absents, au moins dans le moteur de recherche
    actuel du Géoportail.
  4. Informations trafic – Aujourd’hui, l’IGN ne propose aucune information sur le trafic, ni « en
    direct » ni « historique ».
  5. Dans une moindre mesure, la structure de la BD Topo pourrait montrer ses limites dès lors
    qu’on souhaiterait aller vers une base à plus grande échelle.

1.1.2 Services

En termes de services de calculs d’itinéraires (et d’isochrones), l’IGN, longtemps, n’a rien proposé sur
Geoportail. Poussé par quelques utilisateurs (DSR, IGN Rando…), un service a fini par être proposé
au début des années 2010. L’outil proposé est très longtemps resté en « bêta ». Pour la partie
strictement isochrone, il a connu un pic de popularité lors des confinements de la crise sanitaire en
2020. L’outil a été mis à niveau en 2021 (publié en septembre).

Aujourd’hui, le moteur de calcul d’itinéraire, en tant qu’algorithme, est satisfaisant. Il s’appuie sur
des outils open source (OSRM et PGRouting) qui sont à l’état de l’art et utilisés par la communauté.

Par contre, le service de calcul d’itinéraire du Géoportail souffre essentiellement de la faiblesse de la
base de données utilisée en entrée (cf. analyse en section précédente). Il souffre également de la
qualité de service de l’infrastructure Oshimae. Il est utilisé par la DSR dans le cadre du dispositif de
contrôle automatisé.

1.2 Des sollicitions externes croissantes

Si l’enthousiasme exprimé par les utilisateurs avait été assez faible en 2015, les marques d’intérêt se
sont multipliées ces dernières années. On peut citer en particulier :

  • Le département des contrôles automatisés de la délégation à la sécurité routière (DSR/DCA).
    D’une part, la DSR a besoin d’un outil de calcul d’itinéraire pour gérer les « tournées » des
    véhicules de contrôles ; d’autre part, le projet prévoit que la DSR mette à disposition une
    base de données de panneaux de signalisation (non encore effective), qui permettrait
    notamment de disposer d’une information sur la vitesse règlementaire. La DSR a été moteur
    pour le nouveau moteur de calcul d’itinéraire du Géoportail.
  • L’agence du numérique de la sécurité civile (ANSC) et le projet NexSIS 18-112, système
    d’information et de commandement unifié des services d’incendie et de secours. L’ANSC
    exprime le besoin de disposer d’une base de données routière navigable, souveraine pour
    conduire la décision d’engagement des véhicules de secours sur les lieux d’intervention.
  • Le Service des technologies et des systèmes d’information de la sécurité intérieure (ST(SI)²),
    qui pilote le SI de la police et de la gendarmerie nationale, a besoin d’un réseau navigable
    pour s’affranchir des solutions de calcul d’itinéraire/d’isochrone et des données d’ESRI/Here.
    Il souhaite s’inscrire dans un besoin plus global commun à différents acteurs d’un tel réseau
    routier navigable.
  • L’Agence régionale de santé Ile-de-France (ARS IDF) a émis plusieurs besoins dont celui
    d’affiner le calcul du temps de trajet au regard des autorisations spéciales dont disposent les
    véhicules type SAMU pour leurs déplacements (vitesses supérieures à la vitesse maximale
    autorisée, etc.). Un besoin en matière des données concernant le trafic en temps réel dans le
    calcul d’itinéraire a aussi été exprimé.

(^1) Geoportail.gouv.fr au 31/03/
(^2) L’outil de « snapping » d’une randonnée s’appuie en fait sur le moteur de calcul d’itinéraires…
(^3) Popularité qui ne reposait pas sur une réalité puisque que les zones de confinement correspondaient à des
emprises à vol d’oiseau…

  • Lors des premières publications autour de la stratégie des Géocommuns, OSM France a
    « challengé » l’IGN autour de deux propositions de géocommuns : une base de vues
    immersives, et… une base de données routières navigables.
  • Dans le cadre de travaux de « clarification de périmètre » avec le CEREMA autour du thème
    « route », la possibilité d’un guichet voirie dédié à l’entretien du réseau routier, dont les
    attributs de navigation, a été évoquée…

Globalement, on peut considérer qu’il y a aujourd’hui une appétence certaine pour une navigabilité
souveraine, au niveau de la base de données comme des services.

2 Perspectives

2.1 Axes d’améliorations

On reprend ici les 5 faiblesses de la BD Topo identifiées précédemment, croisées avec la dimension
« sollicitations externes ».

2.1.1 Vitesse

La piste de l’amélioration des vitesses (et, plus globalement, de la BD Topo) en s’appuyant sur une
donnée externe (Here, TomTom) a été explorée mais s’est heurtée aux conditions de licence – la
licence ouverte^4 souhaitée par l’IGN et les utilisateurs est incompatible avec les modèles
commerciaux.

Pour améliorer les valeurs de l’attribut « Vitesse moyenne VL », l’IGN a initié un nouvel algorithme de
calcul des vitesses en s’appuyant notamment sur un script utilisé par le SDIS 44. Ce script présente
des avantages :

  • Il donne des résultats satisfaisants aux yeux du SDIS
  • Il ne s’appuie que sur des éléments de contexte décrits dans la base de données (la largeur
    des voies, les intersections, la proximité d’une école…) ; il ne nécessite pas d’information
    complémentaire.

On estime que ce script résout le problème lié aux vitesses.

Action 1.1 : Valider le nouvel algorithme de calcul des vitesses

Action 1. 2 : Industrialiser le script et, en particulier, l’implémenter dans les outils de production de la
BD Topo

2.1.2 Restrictions / panneaux

2 axes peuvent permettre d’améliorer la situation actuelle, qui peut être considérée comme
satisfaisante sur les sens uniques, mais pas sur les autres restrictions.

  1. Mettre en place une dynamique collaborative pour favoriser le fait que le gestionnaire de la
    voie soit aussi le gestionnaire des informations relatives à la voie dans la base de données ; et
    également pour développer une logique de signalement voire de contribution directe,
    notamment avec les SDIS via NexSIS. Cette dynamique collaborative pourrait être portée par
    l’IGN et/ou par le CEREMA suite aux travaux en cours de « redéfinition de périmètres ».

Action 2.1 : intégrer la dimension collaborative dans NexSIS, faciliter les contributions directes des
SDIS.

Action 2. 2 : formuler une proposition de guichet voirie, aller vers un Géocommun Voirie

(^4) On parle ici « licence ouverte » sans plus de précision (Licence ouverte Etalab 2.0 ou OdbL ?) – la discussion a
été ouverte sous cet angle « licence » sur le forum Géocommuns.

Action 2. 3 : proposer et soutenir une disposition législative pour rendre obligatoire la contribution du
gestionnaire (via DSR? MinInt ?)

  1. Organiser une collecte de panneaux par un levé immersif massif, qui pourrait être adossé :
    a. A une commande d’un acteur public, notamment pour un jumeau numérique
    b. A une activité dédiée dans le cadre de NexSIS : schématiquement, NexSIS monte en
    charge « par département », on pourrait organiser un levé massif départemental au
    gré des « commandes » NexSIS (point d’attention : on risque de créer de
    l’hétérogénéité…) – une expérimentation (peu concluante) a déjà été faite avec
    Futurmap^5 ; une autre est en cours de montage avec Geoptis.
    c. Au projet DSR/DCA
    d. A un Géocommun de vues immersives

Action 2. 4 : analyser l’existant et son utilisabilité en termes de vues immersives

Action 2. 5 : monter une proposition de levé massif dans le cadre de NexSIS

Action 2. 6 : relancer DSR/DCA

Certaines de ces actions pourraient être traitées dans le cadre de la « pré-investigation produits »
autour d’un Street View commun lancé par la Fabrique des Géocommuns.

2.1.3 Points d’intérêts

Trois pistes peuvent être évoquées pour améliorer l’information relative aux points d’intérêts :

  1. Les travaux autour des établissements recevant du public (ERP), actuellement en cours au CNIG.

Action 3.1 : assurer l’expression de besoin auprès du GT CNIG

  1. Il existe manifestement des informations présentes dans BD Topo et absentes du moteur de
    recherche Geoportail, en particulier les informations relatives aux zones d’activités et
    d’intérêt (ZAI).

Action 3.2 : Améliorer le moteur de recherche - Etudier les différences entre base de données (BD
Topo) et moteur de recherche Géoportail

  1. L’exploitation de données OSM^6 dont la base de POI sur les informations « privées » est
    sensiblement meilleure que celle de la BD Topo. On pourrait en outre profiter de ce travail
    pour enrichir les fonds cartographiques IGN. Deux aspects techniques et juridiques sont à
    étudier.

Action 3. 3 : échanger avec OSM France pour identifier des pistes de travail commun

Action 3. 4 : monter un POC Geoportail/Geoplateforme (GPF) autour des POI OSM (outils de
recherche/géocodage…)

Action 3. 5 : ré-instruire les conditions de réutilisation des données OSM

(^5) Futurmap exploite les vues immersives de Tomtom, dont la couverture n’est pas exhaustive. La valeur ajoutée
n’a pas semblé importante lors du test réalisé sur Lagny/Marne (77).
(^6) Les fichiers SIRENE géocodés pourraient également être une source…

2.1.4 Trafic (temps réel ou historique)

Les informations trafic manquent aujourd’hui totalement dans les données et services IGN. C’est un
aspect qui mérite d’être travaillé mais, d’une part on part d’assez loin, d’autre part ça n’est pas un
besoin primaire aujourd’hui, en particulier dans NexSIS. Outre un abandon de cette préoccupation, 2
pistes méritent un peu d’attention :

  • Les travaux du CEREMA et, plus globalement, les « boucles de comptage » assurées par des
    acteurs publics. Le guichet voirie évoqué en 2.1.2 pourrait intégrer cette dimension, au moins
    pour une information trafic « historique ».

Action 4.1 : étudier l’intégration de l’information trafic au guichet voirie

  • Une source externe, en particulier en s’associant à des constructeurs automobiles ou à des
    acteurs de la téléphonie.

Action 4.2 : assurer un benchmark de l’information disponible (téléphonie, automobile, programme
Waze…) [c’est pour qui? ; c’est pour quand ?]

2.1.5 Structure de la base

La structure de la BD Topo a certes évolué pour être « navigable », et elle pourra accueillir les
informations que l’on serait amené à créer/récupérer en réalisant les actions identifiées. Mais cette
structure est probablement insuffisante pour aller plus loin, que ce soit pour la bonne exploitation de
la base (lien panneau/tronçon de voie, par exemple…) ou pour de la très grande échelle (carto HD
pour véhicule autonome).

Action 5.1 : Etudier les formats existants en termes de BD Navigable et proposer des évolutions de
spécifications du réseau routier de la BD Topo pour aller vers la très grande échelle navigable.

2.2 Horizon temporel, jalonnement

La priorité est de valider une proposition qui réponde aux attentes de l’ANSC/NexSIS, au plus vite
(T2-2022). On propose ainsi le jalonnement suivant :

2.2.1 Une base nationale navigable exploitable dès septembre 2022

  • Amélioration des vitesses du réseau routier de la BD Topo (actions 1.1 et 1.2) afin de
    proposer des services de calcul d’itinéraire et d’isochrone valables pour NexSIS.
  • Confirmation que les informations relatives au sens unique sont de bonne qualité.
  • Co-validation avec NexSIS

2.2.2 Proposition d’un dispositif d’amélioration mi 2023

Les deux axes « dispositif collaboratif » et « vues immersives » seront explorées en parallèle d’ici fin
2022, en particulier en vue d’une décision de type « stop ou encore ».

L’intégration de la dimension collaborative dans le projet NexSIS sera particulièrement travaillée –
elle est déjà programmée.

2.2.3 Préparer l’avenir

Si l’urgence commande de s’appuyer sur l’existant BD Topo, il est assez clair que sa structure devra
évoluer. L’action 5.1 pourra être menée parallèlement aux autres travaux. On vise une étude pour fin
2022.

3 Récapitulatif des actions proposées

Axe Numéro Action Pilote Début / fin
Vitesse 1,1 Valider le nouvel algorithme de calcul des vitesses IGN - SPP En cours – fin au 30-04
1,2 Industrialiser le script IGN - SPP, avec SV3D et SDM 01-05-22 / 30-09- 22
Panneaux Restrictions 2,1 Intégrer une la dimension collaborative dans NexSIS, faciliter les contributions directes des SDIS. IGN / ANSC
2,2 Formuler une proposition de guichet voirie IGN/CEREMA En cours / 15-05 pour une 1ère proposition
2,3 Faire légiférer pour rendre obligatoire la contribution du gestionnaire IGN – faisabilité à étudier Long terme
2,4 Analyser l’existant en termes de vues immersives et son utilisabilité Fabrique ?
2,5 Monter une proposition de levé massif dans le cadre de NexSIS IGN-SPP / Fabrique En cours / 30-06- 22
2,6 Relancer DSR/DCA IGN - SPRI ?
POI 3,1 Assurer l’expression de besoin relative aux ERP auprès du GT CNIG IGN Prochaine réunion CNIG sur le sujet
3,2 Améliorer le moteur de recherche - Etudier les différences entre base de données (BD Topo) et moteur de recherche Géoportail IGN – SPP, avec pôle technique T2-2022
3,3 Echanger avec OSM France pour identifier des pistes de travail commun IGN - SPRI T2-2022
3,4 Monter un POC Geoportail/Geoplateforme (GPF) autour des POI OSM (outils de recherche/géocodage…) Action 3.5 : échanger avec OSM France pour identifier des pistes de travail commun IGN (pôle technique Géoportail ; projet GPF) S2-2022
3,5 Ré-instruire les conditions de réutilisation des données OSM IGN – mission juridique T2-2022
Trafic 4,1 Etudier l’intégration de l’information trafic au guichet voirie IGN/CEREMA T2/2022 pour un 1er cadrage du guichet qui, lui- même, aura des échéances plus lointaines
4,2 Assurer un benchmark de l’information disponible (téléphonie, automobile, programme Waze…) IGN S2-2022
Structure 5,1 Etudier les formats existants en termes de BD Navigable et IGN (and friends S2-2022
proposer des évolutions de spécifications du réseau routier de la BD Topo pour aller vers la très grande échelle navigable. #Geocommuns)
5 Likes

Merci pour la diffusion de cette note, qui permet d’engager au moins 2 réflexions : le devenir de la BD Topo en tant que BD navigable, et son adéquation avec le fait d’être le socle d’un commun. J’essaie d’aborder les 2 aspects ici.

Je ne vois rien d’identifié dans l’existant ni dans les pistes d’amélioration au sujet des manœuvres sur plus de 2 tronçons successifs. Ou alors c’est une question de vocabulaire et j’ai loupé un truc :slight_smile:

Je trouve la conclusion bien rapide (sans jeu de mot). Comment un tel script peut être satisfaisant en s’affranchissant des limites de vitesse constatées sur place ? On a potentiellement en sortie de script des vitesses supérieures aux vitesses légales si on se trouve dans une zone à vitesse réduite réglementairement par des panneaux (zone 30, passage à 70 en hameau au lieu de 90, etc)

Toutes ces propositions parlent de collaboratif, mais il s’agit surtout d’interactions entre acteurs institutionnels (SDIS, gestionnaires…). Pendant des décennies ces leviers ont été clé dans la collecte d’information, mais OSM a depuis quelques années suggéré qu’un autre collaboratif est possible, qui sollicite toutes les bonnes volontés, et pas que les institutionnels. Je trouve regrettable que le “crowdsourcing”, le collaboratif élargi à toutes et tous, ne soit pas évoqué ici parmi les pistes. Pour mémoire, ce levier est mentionné dans la convention IGN/OSM de 2019 comme axe de collaboration. Il ne devrait d’ailleurs pas se limiter au sujet des panneaux, celui des vitesses légales mérite d’être embarqué. On est sur des sujets de collecte vaste, où on a intérêt à réunir toutes les forces en présence, et pas que les acteurs pro.

Je pense que pour ne pas s’éparpiller le sujet des POIs ne devrait pas être inclus dans la réflexion sur la BD Routière. Chacun des sujets est suffisamment gros en soi pour ne pas combiner les 2 en un sujet “monstre”. Sinon on peut aussi y ajouter la BAN, et on aura un mega-commun hypertrophié :slight_smile:

Le couplage entre POIs OSM et géocodage a déjà fait l’objet de POCs autour d’addok notamment. Il y aurait moyen de ne pas partir de rien sur ce sujet.
Je ne sais pas ce que recouvre l’action 3.5, j’ai l’impression que cela traite de l’ODbL. A aborder dans un topic dédié ou dans une nouvelle section dédiée à un commun POIs ?

De même pour le trafic. La connaissance du trafic est un vrai plus pour proposer un choix de trajet pertinent en situation de guidage. Cependant ça reste un 2e niveau de service. Le 1er niveau doit être assumé par la BD routière elle même. Il sera toujours temps de parler d’OpenLR une fois la BD viable, mais, comme pour les POIs, ça me semble hors sujet pour l’instant d’inclure la réflexion sur le trafic dans le périmètre de notre discussion.

Si cette base alimente le calculateur OSRM du Geoportail, faut-il comprendre qu’il existe déjà une passerelle entre un format interne ou public de la BD Topo, et un format compris par le compilateur d’OSRM ?

Si urgence il y a, alors autant embrayer immédiatement avec le graphe OSM, dont le modèle de données est nativement compatible avec plusieurs calculateurs OpenSource. Le contenu est critiquable, notamment pour son exhaustivité. Il manque des voies, il manque pas mal de panneaux directionnels aussi, pour parler des lacunes principales, différentes de celles de la BD Topo. C’est le caractère immédiatement opérationnel d’OSM qui me fait pousser cette piste. On peut avoir un calculateur opérationnel avant le SOTM-Fr, et se faire une grosse session de travail à Nantes pour avancer :wink:

Plus largement, et toujours pour réagir à cette urgence, je ne vois pas comment elle est compatible avec des propositions d’amélioration qui arriveraient dans 1 an (“Proposition d’un dispositif d’amélioration mi 2023”), pour une mise en œuvre ultérieure. Je comprends la volonté de rendre la BD Topo navigable, mais ni la temporalité, ni la gouvernance, ni la licence ne me permettent d’imaginer qu’elle soit le socle d’un commun BD Routière à ce stade.

1 Like

Je serai fort intéressé par le descriptif du contenu de cette ancienne base afin de le comparer à ce qui est présent dans la BDTopo.

Qu’entends-t-on par “moindre priorité de mise à jour” ?
C’est une mise à jour plus décalée dans le temps ou plus mis à jour (en partie) ?
A-t-on une idée de la proportion de tronçons qui ne sont plus actuellement à jour ?

De quelles restrictions s’agit-il ici ?

  • Les limites de gabarits ? (hauteur, largeur, poids, etc)
  • Les restrictions du champ nature_de_la_restriction ? quasiment jamais renseignée (moins de 200 fois hors voies vertes sur 19M de tronçons).
  • Les restrictions sur les manoeuvres ? (interdiction de tourner, de faire demi-tour, etc… sans sens interdit en destination) qui me semble totalement absente et nécessitant une modélisation spécifique (lien entre 2 tronçons).

Toutes ces informations sont nécessaires pour obtenir un itinéraire en cohérence avec le terrain.

La vitesse moyenne calculée par ce script est de toute façon recalculée lors de la mise en graphe par les logiciels tels qu’OSRM. Le pré-calcul est donc peu utile.
Ce qui est utile dans le référentiel d’origine ce sont bien les limites légales de vitesse, absente actuellement de la BD Topo.

L’IGN ne devait pas travailler avec/pour le Ministère de l’Intérieur pour la constitution de la base des vitesses maximales autorisées (VMA) ?
Le précédent DG interrogé à ce sujet il y a quelques années (et peu avant le passage à 80 km/h) avait confirmé cela et parlait de quelques semaines pour son ouverture… peut-on en savoir plus vu que c’est complètement dans le sujet ? (cette base doit en principe être publiée durant ce second trimestre 2022).

Intégrer “dans NexSIS” ? Je doute que ce soit envisageable, ou alors dans une partie backend/géomatique servant à préparer les données, mais sûrement pas dans les outils de gestion des appels ou de gestion opérationnelle de NexSIS (SGA/SGO).

Un guichet de plus ? il existe, c’est OSM. :wink:

Contribution obligatoire… sous peine de ? Je ne crois plus du tout aux obligations réglementaire s’il n’y a pas de conséquences lorsqu’on ne contribue pas (il suffit par exemple de voir l’état de la base GéoDAE censée être alimentée obligatoirement par tous par les exploitants de défibrillateurs).
Cela suppose aussi un flux bien organisé pour ces contributions, à créer ou s’appuyer sur quelque chose de fonctionnel (OSM ?).

Comme Vincent… c’est un tout autre sujet. Qui trop embrasse mal étreint.

Oui, mais avec tout le monde autour de la table et pas en mode A parle à B qui parle à C… tout l’alphabet autour de la table.

Rappel du POC existant depuis plusieurs années de géocodage adresse (BANO) + POI (OSM) + intersections rues/routes (OSM): https://demo.addok.xyz/

Je l’ai mis en place justement pour montrer le potentiel pour les secours suite à différentes réunions GéoSDIS.

Le code d’extraction des POI pour addok est ici:

Réponse simple : respect de la licence ODbL + “community guidelines” d’OSM

Compléter d’une façon ou d’une autre une base de données en s’appuyant sur une base de données sous licence ODbL, implique que la base complétée soit publiée (uniquement) sous licence ODbL.

Je suis sûr que le service juridique de l’IGN a déjà répondu en interne à cette question.

C’est le cas, le code de conversion de la BDTopo à destination d’OSRM (ou pgRouting) a été publié ici:

Pareil, d’où la vision que j’ai exposé sur

… et qui n’a eu aucun écho en 2 semaines.

Le besoin de répondre à un certain type d’acteurs (les secours) est une chose.
Le besoin est toutefois plus général et cette feuille de route ne semble pas le prendre suffisamment en compte.

Je ne vois pas trop non plus l’articulation en terme de commun et de contribution, qui semble comme toujours très centrée sur les institutionnels, avec “réutilisation des données OSM”. C’est de mon point de vue un silo IGN qui est décrit, pas un commun où l’on fait converger les efforts de tous pour tous.

1 Like

merci à Mathieu pour le partage, à Frédéric pour la mise en forme et à Vincent et Christian pour leurs analyses, que je partage, notamment l’idée de ne pas inclure les POI et le trafic dans le périmètre du commun (ça ferait de beaux projets de commun par ailleurs), c’est vrai que le terme navigable fait penser à une app embarquée (disons waze) et aux besoins de guidage du conducteur, alors qu’un 1er objectif déjà est de pouvoir faire du calcul d’iti et des isochrones (personellement c’est ce qui m’intéresse), avant de faire vraiment du guidage.

2 Likes

Je ne comprends pas pourquoi envisager une collaboration avec des acteurs institutionnels est taxé de « silo IGN » ?

Le terme est peut être fort, au moins il aura fait réagir.

Ce qui est décrit est identique à ce qu’on connaît depuis des années et n’a pas grand chose de novateur sur lequel on pourrait mettre un coup de tampon “commun”.

N’est-ce pas justement pour aller au delà de ce mode de fonctionnement qu’on essaye d’ouvrir plus largement ?

“Ré-instruire les conditions de réutilisation des données OSM” ce n’est pas comme “ouvrir la contribution”

Je suis d’accord sur le fait qu’on pourrait faire des trucs plus ambitieux en matière de commun avec osm (ta proposition est intéressante à ce titre dans l’autre canal de discussion) mais clairement, il faut accepter aussi que des utilisateurs ne veulent pas de données en licence ODBL dans leur SI … (je développe pas, il y a un fil de discussion pour ça) Tiens d’ailleurs @matthieu.le-masson (ou s’il y a quelqu’un de l’ANSC dans le forum…) pour l’ANSC la licence ODbL c’est un sujet ou pas ? Pour quel utilisateur ou contributeur d’un commun navigable la licence serait-il un sujet ?

Bonjour,
P.I. : Amélioration des vitesses dans Road2 le moteur de calcul d’itinéraire développé par l’IGN utilisé par le service d’itinéraire et d’isochrone V2 du Géoportail.(GitHub - IGNF/road2_amelioration_des_vitesses: De l'amélioration du calcul de temps de trajet sur road2)
Cdt
youcef.hilem@laposte.fr

1 Like

En milieu urbain, si l’on ne tient pas compte de la présence de feux de signalisation, de stop, de cédez-le passage, de ralentisseurs, de passages piétons et de carrefours non protégés, on est bien loin de la réalité en terme de temps de parcourt et donc aussi de calcul du meilleur itinéraire (car tout cela a un impact sur l’itinéraire optimal).

Encore faut-il avoir ces données…

Dans OSM, en France, on dénombre environ:

  • 72 000 feux de signalisation
  • 1 million de passages piéton
  • 270 000 stop
  • 180 000 cédez le passage
  • 80 000 ralentisseurs
    ainsi que:
  • 66 000 interdictions de tourner ou autres restrictions…
  • 1 million de limites de vitesses (pas estimées, on fait des estimations à partir des limites)

Dans la BD Topo ?

Merci @yhilem de relancer le sujet, et merci @cquest pour les pistes d’amélioration, certes nombreuses.
Je profite des échanges pour signaler un petit démonstrateur/comparateur mis en place par l’IGN: Iti comparaison - JSFiddle, à utiliser de préférence sur l’IdF (avec encore 2-3 anomalies dedans, dont une mauvaise définition des “zones urbaines”). N’empêche qu’on voit aussi que les corrections prévues sur BD Topo sont une vraie “mise à niveau” (on partait de loin avec notre calcul d’iti pour voitures volantes, certes).

1 Like

Merci @matthieu.le-masson. Je viens de faire quelques tests sur le 92. Les temps de trajets de la BDTopo sont gravement sous-estimés (par 2 ou par 3). Ce sont des temps de trajet avec gyrophares et sirènes :grin: (je dis ca parce que j’ai parcouru le département sous ce mode là le WE donc sans la composante bouchons).

1 Like

Avec les ajustements en cours, on se rapproche d’une réalité, même si c’est une réalité “sans trafic”. Donc on est toujours seuls sur la route MAIS on respecte (à peu près) le code de la route (ce qui n’est clairement pas le cas du moteur “actuel”).

Bonjour,

J’ai balayé rapidement le sujet…je vous donne quelques infos sur les travaux “en cours” au D30 en lien avec la question.

Nous avons travaillé avec le service exploitation routière pour publier en OpenData les TMJA (Trafics Moyens Journaliers Annualisés). C’est une donnée souvent utilisée par les bureaux d’études pour les projets routiers mais je pense pas forcément pertinente pour la navigabilité :

  • la donnée est ponctuelle…les nombreuses ramifications du réseau font qu’il est difficile d’extrapoler ce qu’il se passe avant ou après le point de mesure
  • la donnée est annualisée…on pourrait peut-être faire du mensuel (et encore pas partout) mais pour être pertinent et mettre en lumière le trafic pendulaire il faudrait descendre à un pas de temps encore plus précis
  • une partie seulement du réseau est couverte
  • trafic important n’implique pas forcément congestion

La donnée est pour l’instant publiée dans un format “maison” sur OPenIG : https://ckan.openig.org/dataset/d30-tmja
J’envisage de faire une version conforme au schéma “comptage des mobilités”.

En parallèle, nous essayons de construire une base de données des dispositions de circulation permanentes. En gros, on essai de faire rentrer dans des cases les arrêtés de circulation qui définissent notamment les limitations de vitesse, tonnage, etc.

Le travail est fastidieux (certains actes datent de l’avant décentralisation) et complexe (il faut lire les différents articles et en comprendre le sens).
Afin de consolider la base, l’idée serait de croiser ce travail avec la présence de la signalisation correspondante sur le terrain. Pour cela, on s’appuierait sur les extractions Mapillary.

Ce deuxième travail serait probablement utile pour la constitution d’une base navigable…mais je ne saurais dire quand celui-ci sera suffisamment avancé pour être pertinent.

Cordialement,

2 Likes