Permettre aux utilisateurs de renseigner les PR + Abscisse de début et de fin d'un tronçon

MathieuFV commented 5 months ago

Contexte

Les utilisateurs des conseils départementaux et les services de l'Etat chargés de gérer le réseau routier national utilisent les points de repère ("PR") pour se repérer sur leurs réseaux.

Exemple :

(extrait de cet arrêté)

Pour mieux comprendre le sujet, voir la carte des PR sur le Géoportail

Le PR correspond en règle générale à un objet physique : la borne kilométrique (jaune pour les départementales et rouge pour les nationales). Les PR sont donc généralement espacés d'à peu près 1 kilomètre et subdivisent ainsi une route en segments de cette taille.

En règle générale, les gestionnaires ont besoin d'être plus précis que ça pour définir le début et la fin des tronçons qui sont concernés par une règlementation. Si mes travaux commencent au milieu entre deux PR, j'utilise alors en complément les "abscisses". L'abscisse correspond à une distance en mètre à partir du PR précédent où commence le tronçon que je souhaite définir, ainsi :

"D125 au PR 2 + 650" veut dire "La départementale n°125, au PR n°2 plus 650 mètres"

PR2

A noter : on a vu aussi qu'il y avait une notion de côté. Normalement par convention le côté droit ou "D" est celui dans le sens duquel les PR vont croissant, et le côté gauche ou "G" celui dans le sens duquel les PR vont décroissant. Quand le côté est noté "U" c'est pour une route bidirectionnelle (une seule chaussée pour les deux sens de circulation).

