search

MTES-MCT / dialog

Intégration de la réglementation de circulation dans les solutions numériques
https://dialog.beta.gouv.fr
GNU Affero General Public License v3.0
9 stars 0 forks source link

Intégrer les restrictions de circulation du 11 au 15 août en Seine-Saint-Denis #425

Closed johanricher closed 1 year ago

johanricher commented 1 year ago

Contexte

Du 12 au 14 août inclus, une partie de la branche nord du RER B sera exceptionnellement fermée dans le cadre de travaux réalisés par SNCF Réseau.

Plus de 600 bus de substitution sont mis en place, divisés en quatre lignes pour desservir toutes les gares fermées à cette occasion. et au moins 6 arrêtés de circulation et/ou de stationnement ont été pris, avec des restrictions du 11 au 15 août, pour assurer le fonctionnement de ce dispositif :

:information_source: Synthèse et explication des 6 arrêtés

Pendant trois à cinq jours la circulation dans la proche banlieue nord de Paris va donc être fortement impactée.

Certains éléments nécessaires à la création de tels arrêtés (par exemple la gestion des intersections #419) n'ont pas encore été implémentés dans l'application DiaLog. De même que les restrictions de stationnements, qui ne sont pas disposés par des arrêtés de circulation à proprement parler mais par des arrêtés de stationnement, et qui peuvent donc être considérés comme étant hors du strict périmètre actuel de DiaLog.

IDFM travaille avec les principaux fournisseurs de services de navigation (Waze, Tomtom, Here, Mappy, Google Maps, Apple Plans…) afin que les restrictions de circulation et de stationnements soient diffusés auprès des usagers de la route qui sont concernés.

Il s'agit d'intégrer les restrictions de circulation en question, voire celles de stationnements, dans les données publiées par DiaLog au format Datex II.

L'enjeu est de profiter de cette occasion pour faire la preuve de concept que DiaLog répond à ce cas d'usage et aux besoins des fournisseurs de service de navigation. Ce cas d'usage étant par ailleurs assez illustratif des problématiques similaires qui seront à gérer à plus grande échelle à l'occasion de Paris 2024

Critères d'acceptation

A vérifier avant le 11 août :

Exploration

Une exploration préalable à toute implémentation doit d'abord être menée.

Les arrêtés de circulation en question (donc hors stationnement) contiennent des éléments qui ne sont pas actuellement gérés par l'application DiaLog :

Questions

Concernant les arrêtés de circulation :

Concernant les arrêtés de stationnement :

Implémentation

florimondmanca commented 1 year ago

Ce qui manque pour une implémentation dans DiaLog

fermetures de voie

À quoi cela fait-il référence ?

D'après le pad explicatif, les mentions comme "circulation interdite sur la voie de droite" sont en fait à comprendre comme "circulation interdite sur la voie de droite dans les deux sens de circulation" (car "voie de droite" ou "voie de gauche" est relatif au sens de circulation)

Donc ça serait équivalent à "circulation interdite"

Y a-t-il des cas où seul un sens sens de circulation est interdit ? Je n'en ai pas vu.

A part la gestion des intersections et des fermetures de voie, quels sont les éléments qui ne sont pas encore implémentés dans DiaLog ?

Pour les autres arrêtés, hormis la gestion des intersections (qu'on devrait pouvoir traduire en N° de rue puisqu'on est en environnement urbain), et la notion de stationnement, je n'ai pas vu d'autre barrière à l'intégration directe dans DiaLog

Représentation DATEX II

Je n'ai pas vu de problème pour traduire les arrêtés dans DATEX II

Pour le stationnement, "neutralisation" veut bien dire en pratique "arrêt et stationnement interdit" ?

Si oui, au lieu d'utiliser ceci pour les restrictions de circulation :

        <typeOfRegulation xsi:type="AccessRestriction">
          <accessRestrictionType>noEntry</accessRestrictionType>
        </typeOfRegulation>

On devra utiliser :

        <typeOfRegulation xsi:type="StandingOrParkingRestriction">
          <standingOrParkingRestrictionType>standingAndParkingProhibited</standingOrParkingRestrictionType>
        </typeOfRegulation>

Pour le reste, la structure reste identique (définition des "conditions" où on peut mettre localisation et horaires, etc)

Notamment, les localisations peuvent aussi être représentées par une section de route (LinearElement) identifiée par 2 points GPS

johanricher commented 1 year ago

D'après le pad explicatif, les mentions comme "circulation interdite sur la voie de droite" sont en fait à comprendre comme "circulation interdite sur la voie de droite dans les deux sens de circulation" (car "voie de droite" ou "voie de gauche" est relatif au sens de circulation)

Donc ça serait équivalent à "circulation interdite"

Par "voie de droite" il faut comprendre "voie de droite dans les deux sens de circulation" sachant qu'en l'occurence (avenue du Stade de France à Saint-Denis) il y a deux voies dans les deux sens de circulation (2 x 2 voies).

Donc non la restriction de circulation n'est pas totale ("interdite") puisqu'il reste une voie (celle de gauche) dans les deux sens.

johanricher commented 1 year ago

on devrait pouvoir traduire les intersections en N° de rue puisqu'on est en environnement urbain

Malheureusement pas ici. Si on prend seulement l'arrêté ACT2023STD 619-MB de la mairie de Saint-Denis pour la voie qui est concernée, c'est à dire l'avenue du Stade de France :

Si l'on récapitule les implémentations qui manquent dans l'application DiaLog, en plus de :

il faudrait donc à minima ajouter (je vais créer les tickets) :

Il ne me paraît pas du tout réaliste d'arriver à implémenter tout ça dand DiaLog dans les délais pour ce cas d'usage.

Ce que tu proposes pour le stationnement me semble valide. Néanmoins sur le principe j'ai une réticence à l'élargissement du périmètre et de la raison d'être de DiaLog, à bande passante et budget égaux et alors que la preuve de concept du projet n'a pas encore été faite. De toute façon aucun des services de navigation ne saura intégrer ces données si on les a avant le 11/08 donc l'intérêt est proche de zéro pour ce cas d'usage.

Je n'ai pas vu de problème pour traduire les arrêtés dans DATEX II

Je pense qu'on doit donc partir sur une intégration en dur des dispositions contenues dans les 6 arrêtés (celles concernant la circulation) dans les données Datex II de DiaLog. Si on a le temps, on pourrait alors discuter en direct avec les services de navigation pour faire en sorte que ces données soient intégrées dans au moins un GPS (2ème objectif "must have" qu'on s'est fixé)

Est-ce tout ça te paraît ok @MathieuFV ? dispo pour une synchro à 3 si nécessaire avant de donner le feu vert à l'intégration.

florimondmanca commented 1 year ago

Je pense qu'on doit donc partir sur une intégration en dur des dispositions contenues dans les 6 arrêtés (celles concernant la circulation) dans les données Datex II de DiaLog.

J'aurais la même conclusion :+1:

MathieuFV commented 1 year ago

Ok pour moi pour nous concentrer uniquement sur la partie circulation. Ce qui est intéressant pour nous dans ce cas d'usage est de voir comment utiliser DATEX pour traduire des choses plus subtiles que ce qu'on gère déjà (la neutralisation de voie, les riverains), il y a un intérêt en déploiement car on envoie clairement le message qu'on travaille sur les interdictions tous véhicules et plus seulement poids lourds, et on a une chance (petite mais existante) de voir un GPS intégrer notre data ce qui contribue à nos objectifs de cette année.

Sur la question du stationnement c'est une toute autre discussion. Je suis d'accord avec toi @johanricher notre priorité est de faire notre preuve de concept, et les GPS n'intégreront de la donnée que concernant la circulation. D'un autre côté je crois intéressant de préparer l'implémentation future des restrictions de stationnement pour :

1° faire passer le message aux GPS que la donnée arrivera 2° boucler le cas d'usage "je renseigne mon arrêté complet (y/c le stationnement) dans DiaLog pour le sortir ensuite au format word" 3° donner accès à cette données aux collectivités pour qu'elles aient une base de travail sur la question du stationnement.

Ce sera intéressant pour déployer DiaLog en s'appuyant sur des dispositifs comme celui-ci qui se multiplient en ce moment.

J'avais prévu d'entamer la réflexion au sujet de l'implémentation du stationnement uniquement côté design avec Anne-Sophie cette semaine. L'idée étant d'avoir du stock en sujets explorés, pas de bouleverser la priorisation établie lors de notre dernier point d'équipe. En revanche, si les arrêtés du 14 août nous permettent d'avoir un quick win sur l'implémentation de la neutralisation de voie et du paramètre localresident je pense utile de le faire remonter dans notre liste, avec les autres modifications de ce type.

Dès que les données concernant les 6 arrêtés seront dans la base je renverrai un mail aux GPS pour leur notifier :)

