Géocodage de route départementale

[johanricher]

Description

Voir #518 pour le contexte.

La documentation de la BD TOPO, référentiel sur lequel DiaLog s'appuie, donne la définition suivante à "route numérotée ou nommée" :

Voie de communication destinée aux automobiles, aux piétons, aux cycles ou aux animaux et possédant un numéro ou un nom particulier.

Il s'agit principalement des autoroutes et des routes nationales et départementale, mais aussi des voies communales, chemins ruraux...

Contrairement aux voies nommées (#536), elles ne sont pas "adressées". Ce qui signifie notamment qu'on ne peut pas les retrouver dans le référentiel de la base adresse nationale (BAN).

Implémentation

Dans ce ticket on implémente (backend et frontend) la possibilité de définir une restriction de circulation avec une localisation sur une "route numérotée ou nommée" (entendue au sens BD TOPO), avec comme périmètre les 3 premiers types (route départementale, route nationale et autoroute).

Backend

On utiliserait le même service "Géoplateforme de sélection WFS" que pour #536 avec la requête GetFeature :

• https://data.geopf.fr/wfs/ows
• Documentation API
• Documentation de la BD TOPO, section 12.10 "Route numérotée ou nommée" (page 298)

UI

Voir la maquette .

UX

En complément de la maquette, quelques conseils d'implé pour améliorer l'UX (pas des critères d'acceptation) :

• Pour le champ "Département ou gestionnaire" du type "Route départementale", l'UX souhaitée serait différente de celle pour le champ "Commune" des voies nommées entières, c'est à dire un menu déroulant avec de l'autocomplétion. Similaire à l'exemple suivant : Screencast from 2024-01-10 17-04-21.webm (Cet exemple est tiré de catalogue.data.gouv.fr et avait été implémenté par @florimondmanca)
• Même UX pour le champ "Numéro de la route"
• Pour peupler les valeurs de ces 2 champs, récupérer dynamiquement la liste des "gestionnaires" et des "numéros de route" depuis l'API
• Valider la valeur saisie dans chaque champ au moment de la saisie et afficher une erreur pertinente le cas échéant. Le champ suivant ne devrait pas pouvoir être utilisé si le champ précédent n'est pas valide (par exemple commune -> nom de la voie, je ne peux pas chercher une voie si une commune valide n'a pas été saisie). Actuellement un message d'erreur ne s'affiche qu'au moment où on clique sur "valider" et le message n'est pas compréhensible.

Le comportement serait similaire pour les 2 autres types de voies (route nationale et autoroute).

Suivi des PR

• 593

• 631

Critères d'acceptation

• (Must have) DiaLog doit pouvoir intégrer et créer des restrictions avec comme localisation une route départementale.
• (Must have) DiaLog doit pouvoir intégrer et créer des restrictions avec comme localisation une route nationale.
• (Must have) DiaLog doit pouvoir intégrer et créer des restrictions avec comme localisation une autroute.
• (Must have) Les localisations définies par une route numérotée ou nommée (3 types) doivent être associées à une géométrie linéaire (Linestring).
• (Must have) Export Datex II
• (Must have) Export DOCX
• (Must have) Export CIFS

Hors périmètre :

• Evolutions l'UX liées à #519 (potentiellement renommer "type de voie" en "type de localisation" pour inclure les communes entières et autre "zones")
• Sections / tronçons
• Inférer gestionnaire à partir du SIRET d'une orga (comme pour #575, et utiliser l'API

[MathieuFV]

J'ai fait un rapide explo de la couche "Voies numérotées ou nommées" :

On a un champ "Type de voie" qui peut avoir les types suivants (dans mon échantillon de données qui est choisi sur le département 02) :

• Route européenne
• Autoroute
• Nationale
• Départementale
• Route nommée
• Itinéraire cyclable
• Voie verte
• Autres

Quelques observations :

1. Il semble que ces types caractérisent les routes par fonction, ce qui fait qu'on les retrouve à peu près classées en fonction de leur profil en travers ou de leur gestionnaire. Ce qui n'est effectivement pas le plus pratique pour retrouver l'organisation qui a l'autorité sur la voie concernée.

2. Le type "Route européenne" est un regroupement d'autoroutes ou de nationales qui constituent des itinéraires d'intérêt européen, empruntés régulièrement je suppose par des véhicules en transit se rendant d'un pays à un autre en traversant la France. Ces routes européennes sont donc finalement un ensemble de routes du Réseau Routier National dont le gestionnaire est l'Etat ou les sociétés concessionnaires. On trouve des tronçons de routes qui sont à la fois catégorisées "Autoroute" et "Route européenne".

3. La table contient un champ "Toponyme" qui n'est renseignée que pour les types "Route nommée", "Voie verte" ou "Itinéraire cyclable" dans mon échantillon. Ce champ toponyme serait très probablement celui que les utilisateurs DiaLog utiliseraient s'ils souhaitaient les retrouver, mais au demeurant je ne sais même pas s'il existe des arrêtés de circulation qui touchent ces catégories de voies, et aucun besoin ne nous a été remonté à ce jour sur des voies vertes ou cyclable me semble-t-il.

4. Le type "Route nommée" est le plus difficile à comprendre, il semble couvrir une variété de voies qui vont de l'autoroute au sentier forestier. Dans mon échantillon la seule autoroute qui était comprise dans le type "Route nommée" était aussi représentée avec le type "Autoroute", donc on ne devrait pas avoir trop de pbs d'ambiguïté là-dessus. La lecture cartographique des voies typées "Route nommée" semble faire apparaître que ce type est beaucoup utilisé pour rattacher des sentiers forestiers (on voit une densité particulière de "Routes nommées" dans les forêts...). J'ai néanmoins pu trouver une route départementale qui était typée en "Route nommée" mais pas en "départementale" sans savoir pourquoi cette distinction existe, ce qui pourrait être problématique à l'usage. De manière générale le type "Route nommée" est utilisé pour de petites voiries pas forcément routières, donc peut être à exclure du champ des voies qui sont accessibles aux utilisateurs DiaLog.

Du reste, une fois qu'on a pu isoler par exemple une départementale, il est fort probable que nous ayons besoin de redécouper cette départementale sur le tronçon qui fait l'objet d'une réglementation. Et à cet effet nous aurions vraisemblablement besoin d'accéder aux points de repère "PR" et à l'abscisse qui correspond au début et à la fin de la section en question, chose qui n'apparaît pas dans cette table. A voir ce qui est possible en récupérant ces points de repère ailleurs, j'ai jeté un oeil à la table "Tronçon de route" mais ça m'a l'air compliqué...

[johanricher]

@Lealefoulon a démarré une exploration de ce sujet dont on a parlé aujourd'hui en réunion du jour :

On utiliserait le même service "Géoplateforme de sélection WFS" que pour #536 avec la requête GetFeature.

Pour démarrer : explorer les différents types de routes dont on pourrait avoir besoin pour DiaLog, ce que ça représenterait comme différentes requêtes, ce qu'on a besoin de passer comme paramètre et qu'on aurait besoin de récupérer comme info donnée par l'utilisateur dans l'UI (réfléchir en terme de parcours utilisateur complet).

Potentiellement pour la suite on devrait distinguer les différents types de route (type_de_route) à implémenter et problèmes à résoudre associés, en fonction des paramètres dont on a besoin de récupérer dans l'UI, par exemple :

• Route nationale (RN) :
  • à priori pas d'autre input nécessaire une fois ce type-là sélectionné dans l'UI
  • section de RN : entre 2 communes, entre point de repère, entre intersections... ?
• Route départementale (RD) :
  • dans l'UI l'utilisateur devra pouvoir sélectionner un département avant de choisir la RD par son numéro ; est-ce qu'on irait plus loin en préselectionnant le département en inférant à partir de l'organisation (idée similaire à #575)
  • section de RD : entre 2 communes, entre point de repère, entre intersections... ?
• etc.

Le cas échéant, chacun de ces points serait un ticket+PR avec un design et implémentation spécifique.

J'ai mis à jour la partie "Exploration" du ticket. A suivre à partir de lundi

[Lealefoulon]

• Après quelques recherches je me demande même s'il sera vraiment nécessaire de sélectionner les types nationales et autoroutes dans l'UI. Pour ces deux types il semble qu’en renseignant simplement son numéro correspondant dans la requête nous puissions récupérer la géométrie. Exemple pour la nationale N135 : https://data.geopf.fr/wfs/ows?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&OUTPUTFORMAT=application/json&TYPENAME=BDTOPO_V3:route_numerotee_ou_nommee&cql_filter=numero=%27N135%27

• Concernant les départementales il faut préciser les attributs numéro et gestionnaire disponibles dans la documentation p 298 https://geoservices.ign.fr/sites/default/files/2023-10/DC_BDTOPO_3-3.pdf pour obtenir la géométrie de la bonne départementale.

https://data.geopf.fr/wfs/ows?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&OUTPUTFORMAT=application/json&TYPENAME=BDTOPO_V3:route_numerotee_ou_nommee&cql_filter=numero=%27D951%27%20AND%20gestionnaire=%27Charente%27

En effet si l’on renseigne simplement le numéro on obtient un tableau avec plusieurs départementales portant le même numéro et des géométrie différentes pour chacune. Par exemple : Dans le cas de la D951 il y en aurait 17 dont une située à Poitiers dans la Vienne et une autre à Lussac (16450) en Charente par exemple.

Pour tester : https://data.geopf.fr/wfs/ows?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&OUTPUTFORMAT=application/json&TYPENAME=BDTOPO_V3:route_numerotee_ou_nommee&cql_filter=numero=%27D951%27

[johanricher]

Merci pour ces recherches !

je me demande même s'il sera vraiment nécessaire de sélectionner les types nationales et autoroutes dans l'UI.

A ce stade de l'exploration j'ai l'impression que les user inputs seront différents selons les types de voie (voies nommées, routes départementales, routes nationales, autoroutes, etc.), donc je ne vois pas d'autre solution que de demander le type de voie avant ces autres inputs.

Concernant les départementales il faut préciser les attributs numéro et gestionnaire disponible dans la documentation p 298

C'est cohérent puisque les routes départementales (et leur numéro) sont spécifiques à chaque département qui la gère (ainsi que d'autres cas spécifiques pour des territoires qui ne sont pas des départements comme la Collectivité européenne d'Alsace).

Donc, en tant qu'utilisateur, si je veux pouvoir définir une restriction sur une route départementale, le parcours serait le suivant :

• dans le bloc localisation
• je choisis d'abord le type "Route départementale"
• je sélectionne le "gestionnaire" dans une liste déroulante (menu de type HTML Select)
• je sélectionne le numéro dans une liste déroulante (menu de type HTML Select)

Par contre, pour les nationales et autoroutes, comme tu le soulignes, les numéros ne sont pas spécifiques à un territoire donc on n'a pas besoin de cet input. Ainsi, si je veux pouvoir définir une restriction sur une route nationale, le parcours serait le suivant :

• dans le bloc localisation
• je choisis d'abord le type "Route nationale"
• je sélectionne le numéro dans une liste déroulante (menu de type HTML Select)

Pareil pour autoroute.

[aureliebaton]

Merci pour les toutes ces infos ! Je n'ai pas encore eu le temps d'explorer ce sujet. Est-ce que cette issue devrait être déplacée à Exploration plutôt que Backlog ?

[MathieuFV]

Commentaire laissé en suspend après le daily d'hier, du coup peut être déjà traité... Je le laisse pour info!

En effet je suppose qu'on peut la déplacer dans Exploration. Côté design effectivement on aura des implications en fonction du type de route visée comme cela apparaît dans le commentaire de @johanricher.

A garder en tête qu'un utilisateur unique peut être amené à émettre de la réglementation sur des routes de différents types, car par exemple une commune a autorité sur les voies départementales qui sont situées dans son agglomération (comprendre dans ses limites administratives). Une question que je me pose cependant : Je crois que les voies départementales à l'intérieur des communes sont nommées, elles ont donc un libellé et des adresses, tandis que celles hors agglomération sont bien indexée par leur numéro et les points de repère. Mais tout ça est à confirmer...

[MathieuFV]

Ah et aussi cet article qui est intéressant, en lien avec le sujet : https://www.lemonde.fr/societe/article/2024/01/03/nos-lieux-dits-sont-la-memoire-de-nos-terres-des-milliers-de-villages-lances-dans-le-chantier-de-l-adressage-de-leurs-rues-sans-nom-ni-numero_6208807_3224.html?lmd_medium=al&lmd_campaign=envoye-par-appli&lmd_creation=ios&lmd_source=mail

[johanricher]

Mon compte-rendu du petit point UX lié à ce ticket mais aussi à #573 et #575 avec @aureliebaton @Lealefoulon, en se basant sur la maquette pour cette exploration.

Quelques détails d'implé pour le champ "Département ou gestionnaire" du type "Route départementale" :

• L'UX souhaitée serait différente de celle pour le champ "Commune" pour le géocodage des voies nommées entières, c'est à dire un menu déroulant avec de l'autocomplétion. Similaire à l'exemple suivant : Screencast from 2024-01-10 17-04-21.webm Cet exemple est tiré de catalogue.data.gouv.fr et avait été implémenté par @florimondmanca lui-même donc il saura sans doute comment le refaire. :)
• Même UX pour le champ "Numéro de la route"
• Pour peupler les valeurs de ces 2 champs, il faudrait idéalement récupérer dynamiquement la liste des gestionnaires et des numéros de route depuis l'API (afin d'éviter d'avoir cette liste en dur chez nous car les données peuvent évoluer dans l'API) : à vérifier si c'est faisable
• Il faudrait valider la valeur saisie dans chaque champ au moment de la saisie et afficher une erreur pertinente le cas échéant. Le champ suivant ne devrait pas pouvoir être utilisé si le champ précédent n'est pas valide (par exemple commune -> nom de la voie, je ne peux pas chercher une voie si une commune valide n'a pas été saisie). Actuellement un message d'erreur ne s'affiche qu'au moment où on clique sur "valider" et le message n'est pas compréhensible.