@Lealefoulon travaille en ce moment sur le géocodage de routes (voir issue #571 et PR #631 notamment) ce qui permettra à un utilisateur de localiser une mesure sur une route départementale ou nationale. A la suite de ces travaux, nous disposeront de la géométrie de la route en entier dans les données DiaLog, et nous voudrions donc pouvoir redécouper cette géométrie entre les PR+abscisses de début et de fin renseignés par les utilisateurs.

Critères d'acceptation

[ ] (Must have) L'utilisateur peut renseigner les PR+abs de début et de fin du tronçon dans la partie "localisation" du formulaire
[ ] (Must have) L'utilisateur peut spécifier : le numéro de la PR, l'abscisse et le côté de la route concerné
[ ] (Must have) La géométrie stockée dans les données correspond au tronçon entre le PR+abs de début et celui de fin renseignés
[ ] (Must have) Export DOCX
[ ] (Must have) Export Datex II
[ ] (Must have) Export CIFS

Design

Maquette

Implémentation

On pourra faire usage de l'API de l'IGN pour géocoder les PR+Abs recueillis par le formulaire. Pour l'instant des instances de démo de cette API sont accessibles :

Là pour le géocodage direct (je rentre département, route, PR, (abscisse), je repars avec un XY – la saisie est guidée par des listes) : https://demo-dscr.ign.fr/demonstration/geocode/
Ici pour le géocodage inverse (je rentre/clique un XY, je repars avec des propositions de PR+abscisse correspondantes, avec un score associé) : https://demo-dscr.ign.fr/demonstration/reverseGeocode/
[ ] Migration de données
[ ] Interface d'édition
[ ] Affichage dans l'interface
[ ] Export DATEX II
[ ] Export Word

PR :

693

Contexte supplémentaire

johanricher commented 5 months ago

Les points de repères sont des objets présents dans la BD TOPO et le service Géoplateforme de sélection WFS (celui qu'on utilise déjà pour #571). A noter que la doc BD TOPO (page 293) définit ces objets de façon plus complexe que dans l'implé démo que tu cites donc je ne suis pas sûr que celle-ci soit complète / pérenne (par exemple la valeur "Ordre du PR le long de la route à laquelle il est associé" est obligatoire).

Pour le cas d'usage création d'arrêtés : l'idée serait de faire une implémentation des points de repères permettant de définir les début et fins de restriction pour certaines voies (lesquelles ?), de façon similaire aux numéros de rues pour les voies nommées. En pratique cela sera sans doute plus complexe.

Pour le cas d'usage intégration d'arrêtés : vu l'exemple que tu donnes, je ne suis pas sûr qu'on parvienne à automatiser de façon massive l'intégration de tels arrêtés. La façon dont les localisations sont écrites rend leur interprétation par une machine très complexe, et ce même si on met en place un géocodage point de repère + absisse -> coordonnées géo.

Afin de prioriser ce chantier il faudrait une phase bizdev pour répondre aux questions suivantes :

Cas d'usage création d'arrêtés : quelles organisations n'utiliseraient DiaLog qu'à la condition que l'UI gère ce cas d'usage ?
Cas d'usage intégration d'arrêtés : quelles sources de données contiendraient des localisations définies de telles façons ?

florimondmanca commented 5 months ago

une implémentation des points de repères permettant de définir les début et fins de restriction pour certaines voies (lesquelles ?)

Actuellement ça serait pour les routes départementales ? Seul cas où il y a une notion de PR sur lequel on travaille dans le cadre de #571

MathieuFV commented 5 months ago

Oui j'ai plutôt donné des exemples sur les départementales puisque ça me semble être dans la continuité de ce que fait Léa sur #571, mais bien entendu (et ça se confirme en regardant comment fonctionne l'API IGN), ces développement fonctionneraient sur les réseaux départementaux et nationaux (on a aussi les PR sur les nationales et autoroutes concédées).

MathieuFV commented 5 months ago

Afin de prioriser ce chantier il faudrait une phase bizdev pour répondre aux questions suivantes :

Cas d'usage création d'arrêtés : quelles organisations n'utiliseraient DiaLog qu'à la condition que l'UI gère ce cas d'usage ?

Cas d'usage intégration d'arrêtés : quelles sources de données contiendraient des localisations définies de telles façons ?

En effet ! Pour mémoire j'avais eu des échanges avec un certain nombre de conseils départementaux sur DiaLog, avec des résultats assez variés d'un territoire à l'autre.

Notamment en Corrèze ils disposent de données DATEX qu'on peut même consulter avec ces accès :

https://extranet.inforoute19.com/datex identifiant : !!MODÉRÉ!! mot de passe : !!MODÉRÉ!!

Je vous suggére de vous limiter à la racine de l'URL : https://extranet.inforoute19.com/datex/

Il avait aussi fait part de DiaLog à des collègues d'autres Conseils Départementaux et avait fait le retour suivant ;

2 éléments à partager avec vous :

Nous avons eu une réunion avec plusieurs Conseillers Départementaux cette semaine. L'envoi des informations vers les acteurs comme Waze, TomTom et Here est critique. Est-ce que votre approche ne permettrait pas de simplifier cette remontée d'information ? En prolongement du point précédent, quel référentiel utilisez vous pour localiser une information ? Est-ce envisageable d'étendre les informations remontées aux manifestations culturelles et sportive impactant le domaine routier ? En conclusion de tous ces points, prévoyez vous une interface de saisie simplifiée et/ou la possibilité de récupérer un flux d'information ?

Autre exemple en Eure-et-Loire avec qui j'avais réalisé un entretien :

j’ai trouvé l’idée alléchante de pouvoir donner nos restrictions de tout type pour notre réseau départemental eurélien et cela puisse ensuite partagé avec les fournisseurs de GPS.

Dans l'Oise :

Le Département de l’Oise a entrepris une démarche particulière visant à mieux connaître et à tenter de maîtriser la circulation des poids-lourds sur ce territoire. Nos services ont recensé et intégré à notre système d’information routier les arrêtés de restriction de la circulation des poids-lourds dont nous avions connaissance, quelle qu’en soit l’autorité signataire. Aussi, disposer d’un accès à votre outil et collaborer nous intéresse.

Pouvons-nous créer un compte ?

Sur le cas "intégration", je citerais en premiers lieux Inforoute qui concentre vraisemblablement des données au format DATEX II (je crois), ici l'exemple du (magnifique) Finistère :) https://www.inforoute29.fr/

Je pense donc que l'ajout de la gestion des PR+abs serait une opportunité de déploiement intéressante, ça permettra à tout le moins de redonner signe aux conseils départementaux cités plus haut (il y en a d'autres dans ma liste de contact qui s'étaient manifestés). Pour ce qui est de l'intégration il faudrait jeter un œil aux données Inforoute, je crois que c'est du DATEX II (on peut le voir en se connectant au point d'accès fourni par mon contact en Corrèze plus haut). Inforoute est intéressant mais ce n'est peut être pas la seule source de données, c'est en tout cas la seule que je connaisse à ce stade.