Merci à tous les deux!

florimondmanca commented 1 year ago

Il me vient une réflexion suite à cette discussion sur le stationnement. C'est un peu hors sujet de ce ticket, mais...

Dans la perspective d'une collectivité qui utiliserait DiaLog comme outil principal pour créer des arrêtés... Comment créerait-elle des mesures que DiaLog ne supporte pas encore ? Actuellement cela se ferait directement dans le Word après export, on est d'accord ? Est-ce que nous garderons ce système à terme ?

Je crains que le 2° de @MathieuFV ("je renseigne mon arrêté complet"), à condition qu'il reflète fidèlement l'objectif qu'on se donne, ne puisse être complété dans DiaLog qu'avec une sorte d'option "Autre mesure". Peut-on anticiper tous les types de mesures utilisées sur le terrain ?

J'avais clos préventivement le ticket #215 avec ce message https://github.com/MTES-MCT/dialog/issues/215#issuecomment-1598889215, peut-être est-il utile de reprendre cette discussion-là.

johanricher commented 1 year ago

Pour moi la raison d'être de DiaLog, numériser la réglementation en matière de circulation, signifie fondamentalement traduire des arrêtés en données afin que la réglementation puisse être diffusé auprès des usagers grâce aux services de navigation (GPS).

Par conséquent, d'un point de vue stratégie et produit, tout ce qui ne sert pas cet objectif et qui fait de DiaLog un outil qui ne diffuse pas des données auprès des usagers via les GPS, revient à essayer de numériser des pratiques existantes et donc cloner Word, ce qui est à mon avis ni faisable ni prioritaire.

Actuellement cela se ferait directement dans le Word après export, on est d'accord ? Est-ce que nous garderons ce système à terme ?

Je pense qu'il est impossible de savoir ce que sera DiaLog "à terme", mais je pense que les utilisateurs auront toujours besoin de fonctionnalités de type "traitement de texte" pour tout ce qui n'a pas vocation à être traduit en données. Il me paraît plus réaliste et efficace de prendre en compte cette réalité, et en simplifiant (et sécurisant) le passage de DiaLog à Word sans essayer de remplacer Word.

MathieuFV commented 1 year ago

Un élément de réflexion à ce sujet : Nous avons fait le choix de nous fonder sur DATEX II pour diffuser les données réglementaires. Il se trouve que nous (le ministère) sommes représentés au sein des instances de gouvernance de DATEX II et d'autres formats de données européens (Napcore), et que nous pouvons être force de proposition dans ce cadre pour faire évoluer DATEX s'il nous semble judicieux de le faire. Il y a en ce moment en cours une révision de la directive européenne sur les Systèmes de Transport Intelligents (ITS) qui tendrait à rendre obligatoire l'ouverture de la réglementation de circulation en vigueur sur le réseau transeuropéen global (RTE-T) début 2025. Cela montre que le sujet de la réglementation va être de plus en plus présent à l'avenir dans les débats autour des échanges de données européens, les états membres y travaillent et vont faire évoluer le standard.

Tout ça pour dire que les limitations actuelles de DATEX, qui sont de facto des limitations de DiaLog sur les cas d'usage de réglementation pris en charge, sont elles aussi amenées à bouger. Une autre manière de faire évoluer DiaLog serait donc de coller au maximum aux cas d'usage qui sont permis par DATEX, en supposant qu'ils ont été bien étudiés en amont. Ce n'est pas trop notre genre, car on préfère heureusement interroger les besoins terrain avant d'agir, mais c'est techniquement possible.

Au delà de ça, je partage ce qu'a écrit Johan, mais je permets néanmoins d'insister sur l'importance de traiter le sujet du stationnement (autant que possible avec ce qui est dans DATEX), ne serait-ce que pour contribuer au déploiement de DiaLog.

florimondmanca commented 1 year ago

Concernant ce ticket et l'intégration des arrêtés de Seine-Saint-Denis, est-ce qu'il y a encore un obstacle à l'implémentation ? C'est-à-dire à leur traduction en DATEX (pour ce qui concerne la circulation) puis ajout "en dur" au flux DATEX.

johanricher commented 1 year ago

les limitations actuelles de DATEX, qui sont de facto des limitations de DiaLog sur les cas d'usage de réglementation pris en charge, sont elles aussi amenées à bouger

DiaLog évoluera en fonction des usages, du cadre normatif (dans lequel je mets Datex), etc. mais l'objectif restera d'aider le maximum d'usagers à se déplacer, en diffusant un maximum d'arrêtés de circulation via les GPS, non ?

Une autre manière de faire évoluer DiaLog serait donc de coller au maximum aux cas d'usage qui sont permis par DATEX

En l'état actuel de ma compréhension, les cas d'usage permis par Datex sont les seuls qui permettent de produire avec DiaLog des données diffusables dans les GPS, c'est à dire de tendre vers les objectifs fixés par nos indicateurs d'impact. De ce point de vue, c'est coller à autre chose que ces cas d'usage qui paraît difficilement justifiable.

johanricher commented 1 year ago

Concernant ce ticket et l'intégration des arrêtés de Seine-Saint-Denis, est-ce qu'il y a encore un obstacle à l'implémentation ? C'est-à-dire à leur traduction en DATEX (pour ce qui concerne la circulation) puis ajout "en dur" au flux DATEX.

Si l'on parle bien du premier critère d'acceptation, pour moi l'exploration est terminée et je mets donc en "Prêt à développer". :+1:

johanricher commented 1 year ago

Le 4 août toutes les restrictions de circulation disposées par les arrêtés en question ont été implémentées dans les données DiaLog exposées au format Datex II.

Différents fournisseurs de service de navigation (Waze, TomTom...) ont été informés.

Le 11 août, Waze nous a fait part des remarques suivantes :

We've tested the Dialog feed you provided in XML format: https://dialog.beta.gouv.fr/api/regulations.xml

Unfortunately, the feed can't be implemented as is. Below, is the feedback from our team:

  • id, description, start & end times: all OK
  • street: It seems that all streets are of structure: "Rue du Taur, 31000 Toulouse". We require the street name in a dedicated field, but as long as the structure is the same, we're good. I was able to split the street, but would like to confirm the consistency of structure.
  • type: All events hold and >accessRestrictionType>noEntry. These events have been mapped to road closures. Are there any other valid types, such as hazards, construction, or lane closures?
  • direction: All events currently hold both</loc:directionRelativeOnLinearSection>. To complete the configuration, we need to know the value for one direction.
  • polyline: Missing for 19 out of 20 events. We require Decimal Degrees (DD) coordinates, and recommend having at least 6 digits after the decimal point for sufficient accuracy. This is how the polyline was provided for one of the events, and this format is supported. 
    
<loc:fromPoint xsi:type="loc:DistanceFromLinearElementReferent">
                        <loc:distanceAlong>0</loc:distanceAlong>

                        <loc:fromReferent>

                            <loc:referentIdentifier>start</loc:referentIdentifier>

                            <loc:referentName>85</loc:referentName>

                            <loc:referentType>referenceMarker</loc:referentType>

                            <loc:pointCoordinates>

                                <loc:latitude>43.63254</loc:latitude>

                                <loc:longitude>1.438402</loc:longitude>

                            </loc:pointCoordinates>

                        </loc:fromReferent>

                    </loc:fromPoint>

                    <loc:toPoint xsi:type="loc:DistanceFromLinearElementReferent">

                        <loc:distanceAlong>0</loc:distanceAlong>

                        <loc:fromReferent>

                            <loc:referentIdentifier>end</loc:referentIdentifier>

                            <loc:referentName>91</loc:referentName>

                            <loc:referentType>referenceMarker</loc:referentType>

                            <loc:pointCoordinates>

                                <loc:latitude>43.632954</loc:latitude>

                                <loc:longitude>1.438502</loc:longitude>

                            </loc:pointCoordinates>

                        </loc:fromReferent>


> Please let me know if you have any questions. Otherwise, can you please provide an updated feed incorporating the above feedback for us to test?

Les données DiaLog tells qu'implémentées dans le cadre de ce ticket n'ont donc pas pu être intégrées en l'état par Waze. Les dispositions des arrêtés en question ayant pris fin, les enseignements qu'on pourra tirer de ce feedback devront être implémentés de façon plus durables et dans le cadre d'une collaboration continue et plus étroite avec Waze. Par ailleurs on comprend de fait que Waze accepterait d'intégrer des données DiaLog nativement en Datex II et sans qu'il soit nécessaire d'implémenter CIFS.

Je propose donc de continuer ce sujet spécifique à Waze sur #198