Le comportement serait similaire pour les autres types de voies (route nationale, autoroute...)

Hors scope mais évoqué comme évolutions d'UX sur les localisations (tickets à venir) :

• Faire évoluer l'UX à l'occasion de #519 (potentiellement renommer "type de voie" en "type de localisation" pour inclure les communes entières et autre "zones")
• Différentes implémentations de sections / tronçons qui auront des implications sur l'UX mais probablement de façon similaire à #573.
• Inférer gestionnaire à partir du SIRET d'une orga (comme pour #575, et utiliser l'API

@Lealefoulon je te laisse relire, compléter et/ou corriger afin qu'on puisse considérer ce ticket comme "prêt à développer".

[Lealefoulon]

Pour peupler les valeurs des champs : "Département ou gestionnaire" et "Numéro de départementale", on peut récupérer dynamiquement des numéros de route depuis l'API geopf service WFS.

• LISTE DES NUMÉROS DE DÉPARTEMENTALES GÉRÉES PAR LE GESTIONNAIRE DE L'AUDE PAR EXEMPLE : https://data.geopf.fr/wfs/ows?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&OUTPUTFORMAT=application/json&TYPENAME=BDTOPO_V3:route_numerotee_ou_nommee&cql_filter=gestionnaire=%27Aude%27&type_de_route=%27D%C3%A9partementale%27&PropertyName=numero