florimondmanca commented 5 months ago

@MathieuFV J'ai supprimé les identifiants de ton message, il vaut mieux les partager en privé je pense

MathieuFV commented 5 months ago

Désolé je continue de faire cette erreur... merci!

johanricher commented 5 months ago

Inforoute concentre vraisemblablement des données au format DATEX

Je découvre Inforoute ! :exploding_head: Donc un acteur privé qui si je comprends bien aide les départements à produire et diffuser de "l'information routière", qui se traduit notamment en Datex II.

Plutôt que de partir du présupposé que les départements veulent produire cette information routière avec DiaLog, pourquoi ne pas les laisser continuer ce qu'elles font déjà et leur rendre service avec DiaLog en intégrant leurs données telles quelles pour les diffuser aux services de navigation (Waze et autres) ?

Comment sont produites les données ? Inforoute fournit un logiciel ?

Quel rôle joue Bison futé / la DGITM là-dedans ?

MathieuFV commented 5 months ago

J'ai reçu ça aujourd'hui de la Préfecture de Police donc je ne pouvais pas ne pas le mettre 😄

MathieuFV commented 5 months ago

@johanricher j'ai essayé de contacter inforoute mais pas eu de réponse jusqu'à présent.

A savoir que, comme l'a montré le département de la Corrèze, les données inforoute ont l'air de remonter au ministère pour être intégrées au système "TIPI" qui collecte des données de situation sur le réseau routier national et les réseaux départementaux qui ont de la donnée.

Je dis bien qui ont de la donnée car, comme d'habitude, inforoute n'est pas présent partout. Il y a des départements qui payent pour avoir ce dispositif et d'autres qui ne l'ont pas (on peut voir la carte sur leur site "France").

Évidemment on aimerait récupérer les flux DATEX des départements qui ont inforoute, tout en permettant aux autres de saisir des données, je suppose.

MathieuFV commented 5 months ago

