Indicateur "Arrêtés de circulation diffusés"

johanricher commented 10 months ago

Contexte

Dans le cadre de la refonte de nos indicateurs d'impact (#506).

Description

DiaLog permet à des utilisateurs, par exemple des agents dans des collectivités, de publier des arrêtés définissant des restrictions de circulations, exportés au format papier (DOCX) et en données diffusées dans des services de navigation tels que Waze. Par ailleurs DiaLog intègre des données sur des restrictions de circulations provenant de différentes sources, pour les diffuser auprès des services de navigation sans intervention d'utilisateurs.

Cet indicateur vise à estimer l'impact de DiaLog en mesurant le nombre d’arrêtés de circulation diffusés dans des services de navigation.

Les services de navigation n'intègrent qu'une partie des restrictions de circulations contenues dans les arrêtés qu'à certaines conditions qui nous sont connues et on ne diffuse auprès d'eux uniquement que les arrêtés compatibles (par exemple pour Waze on ne diffuse pas les restrictions qui concernent les poids lourds). Par conséquent, si nos données ont été validées et intégrées par un service de navigation, alors tous les arrêtés intégrés seront effectivement diffusés.

Nom : Arrêtés de circulation diffusés dans des services de navigation
Source : données DiaLog exportées aux différents formats (Datex II, CIFS...)
Méthode de mesure :
- Services de navigation intégrés par DiaLog : services tels que Waze dont on a pu constater qu'ils ont intégré les données DiaLog
- Arrêtés diffusés : export de données dans un format tel que CIFS ne contenant que des arrêtés dont on sait qu'ils pourront être intégré par le service de navigation
Objectif : valeur et date cibles à définir

Critères d'acceptation

Sur la page stats :

On peut voir le nombre d’arrêtés de circulation diffusés grâce à DiaLog
On peut voir l'évolution dans le temps
On peut voir le détail par service de navigation (Waze, HERE, TomTom...)
On peut comparer les résultats obtenus par rapport à l'objectif fixé

Implémentation

A définir en fonction des critères d'acceptation.

Base de données : enregistrer et stocker les données dont on a besoin, pour faire des séries temporelles et visualiser la progression des indicateurs dans le temps
Période : un point de données par jour
Visualisation
- Valeur absolue : nombre actuel
- Tendance : pourcentage de hausse ou baisse depuis semaine précédente
- Line chart : graphique pour voir l'évolution de la série temporelle
Outil : Metabase ?

johanricher commented 10 months ago

Questions auxquelles on doit répondre au préalable :

Est-ce que l'objet "arrêté" est la bonne unité ? est-elle connue des services de navigations ? à défaut mesurer des "événements" ou des "restrictions de circulation" ?
Objectif : Quelle date et valeur cibles ?

johanricher commented 9 months ago

@florimondmanca Est-ce que tu as un avis sur comment on pourrait définir un "arrêté de circulation diffusé" ? Est-ce que l'objet "arrêté" est la bonne unité ? c'est à dire une unité comprise par les services de navigations (Waze, HERE, Tomtom...) dans les formats CIFS, Datex II... A défaut mesurer des "événements", des "restrictions de circulation" ou une autre unité qui serait sufisament générique pour être comparable entre tous les services de navigations ?

florimondmanca commented 9 months ago

@johanricher

DATEX et CIFS ne sont pas d'accord sur l'unité de traitement

CIFS raisonne par "événement" (équivalent de nos "restrictions") : chaque "événement" a un ID.
DATEX II par "arrêté" (traffigRegulationOrder) : chaque arrêté a un ID, et il contient l'équivalent de nos "restrictions" (trafficRegulation), qui n'ont pas d'ID en propre

Pour le besoin de cet indicateur, autant on peut facilement obtenir le nombre d'arrêtés "publiés" (c'est-à-dire mis à dispo sur l'endpoint DATEX II ou le futur endpoint CIFS), et donc par extension les restrictions "publiées" (toutes les restrictions des arrêtés publiés) ...

Autant le nombre d'arrêtés / restrictions "effectivement intégrés" (ce qui serait bien plus intéressant), actuellement on ne peut pas le savoir. Il faudrait pour ça une sorte de "ack" (accusé de réception) de la part des GPS : "j'ai bien traité l'objet avec tel ID". Une solution générique prendrait la forme d'un endpoint d'API et il reviendrait aux réutilisateurs des données (Waze, autres GPS, etc) de l'appeler pour dire : "j'ai bien traité ça et ça". Mais je ne verrais pas à ce stade l'intérêt pour les réutilisateurs. Du coup je ne pense pas que ça prendrait sauf avec les entités avec qui on pourrait "contractualiser".

Est-ce que le niveau "publié" (= nb d'unités dans DATEX II, dans CIFS...) suffirait ? Ou est-ce qu'on veut creuser le niveau "effectivement intégré" ?

johanricher commented 9 months ago

le nombre d'arrêtés / restrictions "effectivement intégrés" (ce qui serait bien plus intéressant), actuellement on ne peut pas le savoir.

Je pense justement que si. Si on ne diffuse (au cas par cas, service par service) que des données qui sont intégrables, donc intégrées, on peut savoir quelles sont nos données intégrées pour chaque service de navigation. (J'ai expliqué plus longuement mon raisonnement dans le corps du ticket).

Par exemple pour Waze : tout l'enjeu est de produire un fichier qui sera valide au format CIFS donc intégrable. Donc si on produit un tel fichier valide, il sera intégré. Donc on pourra quantifier ce qui a été "diffusé" auprès de Waze.

La question est donc pour moi de traduire "données diffusées" en une unité pertinente et compréhensible (et qui, si je comprends ton propre raisonnement, serait la "restriction diffusée").

johanricher commented 4 months ago

Petit up de ce sujet, pour le mettre à jour de notre niveau de connaissance actuel des services auxquels DiaLog veut diffuser des données (principalement de Waze pour l'instant).

Quelle est l'unité (et la terminogie) à employer correspondant à la granularité de Waze ? la "restriction de circulation" ?

florimondmanca commented 4 months ago

Waze parle "d'incident". Je pense que c'est donc le terme à employer quand on parle avec eux / quand on parle de l'intégration Waze.

À notre niveau ça correspond à la granularité (attention c'est subtile) "tronçon de localisation"

En effet étant donnée une localisation (jusqu'ici une MULTILINESTRING ce qui ne correspondait pas aux tronçon, et à court-moyen terme une GEOMETRY COLLECTION de LINESTRING cf #793) , on la découpe en LINESTRING individuelle et on a un incident par telle LINESTRING utilisée pour sa <polyline>.

Donc du point de vue d'un arrêté, on crée donc un incident pour chaque "tronçon" (tel qu'on le calcule) de chaque localisation de chaque mesure dans l'arrêté.

MTES-MCT / dialog