Indicateur "Arrêtés de circulation diffusés" #562
Comments
|
Questions auxquelles on doit répondre au préalable :
|
|
@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 ? |
|
DATEX et CIFS ne sont pas d'accord sur l'unité de traitement
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é" ? |
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"). |
|
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" ? |
|
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 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é. |
|
Si ma compréhension est bonne, on peut faire correspondre les notions de "restriction" et "incident". Je propose d'avancer sur un indicateur "restrictions de circulation" en reprenant la définition qu'on s'est donnée (cf. #986) et en prenant en compte dans un premier temps le périmètre de l'export en Datex II (qui n'a pas la même volumétrie que l'export CIFS) si cela te semble pertinent et faisable @florimondmanca. |
|
Attention la granularité correspond à peu près mais pas totalement ce qui fait que ces notions restent distinctes (et tant mieux car il vaut mieux ne pas concevoir DiaLog en fonction d'un format tiers donné répondant à un système autre, à savoir le service de navigation Waze) Notamment dans un "incident" CIFS, la localisation est renseigné par une À l'inverse une "restriction" ayant lieu sur une localisation utilisera la géométrie de cette localisation quelle qu'elle soit (assemblage de lignes, dans le futur pourquoi pas un polygône, etc), notamment pour des types de mesures que Waze ne supporterait pas (ZFE à l'avenir ?). En tout cas oui l'idée d'un indicateur avec une granularité "nombre de restrictions diffusées" ça aurait du sens |
On a quand même été obligés de concevoir dans DiaLog un export spécifique pour Waze, en CIFS. ;) Mais c'est pas le besoin ici. Mon objectif c'est de trouver une unité, une "métrique", qui pourrait être commune à tous les réutilisateurs. Ce qu'il faut éviter c'est d'avoir un indicateur "nombre d'incidents diffusés dans Waze" (qui mesurerait la volumétrie de notre export CIFS), ensuite un autre indicateur "nombre de restrictions diffusées dans TomTom", etc. On veut un indicateur le plus représentatif possible de la volumétrie de ce qu'on diffuse (ce qu'on "met en ligne" pour reprendre le terme qu'on a utilisé l'autre jour), avec une unité commune, interopérable, entre les différents réutilisateurs.
Est-ce que ça mesurerait la volumétrie uniquement sur la base du fichier Datex II ? Est-ce que tu préconises d'avoir un autre indicateur pour la volumétrie du CIFS ou tu penses qu'on peut trouver un indicateur commun ? |
|
Le nombre de restrictions diffusées dans Waze sera différent de ce qui est diffusé dans le DATEX car il y a un filtre dans ce qu'on exporte en CIFS (temporaire uniquement, tous véhicules uniquement) Je ne sais pas s'il vaut mieux faire un indicateur dédié par rapport à un indicateur qui compterait les restrictions diffusées dans le DATEX... |
|
On partirait sur un indicateur "Nombre d'incidents actuellement diffusés dans Waze", en plus d'un indicateur "Nombre de restrictions actuellement diffusées en Datex II" ou "mises en ligne" ? Une fois cette question réglée, je pense aussi à la question de l'historique de nos données, qui n'est pas directement lié au sujet des indicateurs d'ailleurs. Par exemple : est-ce que notre fichier CIFS qui servirait au calcul de l'indicateur va contenir l'historique de tous les incidents issus de DiaLog, y compris ceux qui ne sont plus d'actualité ? |
|
Oui il faudrait que l'indicateur ne calcule que de l'instantané (nb de restrictions en ligne / diffusées à l'instant T), on peut toujours calculer un cumul à partir de ça. Actuellement dans le CIFS il n'y a que les restrictions en cours ou à venir (le passé n'est pas exposé). Par contre dans le DATEX il y a tout (passé, en cours, à venir) Donc le nb de restrictions DATEX sur le fichier actuel sera nécessairement une fonction croissante (vu qu'on accumulera ce qui est passé). Donc si on veut du "actuellement diffusées en DATEX II" il faudrait faire comme le CIFS, à savoir n'exposer en DATEX que ce qui est permament, ou bien temporaire en cours ou à venir. |
|
Dans un premier temps, de façon à ne pas avoir à toucher aux fichiers CIFS et Datex 2, je propose qu'on crée 2 indicateurs :
respectivement basés sur les fichiers CIFS et Datex 2 tels qu'ils sont aujourd'hui, avec des tickets dédiés qui pourraient être à priori mis en "prêt à développer" tout de suite (tu confirmes @florimondmanca ?). Ensuite, on pourrait envisager les indicateurs suivants :
qui nécessiteraient des développements supplémentaires. Plus tard, dès qu'on pourra mesurer la diffusion dans HERE, TomTom et cie, on tendrait vers un ou plusiers indicateurs qui mesurent les "Restrictions de circulations diffusés dans les services de navigation". Pour moi ça répondrait aux besoins sur un indicateur-phare, "North Star Metric", tel qu'on l'a évoqué, car ça correspond à la raison d'être de DiaLog de diffuser la règlementation routière dans les GPS. @MathieuFV Qu'en penses-tu ? |
|
Hello, Je ne suis pas sûr d'avoir compris l'enjeu sur "ne pas avoir à toucher aux fichiers DATEX/CIFS" Mais je suis aussi partisan de s'appuyer sur ce que reçoivent les GPS, à savoir ces fichiers DATEX et CIFS, pour calculer notre métrique, plutôt que faire une requête à la DB Ça va dans le sens de la consommation de notre propre production pour vérifier qu'elle est utilisable (cf des pb comme #1100 ou #1099 qui ont été détectés par un utilisateur de l'API, sans qu'on ait pu le détecter plus tôt) |
Créer 2 premiers indicateurs good enough rapidement, donc avancer vite et itérer ensuite. |
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.
Critères d'acceptation
Sur la page stats :
Implémentation
A définir en fonction des critères d'acceptation.
Dans le périmètre exploré pour cet epic (voir discussions ci-dessous)
2 premiers indicateurs en cours d'implémentation :
2 autres indicateurs encore en cours d'exploration :
The text was updated successfully, but these errors were encountered: