Restriction de circulation sur du linéaire

johanricher commented 11 months ago

Contexte

Certains arrêtés portent sur des restrictions de circulations définies sur du linéaire de voirie : rue, route, avenue... et ce sur l'entièreté ou sur une section.

L'UI de DiaLog permet actuellement de créer et publier un arrêté avec une restriction définie sur une voie, mais expose des données au format Datex II qui ne comporte qu'un seul point pour localiser la voie en question, au lieu d'une ligne (Linestring dans la spec GeoJSON).

Sections

Une fois les problématiques liées au géocodage de voie entière gérées, on souhaitera implémenter la possibilité de définir la localisation d'une restriction sur une section.

Exemples de sections à gérer :

section entre 2 numéros d'une voie nommée #623
section d'une voie nommée X entre une intersection avec la voie nommée Y et une intersection avec la voie nommée Z
section entre 2 adresses situées sur 2 voies nommée différentes
section d'une voie entre une adresse et une intersection
etc.

La gestion exhaustive des sections impliquent donc de nombreuses problématiques et combinaisons liées au géocodage :

adresse (déjà géré grâce à la BAN / API Adresse)
intersection #419 (entre différentes voies, donc chaque type dans la BD TOPO nécessite un travail spécifique)
point de repère (cf. BD TOPO)
POI
etc.

Exploration

Critères d'acceptation

(Must have) Intégration de données avec des restrictions définies sur du linéaire.
(Must have) Les restrictions de circulation définies sur du linéaire sont servies par l'API Dialog en Datex II.
(Must have) Les restrictions de circulation définies sur du linéaire sont servies par l'API Dialog en CIFS.

Implémentation

Liste non-exhaustive :

[x] Evolution de notre modèle de données pour gérer le linéaire #523
[x] Comment traduire le linéaire dans l'export Datex II (LinearLocation) #512
[x] #536
[x] #571
[x] #623
[x] #667
[ ] #713
[x] #737
[x] #773
[x] #793

Le géocodage est indispensable pour le cas d'usage "création d'arrêté" mais pas pour certaines intégrations de données (celles dont les localisations sont déjà géocodées par exemple #502)

florimondmanca commented 10 months ago

GeoJSON

DATEX II n'inclut pas GeoJSON dans le location referencing https://docs.datex2.eu/location/index.html#location-reference

Pour l'instant on utilise le "linear referencing" cadré par la norme EN ISO 19148 https://docs.datex2.eu/location/4_LinearReferencing.html

Ce format permet aussi de définir une "line string", dans le sens "série de points", avec le type LinearElementByPoints

Dans notre export DATEX, il faudrait supprimer les noeuds loc:fromPoint et loc:toPoint, et remplacer le noeud <loc:linearElement type="LinearElement"> par <loc:linearElement type="LinearElementByPoints">, puis y définir les points.

L'inconvénient est que côté GPS, ce format nécessitera de parser les divers noeuds XML pour reconstituer du GeoJSON (si c'est ça qu'ils préfèrent), ils ne pourront pas "juste" ingérer du GeoJSON qui est un format plus "ubiquitous". Mais ça devrait fonctionner.

florimondmanca commented 10 months ago

Le géocodage n'est indispensable que pour le cas d'usage "création d'arrêté", pas pour le cas d'usage "intégration et diffusion de données vers les services de navigation"

Pour Eudonet il le serait quand même, car Eudonet ne fournit pas de linestring, contrairement à Bac-IDF. Donc en fait ça ne dépend pas que du cas d'usage, mais surtout de si le système avec lequel on s'intègre fournit déjà la linestring du segment de voie concerné.

florimondmanca commented 10 months ago

Export CIFS

CIFS attend une polyline qui est une série de coordonnées "X1 Y1 X2 Y2 ...". Dans tous les cas il faudra donc "convertir" vers ce format là, mais ça ne posera pas de problème pour autant qu'on stocke les points lat/lon eux-mêmes.

Ce qui m'amène à...

Evolution de notre modèle de données pour gérer le linéaire

Actuellement on ne stocke que fromPoint: geometry et toPoint: geometry

Le plus évident serait de stocker un array de points

On peut facilement passer de l'état actuel à ça en faisant points = [fromPoint, toPoint] (conceptuellement).