[johanricher]

Pour les routes départementales le paramètre d'input de la requête n'est pas une valeur dans la liste des départements mais dans la liste des gestionnaires, c'est celle-là qu'on veut récupérer dynamiquement (voir screenshot ci-dessus de la doc de la BD TOPO pour les routes départementales). Les deux listes ne sont pas complètement alignées ni équivalentes.

[Lealefoulon]

Dans la doc la définition de Gestionnaire est : "pour les routes départementales, il s’agit du gestionnaire départemental de la route au sens administratif (c’est-à- dire le nom du département)." Mais si je comprend bien les Métropoles ne ressortiraient pas avec la liste des départements par exemple.

[johanricher]

Dans la doc BD TOPO pour les routes départementales la liste des "valeurs du champ « Gestionnaire » associées" est la suivante :

Ain | Aisne | Allier | Alpes-de-Haute-Provence | Alpes-Maritimes | Ardèche | Ardennes | Ariège | Aube | Aude | Aveyron | Bas-Rhin | Bouches-du-Rhône | Calvados | Cantal | Charente | Charente-Maritime | Cher | Collectivité de Corse | Collectivité européenne d'Alsace | Collectivité territoriale de Martinique | Corrèze | Corse-du-Sud | Côte-d'Or | Côtes-d'Armor | Creuse | Deux-Sèvres | DIR Méditerranée | Dordogne | Doubs | Drôme | Essonne | Eure | Eure-et-Loir | Finistère | Gard | Gers | Gironde | Guadeloupe | Guyane | Haute-Corse | Haute-Garonne | Haute-Loire | Haute-Marne | Hautes-Alpes | Haute-Saône | Haute-Savoie | Hautes-Pyrénées | Haute-Vienne | Haut-Rhin | Hauts-de-Seine | Hérault | Ille-et-Vilaine | Indre | Indre-et-Loire | Isère | Jura | Landes | Loire | Loire-Atlantique | Loiret | Loir-et-Cher | Lot | Lot-et-Garonne | Lozère | Maine-et-Loire | Manche | Marne | Mayenne | Mayotte | Métropole de Lyon | Métropole Nice Côte d'Azur | Meurthe-et-Moselle | Meuse | Morbihan | Moselle | Nièvre | Nord | Oise | Orne | Paris | Pas-de-Calais | Puy-de-Dôme | Pyrénées-Atlantiques | Pyrénées-Orientales | Réunion | Rhône | Saône-et-Loire | Sarthe | Savoie | Seine-et-Marne | Seine-Maritime | Seine-Saint-Denis | Somme | Tarn | Tarn-et-Garonne | Territoire de Belfort | Val-de-Marne | Val-d'Oise | Var | Vaucluse | Vendée | Vienne | Ville de Paris | Vosges | Yonne | Yvelines