Autre besoin que je signale par rapport à ce ticket : Je suis sollicité pour fournir des données sur les voies réservées dédiées aux accrédités des Jeux Olympiques (https://www.francebleu.fr/infos/societe/jo-paris-2024-la-carte-des-185-kilometres-de-voies-olympiques-en-ile-de-france-6737225).

Ce ticket permettrait de réaliser la numérisation de ces voies dans DiaLog, avec des perspectives intéressantes de collaboration avec les GPS (TomTom notamment) par la suite.

johanricher commented 5 months ago

Ce ticket permettrait de réaliser la numérisation de ces voies dans DiaLog,

Etant donné que les voies ont déjà été numérisées pour la carto Anticiper les jeux qui me semble officielle et source de vérité, ne pourrait-on pas plutôt travailler à la récupération / intégration de ces données dans DiaLog ? (même logique que pour #520)

MathieuFV commented 5 months ago

Je pense qu'on doit pouvoir récupérer un shapefile, à voir s'il y a des données attributaires avec. Je demande ça à mes contacts et je vous tiens au courant.

florimondmanca commented 5 months ago

@mmarchois Pour la détermination du point correspondant à la donnée d'un PR et d'une abscisse,

Je pense que les fonctions PostGIS pertinentes sont dans la section 4.19 Linear Referencing, ici https://postgis.net/docs/reference.html#Linear_Referencing

Notamment ST_LineInterpolatePoint https://postgis.net/docs/ST_LineInterpolatePoint.html

Une façon de procéder pourrait être la suivante :

Obtenir la section de la route départementale entre le PR demandé et le suivant
- Si la table section_de_point_de_repere correspond à ça (une section entre deux PR), on peut passer par elle en utilisant le champ identifiant_de_section
- Sinon on peut requêter le PR suivant (+1) et faire un sectionnage de la géométrie de la route complète (ça serait le même genre de calcul que pour #669)
Calculer la longueur de ce tronçon (par ex 2400 m) (fonction ST_Length https://postgis.net/docs/ST_Length.html)
Calculer la fraction (entre 0 et 1) de l'abscisse demandée sur ce tronçon (par ex si l'abscisse demandée est 500 alors la fraction est 500 / 2400 = 0.20833...)
Obtenir le point de l'abscisse demandée avec ST_LineInterpolatePoint

johanricher commented 5 months ago

L'API de l'IGN (la même qu'on utilise pour les voies) ne fournit pas un géocodage type "PR" pour trouver un point (coordonnées géographiques) à partir d'un PR et de differents paramètres ? (abscisse, etc.)

mmarchois commented 5 months ago

@johanricher La BD TOPO en local nous donne accès aux point de repères et nous n'envisageons pas d'utiliser l'API de l'IGN (pour les problèmes de lenteur et fiabilité qu'on lui connait). Ça implique donc de le calculer nous-mêmes. Fausse bonne idée ?

mmarchois commented 5 months ago

@florimondmanca sans aller aussi loin dans le détail, c'est effectivement la solution vers laquelle j'envisageais de me diriger (je viens de découvrir section_de_point_de_repere, merci).

florimondmanca commented 5 months ago

L'API de l'IGN (la même qu'on utilise pour les voies)

La seule API de l'IGN qu'on ait utilisé est l'API WFS qui est essentiellement une interface HTTP pour requêter la BD TOPO

On pourrait donc y trouver tel ou tel PR, mais pour trouver le point correspondant à telle abscisse à partir de tel PR, il faudrait quand même faire ces calculs (mais avec les inconvénients de passer par l'API par rapport à la connexion directe)

johanricher commented 5 months ago

Ah oui faut que je change ma façon de penser pour passer à une logique local first. :)

Mais à priori ça change pas trop l'idée car l'API expose les données, avec des paramètres au lieu de tables et champs.

Ma préoccupation c'est qu'on fournisse à un utilisateur la bonne coordonnées correspondant à sa demande formulée en PR+abscisse. La BD TOPO faisant référence, il faut calculer le moins de choses nous-mêmes.

@MathieuFV Comment font les services dans les collectivités quand ils rédigent un arrêté pour trouver la bonne info de PR+abscisse à partir d'une coordonnées géographique ? (en gros l'exercice inverse au nôtre)

MathieuFV commented 5 months ago

Quand je travaillais à la gestion du réseau routier national on avait un outil de géocodage inverse qui te fournissait le X,Y d'un PR+abscisse.

Il faut bien comprendre que dans les conseils départementaux, dans les préfectures, dans les DREALs ou les DIRs la langue première c'est le PR+abscisse, les agents qui y travaillent connaissent leur réseau avec ce sectionnement et utilisent des cartes avec les PR+abs pour travailler, donc il est assez rare de trouver un cas dans lequel il faut retrouver un point GPS X,Y à partir d'un PR

florimondmanca commented 5 months ago

Ma préoccupation c'est qu'on fournisse à un utilisateur la bonne coordonnées correspondant à sa demande formulée en PR+abscisse. La BD TOPO faisant référence, il faut calculer le moins de choses nous-mêmes.

On est d'accord mais la BD TOPO ne contient que les PR, pas le continuum de points entre deux PR qui sont identifiés par leur abscisse

Par exemple, si l'utilisateur donne le PR 47, et l'abscisse 435, il faut bien interpoler pour trouver le point qui est à 435m le long de la route entre le PR 47 et le PR 48 (ce point spécifique-là n'est nulle part dans la BD TOPO qui ne contient que les PR)

On ne pourra pas échapper à ce calcul-là

johanricher commented 5 months ago

ce point spécifique-là n'est nulle part dans la BD TOPO qui ne contient que les PR

Ok, je comprends mieux. Dans ce cas, sait-on comment le service IGN effectue ce calcul "de référence" ? De même pour le géocodage inversé, il doit bien avoir une méthode sur laquelle tout le monde s'est mis d'accord. Sinon les écarts de résultats doivent être assez importants non ?

mmarchois commented 5 months ago

Si je comprends bien, voici ce que ça pourrait donner :

En prenant en considération l'exemple suivant : j'aimerais trouver sur la D100 des Haute-Saône (70), le PR 1+150. En base de données, il n'y a pas de correspondance pour cette abscisse :

 Num (PR) | Abscisse 
----------+----------
 PR0      |        0
 PR1      |      876
 PR2      |     1332
 PR3      |     2324
 ...      |     ...
PR34      |    33119

L'idée serait : 1 - Récupérer les PR1 et PR2 (le +1) 2 - Faire le calcul de la distance entre PR1 et PR2. On pourrait éviter d'utiliser la fonction ST_Length en faisant une simple soustraction entre les deux PR ? Les unités des abscisses étant en mètre, cela simplifierait le calcul 1332 - 876 = 456m 3 - En parallèle, récupérer le linéaire de la section : LINESTRING(xxx) 4 - Calcul de la fraction : 150 / 456 = 0,32 5 - Enfin, récupérer la géométrie de l'abscisse demandée : ST_LineInterpolatePoint(LINESTRING(xxx), 0.32)

Opération à mener pour le point A et B pour ensuite récupérer le linéaire.

À noter également qu'on ne peut utiliser la table section_de_points_de_repere. Il y a trop de cas d'identifiants de section remontés dans la table point_de_repere qui ne sont pas présents dans section_de_points_de_repere.

Réflexion supplémentaire : si PR1 + abs > PR2+abs 0, alors le calcul de la section doit être fait entre PR1 et PR3 ? Par exemple PR1 + 500 (1376m) > PR2+0 (1332m)

Une autre solution serait d'envisager de faire le calcul de la distance et de la section entre le premier PR (PR0) et le dernier PR (PR34) pour qu'il n'y ait pas le cas particulier décrit au-dessus. Qu'en penses-tu @florimondmanca ?

florimondmanca commented 5 months ago

En base de données, il n'y a pas de correspondance pour cette abscisse :

Non et d'ailleurs il n'y aura jamais de correspondance directe sauf si on ne saisit pas d'abscisse (donc abscisse 0 = le PR lui-même)

On pourrait éviter d'utiliser la fonction ST_Length en faisant une simple soustraction entre les deux PR ?

Oui carrément (peut-être juste faire des ST_Length en off pour vérifier que les diff d'abscisses sont bien égales à la longueur calculée par ST_Length ?)

Il y a trop de cas d'identifiants de section remontés dans la table point_de_repere qui ne sont pas présents dans section_de_points_de_repere.

C'est bizarre ça, non ? Ca veut dire qu'il y a des points de repères qui ont un identifiant de section associé, mais sans que la section existe ?

Réflexion supplémentaire : si PR1 + abs > PR2+abs 0, alors le calcul de la section doit être fait entre PR1 et PR3 ? Par exemple PR1 + 500 (1376m) > PR2+0 (1332m)

C'est vrai qu'il théoriquement que l'abscisse saisie par l'utilisateur soit bien entre 0 et la distance au PR suivant

@MathieuFV On est d'accord que quand on dit "Les collectivités travaillent avec PR+abscisse", là-dedans "abscisse" est une valeur relative au PR ? Ou bien c'est l'abscisse absolue qui est utilisée dans le métier ? (Par exemple 32119) (Ce qui serait + simple mais d'un autre côté rendrait inutile la référence à un PR donc je pense que c'est bien une abscisse relative)

Une autre solution serait d'envisager de faire le calcul de la distance et de la section entre le premier PR (PR0) et le dernier PR (PR34) pour qu'il n'y ait pas le cas particulier décrit au-dessus.

Je n'ai pas compris cette alternative. Si l'abscisse saisie par l'utilisateur est relative, on ne pourra pas s'épargner de calculer "à partir du PR demandé" ?

mmarchois commented 5 months ago

Je n'ai pas compris cette alternative. Si l'abscisse saisie par l'utilisateur est relative, on ne pourra pas s'épargner de calculer "à partir du PR demandé" ?

Cette alternative permettrait d'éviter de se soucier du cas PR1 + abs > PR2+abs 0 et donc devoir faire le calcul entre PR1 et PR3. L'idée serait du coup de faire le calcul directement entre PR1 et PR34 (entre le PR demandé par l'utilisateur et le dernier ).

C'est bizarre ça, non ? Ca veut dire qu'il y a des points de repères qui ont un identifiant de section associé, mais sans que la section existe ?

Oui, en tout cas dans ce que j'ai pu tester. La table section_de_points_de_repere contient 104.185 entrées, ce qui est peu par rapport au réseau routier national.

florimondmanca commented 5 months ago

L'idée serait du coup de faire le calcul directement entre PR1 et PR34 (entre le PR demandé par l'utilisateur et le dernier ).

Ah oui ok, je crois que j'ai compris. On prendrait donc toute la demie-route qui va du PR demandé jusqu'à la fin = le PR avec l'ordre maximum sur la route en question ?

Oui, en tout cas dans ce que j'ai pu tester. La table section_de_points_de_repere contient 104.185 entrées, ce qui est peu par rapport au réseau routier national.

Une requête semble le confirmer, il y a environ 10% de points de repère dont la section n'existe pas...

select count(*) from point_de_repere p
where p.identifiant_de_section is not null
and not exists (
  select 1
  from section_de_points_de_repere s
  where p.identifiant_de_section = s.identifiant_de_section
);

 count 
-------
 17303
(1 row)

On trouve ces cas pour une soixantaine de gestionnaires différents

Il y a aussi 514 PR dont l'identifiant de section est NULL (ce qui est déjà plus logique)

Ce qui n'est pas raccord avec la doc BD TOPO qui dit concernant identifiant_de_section : "Contrainte sur l'attribut : Valeur obligatoire"...

Cela dit, après qq visualisations sur geojson.io, quand tout est présent, les PR et le linéaire de section semblent concorder !

Mais par contre, une "section de point de repère" ne semble pas correspondre au linéaire entre un PR et le PR+1.

Par exemple j'ai la section 976-D7A-U-1 (située à Mayotte)

Le 1er PR est situé ici {"type":"Point","coordinates":[45.113759815,-12.832445123]}
Le suivant est ici {"type":"Point","coordinates":[45.111309274,-12.834171542]}

Or on voit que le linéaire de la section va bien au-delà de ce second PR

mmarchois commented 5 months ago

Après avoir échangé avec Matthieu le Masson (contact IGN), il nous déconseille de réinventer la roue et de partir sur l'API du démonstrateur (https://demo-dscr.ign.fr/api/). En soi, je suis d'accord avec lui, au plus on passera par des APIs externe qui feront ces traitements à notre place, au moins on aura de TMA et de dette technique sur DiaLog.

Maintenant, il s'agit d'une API qui a été conçu pour la Délégation à la Sécurité routière (DSR) et uniquement pour eux. Par ailleurs, la documentation API stipule :

Attention : Cette API est développée pour le compte de la Délégation à la Sécurité routière (DSR). Si vous n'êtes pas lié au projet, vous pouvez tester l'API mais n'êtes pas autorisé à l'exploiter en production.

Je l'ai donc recontacté à ce sujet pour savoir si nous pouvions l'utiliser en production. Il me dit que oui mais spécifie qu'il y a un risque : qu'ils atteignent les limites de charge et qu’ils ne servent pas bien ni la DSR, ni DiaLog.

Il précise également que, si notre conso est « raisonnable » (que veut dire raisonnable ?), on pouvait l'utiliser. Si notre conso est « forte », il faudra échanger avec lui pour voir les possibilités techniques.

Enfin, ils ont un plan de migration vers une solution plus robuste d'ici à la fin de l'année (et si nous confirmons l'intérêt pour cette API).

Qu'en pensez-vous ? Pour ma part, je suis assez partagé. D'un côté, déléguer ces calculs à un service tiers dont ce sera sa responsabilité me plait pour les raisons évoquées ci-dessus. D'un autre, le côté performance me fait assez peur. Le point positif, c'est qu'ils ont l'air assez réactifs et Mathieu Le Masson ouvre la porte à une collaboration.

florimondmanca commented 5 months ago

Ça confirme ce que je craignais, ça n'est pas pour l'heure un service déployé selon le principe qu'il puisse être utilisé par n'importe qui

Est-ce que tu as eu l'occasion de lui demander si le code source de cette API était dispo ? Ça serait une façon de "ne pas réinventer la roue" au sens de "réutiliser la connaissance", sans mettre de charge côté DSR.

florimondmanca commented 5 months ago

@MathieuFV Est-ce qu'on a d'autres exemples d'arrêtés sur départementales avec PR que celui dans la description de ce ticket ?

Notamment une question qu'on se pose avec @mmarchois, et qui a rapport avec ces histoires de "sections en seul morceau", c'est que font les collectivtés quand elles veulent réglementer la circulation sur une portion de la RD où se situe par exemple un rond-point ? Font-elles la distinction sur la portion avant et la portion après, et si oui à quels PR font-elles référence ?

Dans la BD TOPO il semble y avoir des points de repère de type "début de section" (DS) et "fin de section" (FS) au niveau des ronds points.

johanricher commented 5 months ago

On peut en trouver plein via Inforoute qui a pour clients des départements, par exemple le Tarn :

MathieuFV commented 5 months ago

@florimondmanca @johanricher

J'avoue que je ne connais pas tout à fait les pratiques des collectivités, mais de mes récents échanges avec la Préfecture de Police il semble que ça peut avoir son importance. Je vous remets la réponse de mon contact quand je lui ai transmis nos maquettes sur PR+abscisse :

Dans un premier temps, des captures d'écran que vous m'avez partagé, les deux propositions me semblent pertinentes. Par contre, est-ce que vous aurez des difficultés à implémenter les échangeurs et autres axes particuliers de ce type?

Ca semble indiquer que ces points particuliers ont leur importance. De manière générale les ronds-points/échangeurs/bretelles etc. sont des points particuliers du réseau, quand on se place du côté des gestionnaires de voirie il faut penser "repères visuels pour retrouver une portion de la route", ce qui me ferait dire que la réponse à ta question :

Font-elles la distinction sur la portion avant et la portion après, et si oui à quels PR font-elles référence ?

Est plutôt oui. Mais je vais regarder ce que je peux trouver parmi les arrêtés disponibles pour confirmer ça.

johanricher commented 4 months ago

Suite à notre discussion, on décide les améliorations UI / UX suivantes :

Titre : "Section où la mesure s'applique" (?)

Texte d'aide pour expliciter: "La restriction s'applique à toutes les voies de la chaussée." (?)

Renommer Point A : "Début", Point B : "Fin" (plus clair, explicite, et cohérent avec l'UX des sections définis par points d'adresse)

Champs "PR" et "Absisse" : libre, pas d'autocomplétion dans un premier temps (serait possibles techniquement mais pas trivial, et on anticipe des problèmes d'UX liées à la latence)

Champ "Côté" : menu déroulant qui présente toujours les 3 options, pour début et fin, avec les mêmes libellés que dans la doc BD TOPO :

Exemple de cas particulier possible dans la réalité : Une section d'une RD avec un point de début côté "U" et un point de fin côté "G" ou "D". On doit laisser la saisie possible, néanmoins comme actuellement on ne sait pas calculer la géométrie on doit renvoyer un message d'erreur le plus explicite possible.

johanricher commented 4 months ago

@aureliebaton On aurait besoin de ton avis sur ça et tes préconisations éventuelles pour appliquer au mieux ce qu'on a décidé, ou plutôt explicité, aujourd'hui. Les nouveaux textes (titre, phrase d'aide) sont notamment à préciser et à ajouter à la maquette.

aureliebaton commented 4 months ago

Merci pour toutes ces informations. J'ai mis la maquette à jour avec vos retours.

Nommage des points : Je me pose quand même la question du nommage des points (début et fin). Au départ j'avais proposé de faire quelque chose similaire à Waze avec plutôt Point A et Point B. Cela permet notamment lorsqu'on traitera de la direction sur les voies de spécifier : "Circulation interdite sur l'avenue du 14 juillet dans le sens B vers A" au lieu de dire "Circulation interdite sur l'avenue du 14 juillet dans le sens fin vers début". Un autre point est qu'il sera plus facile à spécifier sur la carto A et B que début et fin. Sauf si on considère qu'on définit différemment les points qui concernent les routes et ceux qui concernent les voies.

Message d'erreur après sélection non valide :

Exemple de cas particulier possible dans la réalité : Une section d'une RD avec un point de début côté "U" et un point de fin côté "G" ou "D". On doit laisser la saisie possible, néanmoins comme actuellement on ne sait pas calculer la géométrie on doit renvoyer un message d'erreur le plus explicite possible.

Je ne suis pas convaincue par cette solution, mais je suis consciente qu'il n'y a pas vraiment de "bonne solution" dans ce cas. Il n'est pas usuel de laisser sélectionner quelque chose qui ne sera pas possible/valide. Il me semblerait plus naturel de spécifier directement la limitation dans une description ou un warning avant et de griser le champ si ce n'est pas possible. Mais je suis prête à accepter la solution proposée en attendant si cela vous semble à tous plus pertinent.

Pour le message, pouvez-vous me résumer ce qu'il devrait contenir afin que je puisse le reformuler si nécessaire ?

MTES-MCT / dialog