À partir de là on peut stocker une suite de points ("linéaire") provenant de divers formats (linestring geojson, ou autre) et qu'on pourra reformatter dans d'autres formats (linearElementByPoints, polyligne CIFS...).

Edit : j'ai créé un ticket pour tracker ça https://github.com/MTES-MCT/dialog/issues/523, je le mets dans la description

Re-EDIT : :bulb: En fait, il faut simplement stocker une geometry... PostGIS réalise déjà le polymorphisme des différents types de géométries à notre place. Une geometry peut contenir aussi bien un POINT qu'une LINESTRING ou encore un POLYGON ou encore une GEOMETRYCOLLECTION (assemblage de géométries). Il faut qu'on actionne pleinement les capacités de PostGIS en la matière.

florimondmanca commented 10 months ago

Une question technique à rajouter je pense : que faire des champs "numéro de début" et "numéro de fin" ?

Ils sont actuellement géocodés avec l'API Adresse. Mais l'un ou l'autre est rempli, alors on n'est plus sur "une voie complète", mais sur "une portion de voie", par exemple entre le début de la voie et le numéro X.

Comment "combiner" le linéaire de voie d'une part, et le fait qu'il faille n'en prendre qu'une partie (entre le numéro de début et numéro de fin) ?

En géocodant à la fois la voie complète (sujet de ce ticket), et en gardant le géocodage API Adresse des numéros de début et/ou de fin, on peut probablement faire un calcul PostGIS pour obtenir la fraction du linéaire comprise entre ces numéros, mais c'est à explorer.

Si c'est inclus à la solution de géocodage de linéaire de voie qu'on trouvera, tant mieux.

florimondmanca commented 10 months ago

Bon à savoir :

Si vous choisissez la norme CIFS V2, vous aurez accès à notre outil de validation qui vous permettra de tester votre flux avant de le mettre en ligne.

https://support.google.com/waze/partners/answer/10618039?hl=fr

On apprend aussi sur cette doc qu'on peut apparemment créer son "organisation" et soumettre un flux en toute autonomie.

johanricher commented 10 months ago

Eudonet ne fournit pas de linestring, contrairement à Bac-IDF.

Quelles sont les localisations fournies par Eudonet qu'on ne pourrait pas convertir en Linestring ?

Les localisations de restrictions qui sont seulement définies par un point de début et un point de fin (+ le libellé de la voie concernée) peuvent être converties en Linestring GeoJSON / polyline qui ne contient que 2 points. (et donc exportable de façon compatible avec Datex II et CIFS). Il me semble que c'est ce que tu dis par ailleurs mais il me manque peut-être un élément de compréhension sur les localisations dans les données Eudonet.

johanricher commented 10 months ago

Une question technique à rajouter je pense : que faire des champs "numéro de début" et "numéro de fin" présents dans l'UI DiaLog et actuellement géocodés avec l'API Adresse ?

C'est en réalité une façon très limitée de définir la localisation d'une restriction, et l'ajout des features qui reflètent la complexité de ces données (routes, intersections, zones, etc.) va nous pousser à redéfinir toute cette partie de l'UI/UX. Il s'agit d'avancer au fur et à mesure en ajoutant des choses sans casser les anciennes (idéalement en les fusionnant d'un point de vue UX). Donc pour l'instant on garde ces champs et le géocodage spécifique pour les points d'adresses.

johanricher commented 10 months ago

En géocodant à la fois la voie complète (sujet de ce ticket), et en gardant le géocodage API Adresse des numéros de début et/ou de fin, on peut probablement faire un calcul PostGIS pour obtenir la fraction du linéaire comprise entre ces numéros, mais c'est à explorer.

Ca me paraît pertinent mais en fait il faudrait se poser la question de comment les services de navigation gèrent la cohérence entre 1) les localisations qu'on fournit aux services de navigation (par exemple 2 points censés être situés sur une voie) et 2) le référentiel de voirie des services de navigation

Il est par exemple tout à fait possible qu'un point qui est pour nous situé sur une voie se situe à côté de cette voie dans le référentiel du service de navigation. Que se passe-t-il dans cette situation ? Est-ce que les services de navigation ne font pas de toute façon eux-mêmes le calcul dont tu parles pour un rapprochement / une mise en cohérence ?

Pour avancer sur le "géocodage de voie" qui est, je pense, quel que soit le scénario un must have de ce ticket, je propose d'explorer le service WFS vectoriel évoqué sur #515. Celui-ci permet, si je comprends bien, en requêtant le libellé d'une voie (présente dans la BD TOPO) d'avoir en réponse un objet, au format GeoJSON par exemple.

florimondmanca commented 10 months ago

Quelles sont les localisations fournies par Eudonet qu'on ne pourrait pas convertir en Linestring ?

Ce sont les localisations de type "La totalité de la voie" (ça concerne 13 localisations dans les 49 arrêtés intégrés le 26/10/2023).

Les voies n'ont qu'un seul point X/Y (comme la BAN) et ne sont pas représentées par un linéaire. Exemple :

Screenshot 2023-11-09 at 11-38-11 Eudonet XRM - GACS TEST

Donc Eudonet Paris est concerné par ce ticket car on ne récupèrera pas directement de linéaire des données Eudonet Paris. Autrement dit dans #533 on ne pourra traiter que le cas "section" avec un "Libellé adresse début" et "Libellé adresse fin". Le géocodage (obtention d'un linéaire) pour les localisations de type "la totalité de la voie" reste entier.

florimondmanca commented 10 months ago

je propose d'explorer le service WFS vectoriel évoqué sur https://github.com/MTES-MCT/dialog/issues/515

Oui je suis d'accord il faut qu'on explore les solutions techniques de récupération de linéaire et voir la donnée qu'on peut en retirer. On peut alors par exemple envoyer un linéaire d'exemple à Waze avec comme question "Est-ce qu'une polyligne de ce type serait exploitable pour vous ?".

Concernant Waze, ils demandent une polyligne et le nom de la voie et mettent en garde que le nom doit correspondre aux données de Waze (et incitent à utiliser leur géocodeur inverse pour cela). Autrement dit ils s'attendent à ce que le nom de voie fourni soit cohérent avec leurs données. Mais est-ce pareil pour la polyligne ? On est d'accord que c'est à voir.

florimondmanca commented 9 months ago

@johanricher

Je pense qu'il nous faudrait un ticket pour le sujet de recalage des numéros de maison sur le linéaire de voie ? Ce qu'on a appelé en off "section de voie" je crois

À moins qu'on ne revoit complètement cette UX des numéros de maison ? Je ne sais pas ce qu'on en disait.

johanricher commented 9 months ago

Oui mais le problème des "sections de voie" serait lui même à décliner en différents cas pratiques (section d'une voie nommée entre deux numéros, section d'une route entre deux communes, section d'une rue entre une intersection et un numéro, section d'une autoroute entre deux points de repère...) au fur et à mesure qu'on explore le sujet. La bonne façon de l'attaquer c'est de savoir ce que qu'on peut faire tout de suite (dans la continuité logique du travail en cours) et qui aura le plus d'effet (volume d'arrêtés diffusés dans les données DiaLog).

Afin de dessiner les contours de ce premier ticket, je propose de prendre comme point d'attaque les données Eudonet "potentiellement intégrables" : qu'est-ce qui correspondrait au problèmes des "sections de voies" ? Est-ce qu'il y a dans Eudonet des localisations géocodables en s'appuyant sur nos solutions actuelles (géoservice BD TOPO + API Adresse / BAN) et pour lesquelles on pourrait calculer des sections ? Pour l'instant j'ai du mal à répondre à cette question donc j'ai besoin de ta gouverne.

Par exemple si on a dans Eudonet des localisations définies comme "Du 8 au 16 de l'avenue de la République à Paris" : on pourrait géocoder les points d'adresses (API Adresse) et géocoder la voie nommé (BD TOPO), et avec les deux calculer une section.

Est-ce que présenter le problème de cette façon te paraît la bonne approche ? Est-ce qu'il y a des données Eudonet potentiellement intégrables de cette façon, et sinon comment ?

florimondmanca commented 9 months ago

Oui c'est ça, dans ma tête une "section" correspond à une portion de linéaire délimitée par des numéros de maison, au début ET/OU à la fin

Concrètement ça veut dire que dans le code qui calcule la géométrie au moment d'enregistrer une localisation, si des numéros de maison sont définis, on va prendre le linéaire de voie, et géocoder les adresses de maison, puis faire un calcul géométrique avec PostGIS (à concevoir) pour "tronquer" le linéaire.

