mmarchois
commented
1 year ago @johanricher Quelques éléments de réponses
Question posées par https://github.com/MTES-MCT/dialog/issues/435 (l'exploration doit permettre de trouver une piste de résolution)
L'export des créneaux horaires au format DATEX a été laissé de côté pour pouvoir se concentrer sur l'implémentation "UI". La maquette que nous avons aujourd'hui en production est compatible. Il est donc tout à fait possible de reprendre ce chantier pour exporter les données.
Est-ce qu'il y a des éléments de l'interface actuellement souhaitée qui ne peuvent pas être implémentés en Datex II ? lesquels ?
La question que je me posais était surtout sur le fait d'appliquer plusieurs créneaux horaires pour une même sélection de jours applicables. En creusant un peu plus, cela me parait possible d'implémenter la maquette cible en spécifiant plusieurs ValidityCondition dans lesquels on pourra spécifier les périodes. @florimondmanca est-ce que ça te parait juste ?
Le design actuel de création d'un arrêté dans DiaLog demande d'abord (page /add) une date de début et une date de fin, puis (page suivante) un ou plusieurs créneaux horaires pour chaque restriction attachée à un arrêté. Est-ce que cela est implémentable dans Datex II ?
Il y a une date de début et de fin pour indiquer la plage de validité "globale" de l'arrêté qui est implémenté en production. (cf https://dialog.beta.gouv.fr/api/regulations.xml) :
<com:validityTimeSpecification>
<com:overallStartTime>2023-08-11T18:00:00+02:00</com:overallStartTime>
<com:overallEndTime>2023-08-15T06:00:00+02:00</com:overallEndTime>
</com:validityTimeSpecification>que se passe-t-il si les 2 se contredisent ? (par exemple un créneau qui commence avant la date de début)
Aucune idée, encore une question de comment les GPS consomment nos données. Après, nous pouvons sécuriser l'intégration de nos données en mettant des règles de validité côté applicatif. Aujourd'hui, ce n'est pas encore le cas.
Quelle est la spécification des horaires de Datex II ? Est-ce qu'il existe un moyen technique (par exemple une librairie) pour créer et/ou valider ces données sur la partie spécifique aux horaires ?
Je ne comprends pas très bien ta question. Aujourd'hui la seule façon que nous avons pour valider l'export DATEX est le schéma XSD. Pour s'assurer de la bonne validité des données (chevauchement de créneaux, par exemple) nous pouvons poser des règles de validité côté applicatif (même remarque que plus haut). Bonjour le mal de crâne ! :smile:
johanricher
florimondmanca
aureliebaton
Lealefoulon
Contexte
La transposition d'horaires écrits par des humains en données lisibles par des machines, et de façon à gérer tous les cas particuliers, est un sujet par nature complexe. Voir par exemple la spécification
opening_hoursd'OpenStreetMap.DiaLog expose actuellement ses données au format Datex II uniquement. A ce sujet, voir la documentation du projet :
Il est indispensable que toutes les caractéristiques des restrictions de circulation paramétrées avec DiaLog soient transposables avec Datex II, afin que ce qui apparaît au final dans les GPS respecte l'intégrité des arrêtés d'origine.
Les arrêtés de circulations disposent de restrictions avec des horaires et temporalités parfois complexes (voir exemples ci-dessous).
Exemples
Arrêté (Savenay T-SN2022-05-154) avec des exceptions (week-ends et jours fériés, les week-ends étant définis avec un début à 16h30 le vendredi et une fin à 9h le lundi) :
Autres arrêtés sur kDrive (dossier "horaires").
Voir également les exemples recensés ici
Critères d'acceptation
Exploration
Implémentation
La gestion des horaires doit être implémentée sur 3 niveaux à la fois et de façon iso :
Suite à la première phase d'exploration, on décide une première implémentation qui vise à améliorer l'UI "Créneaux horaires" lors de la création d'un arrêté :
Dépendances :
Notes suite aux réunions dev/design des 2-4 octobre
DailyRangeavec un seulTimeSlotMeasureTimeSlotWeeklyRangeavec le design puis l'implémenterPR :
507
529 #532