C'est cette liste dont on souhaiterait savoir si on peut la récupérer dynamiquement pour la saisie du champ "Gestionnaire" avec autocomplétion. Cette liste peut potentiellement évoluer dans l'API IGN donc ça serait mieux de ne pas l'enregistrer en dur chez nous.

Au sens du COG (qui fait référence), certaines de ces valeurs ne sont pas des départements ("Paris", "Collectivité européenne d'Alsace", "Métropole de Lyon", "DIR Méditerranée"...), en revanche tous les départements semblent y être mais parfois avec des noms différents du COG ("Collectivité territoriale de Martinique" au lieu de "Martinique").

[florimondmanca]

@Lealefoulon Concernant "l'exemple d'UX catalogue.data.gouv.fr" avec le champ de "couverture géographique"

Effectivement il y a une différence qui est que dès qu'on clique dans le champ, la liste entière apparaît. C'est comme quand on clique sur un <select>, sauf qu'ici c'est un input de recherche avec une liste en-dessous.

À l'inverse sur le champ "Commune" c'est de l'autocomplétion comme le fait <datalist> : rien n'apparaît initialement et ce n'est que lorsqu'on commence à taper que des requêtes d'API vont récupérer les suggestions API Adresse.

Mais le champ "couverture géographique" avait aussi un comportement d'autocomplétion : quand on tapait quelque chose, la liste montrée était "affinée" pour ne garder que ce qui "matchait".