Comme dans Eudonet Paris on traite des numéros de maison, ça peut être un bon cas d'usage pour "évaluer" l'effet mais le correctif ne sera pas spécifique à Eudonet Paris, il sera aussi effectif quand on saisit les infos via l'UI.

Pour illustrer le problème, voilà ce qu'on a actuellement en DB si on saisit "Rue de la concertation 75018 Paris" avec numéro de début = 3 et numéro de fin = 7.

On voit que les adresses ne tombent pas "sur" la rue, donc du point de vue des GPS ça sera un décalage qu'ils devraient traiter

Screenshot from 2023-12-13 12-21-13

(Pour visualiser aller sur https://geojson.io/#map=18.46/48.8962801/2.3567792 et entrer le GeoJSON suivant)

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "LineString",
        "crs": {
          "type": "name",
          "properties": {
            "name": "EPSG:2154"
          }
        },
        "coordinates": [
          [
            2.357665,
            48.896326
          ],
          [
            2.35732,
            48.896315
          ]
        ]
      }
    }
  ]
}

florimondmanca commented 9 months ago

La bonne façon de l'attaquer c'est de savoir ce que qu'on peut faire tout de suite

Le cas de "section" le plus proche est donc les numéros de maison sur des voies nommées.

On pourra le faire une fois le géocodage de linéaire de voie implémenté via #561

D'ailleurs je vois que ça apparaît déjà dans "Implémentation" de #536 (tu viens peut-être de l'ajouter ?)

Pour les routes et autres, on pourra implémenter une logique similaire pour tronquer entre des points de repère s'il se trouve que le géocodage de ces PR via la BD TOPO ne tombe pas "sur" la route.

johanricher commented 6 months ago

J'ai continué mon exploration de la BD TOPO avec un focus sur les tronçons de voie avec notamment comme application les problématiques de #623 mais aussi d'autres qui concernent plus généralement tous les linéaires de voirie BD TOPO.

TL;DR : je commence à comprendre à quoi servent les tronçons de route dans la BD TOPO. Je ne saisis pas encore bien tout l'intérêt de l'usage des tronçons au lieu des voies et leur raison d'être mais je pense que c'est nécessaire de l'explorer pour notre compréhension des données de la BD TOPO. Intro simple à retenir cependant (extraite de la doc) : "Une voie est un ensemble de tronçons de route associés à un même nom."

Différences par rapport aux routes dans la BD TOPO :

Les tronçons de route peuvent porter (valeur non obligatoire) des attributs "Identifiant voie BAN gauche" ou "Identifiant voie BAN droite" (pages 368 et 369). L'identifiant voie BAN est généré à partir de la clé d’interopérabilité d'une adresse de la BAN (par exemple si la clé d'interop d'une adresse dans la BAN est 02001_0056_00022_bis alors la voie dans la BD TOPO portera l'identifiant voie BAN 02001_0056).

Les tronçons de route portent (valeur obligatoire) un attribut "Sens de circulation" (page 343) : utile pour #528 ?.

D'autres différences potentiellement intéressantes à explorer.

Il me semble que les question à se poser sont :

Est-ce qu'on change nos implés pour pouvoir utiliser les nouvelles données (attributs) apportées par les tronçons de route ?
Quelles implications techniques et UX ?

Ca aurait des implications sur :

571 (travaux en cours)
623 (travaux en cours)

Et potentiellement d'autres ?

florimondmanca commented 6 months ago

Oui c'est intéressant de constater que les voies nommées n'ont pas vraiment d'identifiant intéropérable (il y a id_pseudo_fpb mais là où la BAN va contenir par ex 123456789, ce champ contiendra 123456789 sans le donc ça n'a pas l'air si fiable). Au contraire c'est la classe tronçon de route qui a clairement des champs "identifiants voie BAN".

Je suis d'accord que c'est à explorer. Il est possible qu'il vaille mieux changer pour utiliser la classe tronçon de route plutôt que voie nommée... Sachant qu'on peut en principe reconstituer une voie nommée en récupérant tous les tronçons de route avec le même "identifiant voie BAN". La doc BD TOPO dit d'ailleurs que c'est comme ça qu'est fabriquée la classe voie nommée.

Ca aurait des implications sur :

Ça aurait aussi des implications sur le géocodage de voie nommée (entière), qui existe déjà

MTES-MCT / dialog