Cette autocomplétion était "custom", codée en JS avec Svelte (Svelte est une sorte de langage par-dessus JS) : https://github.com/etalab/catalogage-donnees/blob/c4fb550d6b0da0f11e64553cf843c2d362bdf8c3/client/src/lib/components/DatasetForm/_GeographicalCoverageField.svelte#L4

À ma connaissance il n'y a pas de solution incluse dans HTML pour cet entre-deux entre un select (qui ne permet pas de rechercher) et une datalist (qui ne montre rien initialement), malheureusement...

Je suis d'accord qu'afficher toute la liste des gestionnaires pour faciliter une sélection rapide "visuellement" sans avoir à taper, c'est sympa. Mais ça veut dire qu'il faudra faire une implémentation "custom" comme sur catalogue.data.gouv.fr. En étant mieux sur l'accessibilité que ce qu'on avait fait à l'époque, si possible...

Dispo pour en parler!

[johanricher]

À ma connaissance il n'y a pas de solution incluse dans HTML (...) ça veut dire qu'il faudra faire une implémentation "custom"

A mon sens ça vaut le coup quand ça améliore l'UX significativement (comme c'est le cas ici je crois). Je prends aussi en compte la logique RGESN dans cette réflexion.

En étant mieux sur l'accessibilité que ce qu'on avait fait à l'époque, si possible...

Il me semble que Bertrand avait repassé une couche là-dessus après la première implé, pour améliorer l'accessibilité.

Edit : pour préciser à la fois ma réflexion et les critères d'acceptation et périmètre de ce ticket :

Je propose que, si cette implémentation custom est jugée trop complexe, elle ne soit pas considérée comme un "must have" de ce ticket. L'implémentation minimale (pour les champs "gestionnaire" et "numéro de route") serait à choisir entre :

• un menu select, qui permet de choisir une valeur parmi une liste complète (sans autocomplétion)
• un champ de recherche plein texte avec autocomplétion, qui permet de chercher et choisir une valeur, mais sans pouvoir scroller dans la liste complète des valeurs (comportement similaire à celui du champ "Commune")

L'implémentation la plus simple devrait à mon sens être choisie, de façon à ce qu'on puisse itérer dessus par la suite mais sans que ce sujet ne soit bloquant pour avancer.

[florimondmanca]

@johanricher Ce matin on a réalisé avec @johanricher qu'avec un <select> avec la liste complète, on a aussi une forme de recherche. Par défaut si tu cliques sur le <select> et que tu commences à taper, les navigateurs (en tout cas Firefox) te déplacent vers l'option la plus proche.

On se dit par ailleurs que l'affichage de la liste complète est important car les agents vont en général "savoir d'avance" qui est le gestionnaire de telle ou telle RD. Comme la liste est triée on peut donc aussi aisément trouver le gestionnaire qui nous intéresse ("Nord", "Ville de Paris", etc).

Donc pour l'instant on proposerait de partir sur un <select> (la 1ère approche d'implé minimale que tu cites)

[johanricher]

Pour moi un select c'est ça : https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select

Sous Firefox ça donne ça :

https://github.com/MTES-MCT/dialog/assets/10212787/eb4a23f1-e3f7-4fa8-aaa0-c5af2f7ff71c

Pour moi ce n'est pas le comportement souhaité et que tu décris (je ne peux pas faire une recherche en tapant du texte). Exemple de problème UX que ça poserait :

Je cherche "Corse" mais dans la liste c'est "Collectivité de Corse" donc dans une liste rangée par ordre alphabétique je ne le trouve pas à l'endroit où je cherche.

Si une implé meilleure que ça est jugée trop complexe dans le contexte de ce ticket, ça me va si on commence par un select car ça fonctionne, malgré les inconvénients (notamment l'exemple que je pointe ici)

[florimondmanca]

Oui la "recherche" sur un select natif est naïve, c'est juste par "quelle option commence par ce que l'utilisateur a tapé"

[Lealefoulon]

Suite à notre échange ce matin @MathieuFV et @aureliebaton j'ai changé la liste de Gestionnaires pour ne mettre que celle associée aux départementales. Ça a l'air de correspondre bien à ce qu'avait mis Johan en commentaire plus haut. Ain | Aisne | Allier | Alpes-de-Haute-Provence | Alpes- Maritimes | Ardèche | Ardennes | Ariège | Aube | Aude | Aveyron | Bas-Rhin | Bouches-du-Rhône | Calvados | Cantal | Charente | Charente-Maritime | Cher | Collectivité de Corse | Collectivité européenne d'Alsace | Collectivité territoriale de Martinique | Corrèze | Corse-du-Sud | Côte-d'Or | Côtes-d'Armor | Creuse | Deux-Sèvres | DIR Méditerranée | Dordogne | Doubs | Drôme | Essonne | Eure | Eure-et-Loir | Finistère | Gard | Gers | Gironde | Guadeloupe | Guyane | Haute-Corse | Haute-Garonne | Haute-Loire | Haute-Marne | Hautes-Alpes | Haute- Saône | Haute-Savoie | Hautes-Pyrénées | Haute-Vienne | Haut-Rhin | Hauts-de-Seine | Hérault | Ille-et-Vilaine | Indre | Indre-et-Loire | Isère | Jura | Landes | Loire | Loire-Atlantique | Loiret | Loir-et-Cher | Lot | Lot-et-Garonne | Lozère | Maine-et-Loire | Manche | Marne | Mayenne | Mayotte | Métropole de Lyon | Métropole Nice Côte d'Azur | Meurthe-et-Moselle | Meuse | Morbihan | Moselle | Nièvre | Nord | Oise | Orne | Paris | Pas-de-Calais | Puy-de- Dôme | Pyrénées-Atlantiques | Pyrénées-Orientales | Réunion | Rhône | Saône-et-Loire | Sarthe | Savoie | Seine- et-Marne | Seine-Maritime | Seine-Saint-Denis | Somme | Tarn | Tarn-et-Garonne | Territoire de Belfort | Val-de- Marne | Val-d'Oise | Var | Vaucluse | Vendée | Vienne | Ville de Paris | Vosges | Yonne | Yvelines

[florimondmanca]

J'imagine qu'on peut clore ce ticket maintenant que #631 a été mis en prod ?

La partie PK/PR est trackée via un autre ticket #667

[johanricher]

Il y aurait les autres types de "route numérotée ou nommée" listés par Mathieu et en particulier les nationales et les autoroutes dont on avait parlé précédemment mais je propose en effet de renommer et cloturer ce ticket pour ouvrir #686 et #687, et plus tard éventuellement d'autres si le besoin se présente à un moment.

[johanricher]

Les exports Datex et CIFS restent à implémenter.

[florimondmanca]

Les exports ont été mis à jour par #689

Voir D908 ici https://dialog.incubateur.net/api/regulations.xml

(Pour le CIFS on ne peut pas le voir si staging car il n'y a pas de départementale en arrêté temporaire publié)