Horaires - Gestion des calendriers (DayTypeAssignment)

[prhod]

J'ai eu du mal à comprendre la gestion des calendriers d'une course, je note ici mes difficultés pour en discuter et voir s'il y a besoin de préciser le profil. (merci à Christophe pour avoir passé un peu de temps avec moi sur le sujet)

Difficulté 1 :

Difficulté de compréhension de ce qu'est le DayType. Pour moi, un DayType est un jour de fonctionnement, par exemple les lundis entre le 01/01/2025 et le 31/01/2025. Cette interprétation est renforcée par le texte du tableau 47 qui indique sur le DayType :
On utilisera le ValidBetween pour une éventuelle limitation de période
Ce n'est pas faux, mais l'objet est plus complexe que ça.

=> Un DayType peut référencer juste un jour (un lundi), un autre type de jour (le 2ème jeudi de chaque mois), préciser une plage de validité avec ValidBetween, ou ne rien avoir du tout (lien avec DayTypeAssignment , difficulté suivante).

=> Un dayType peut donc suffire dans la plupart des cas simple, sans avoir besoin du DayTypeAssignment .
Par contre, l'utilisation du ValidBetween pour la validité indique sémantiquement que l'objet "DayType" n'est plus valide, et pas les bornes effectives du calendrier de circulation de la course.

=>un DayType peut également être vide pour être complété des DayTypeAssignment

Conclusion : Le profil décrit bien ceci, mais un peu de travail sur la forme peut faciliter la compréhension (si j'ai bien compris !).

Difficulté 2 :

Quel est le lien entre DayType et DayTypeAssignment ? comment bien utiliser un DayTypeAssignment ?
il est indiqué dans le profil :

Dans un certain nombre de situation, les PROPRIÉTÉ DE JOUR ne permettent pas de décrire précisément un TYPE DE JOUR, qui en final ne sera défini que par un ensemble de JOURs D’EXPLOITATION: on réalise alors une affectation entre le TYPE DE JOUR et les JOURs D’EXPLOITATION correspondants.

on a donc le cas où un DayType est vide (pas de PropertyOfDay), et qu'il est complété par un DayTypeAssignment (avec isAvailable=true), c'est le cas simple (si on ne regarde pas le fait que le contenu d'un DayTypeAssignment puisse être un OperatingPeriodRef, OperatingDayRef ou une Date.
Plusieurs cas qui posent question :

Cas 1 : on a plusieurs DayType

est-ce qu'il s'agit bien de la somme des jours "actifs" spécifiés par chaque DayType ?

Cas 2 : un DayType précisé par un OperatingPeriodRef (UicOperatingPeriod)

si DayType déclare un lundi et que l'OperatingPeriodRef (UicOperatingPeriod) indique du 01/01 au 31/01, est-ce que le ValidDayBits doit ne représenter que la plage UicOperatingPeriod toujours active, ou ne montrer que les jours du DayType appliqués ?

Cas 3 : plusieurs OperatingPeriodRef

Si un DayType est associé à 3 OperatingPeriodRef, dont 2 avec isAvailable à true et un autre à false, et qu'ils ont des jours en commun (j'ai pas de chance !). Y a-t-il une règle d'application des OperatingPeriodRef à appliquer ?

Conclusion : en fonction des réponses, je peux proposer une clarification du texte

[Aurige]

Cas1 ) Oui on ajoute les DayType (note que dans le DayTypeAssignment on a un possible "isAvailable" qui permet à contrario d'exclure des jours ... la fameuse petite asterisque "* sauf le jour ou vous en avez besoin")

Cas2) le ValidDayBits ne doit avoir des 1 que sur les jours de fonctionnement associés au DayType

Cas3) non, on flag "la donnée est pourrie" !!! mais on peut prendre comme règle que l'exception négative gagne (juste un avis perso)

[prhod]

Petit résumé des échanges ci-dessus :

• Si le DayType est tout seul, la définition des bornes d'application n'est pas explicite ou faite avec un objet qui n'est pas fait pour ça
• Si le DayType est associé à un DayTypeAssignment, c'est simple, on a même la traduction des jours de fonctionnement avec ValidDayBits
• Si le DayType est associé à plusieurs DayTypeAssignment, chaque DayTypeAssignment aura son ValidDayBits, et il faudra combiner les DayTypeAssignment avec des OR logiques si ce sont des isAvailable=true ou un NOT AND pour un isAvailable=false, en précisant qu'il faut appliquer les isAvailable=false en dernier pour qu'ils soient prioritaires ...

=> Il est possible d'expliciter ça dans la doc, mais j'ai une préférence pour proposer dans le profil France une cardinalité 1..1 entre DayType et DayTypeAssignment. Ce sera plus facile pour tout le monde.
Qu'en dites vous ?

[albanpeignier]

Difficulté de compréhension de ce qu'est le DayType. Pour moi, un DayType est un jour de fonctionnement, par exemple les lundis entre le 01/01/2025 et le 31/01/2025. Cette interprétation est renforcée par le texte du tableau 47 qui indique sur le DayType :
On utilisera le ValidBetween pour une éventuelle limitation de période
Ce n'est pas faux, mais l'objet est plus complexe que ça.
=> Un dayType peut donc suffire dans la plupart des cas simple, sans avoir besoin du DayTypeAssignment .

L'utilisation du ValidBetween sur un DayType sans passer par une (*)OperationPeriod semble très très exotique (= je ne l'ai jamais vu).

Difficulté 2 > Cas 1 : on a plusieurs DayType

Un DayType correspond dans la pratique à un calendrier. Je ne vois pas de raison de tenter d'associer plusieurs DayTypes pour représenter un seul calendrier.

Cas 2 : un DayType précisé par un OperatingPeriodRef (UicOperatingPeriod)

Cela rejoit les soucis de cohérence soulevés avec l'utilisation obligatoire de UICOperatingPeriod et les autres structures (OperatingPeriods simples, DayTypeAssignements avec des dates, etc): #58

Cas 3 : plusieurs OperatingPeriodRef

Il y a plein plein de règles de composition qui ne sont pas explicitement définies. Si un DayTypeAssignement ajoute une date et qu'un autre enlève la même date ? Mais c'est aussi le cas en GTFS, je pense.

[albanpeignier]

Comme j'ai du mal à discuter de ce genre de détails sans avoir un exemple sous les yeux. Voici un exemple de calendrier tiré de nos tests automatiques de Chouette :

<DayType id="daytype-1">
  <Name>Sample</Name>
  <properties>
    <PropertyOfDay>
      <DaysOfWeek>Tuesday Friday</DaysOfWeek>
    </PropertyOfDay>
  </properties>
</DayType>

<DayTypeAssignment id="assigment-1">
  <OperatingPeriodRef ref="period-1"/>
  <DayTypeRef ref="daytype-1"/>
</DayTypeAssignment>

<DayTypeAssignment id="assigment-2">
  <OperatingPeriodRef ref="period-2"/>
  <DayTypeRef ref="daytype-1"/>
</DayTypeAssignment>

<DayTypeAssignment id="assigment-3">
  <Date>2030-01-04</Date>
  <DayTypeRef ref="daytype-1"/>
  <isAvailable>false</isAvailable>
</DayTypeAssignment>

<DayTypeAssignment id="assigment-4">
  <Date>2030-01-15</Date>
  <DayTypeRef ref="daytype-1"/>
  <isAvailable>true</isAvailable>
</DayTypeAssignment>

<OperatingPeriod id="period-1">
  <FromDate>2030-01-01T00:00:00</FromDate>
  <ToDate>2030-01-05T00:00:00</ToDate>
</OperatingPeriod>

<OperatingPeriod id="period-2">
  <FromDate>2030-01-06T00:00:00</FromDate>
  <ToDate>2030-01-10T00:00:00</ToDate>
</OperatingPeriod>

Une course (par exemple) qui veut se référencer à ce calendrier, utilisera un DayTypeRef ref="daytype-1". Elle pourra se référencer à plusieurs calendriers.

Cet exemple n'inclut pas l'utilisation des UICOperatingPeriods. D'une part, parce que ca n'aide pas à comprendre la structuration des données. D'autre part, parce qu'il y a moultes possibilités de conflit entre les ValidDaysBits d'un UICOperatingPeriod et le (potentiel) reste de la définition du DayType.

On parle bien des DayTypes utilisés pour définir un calendrier de circulation. Il y a d'autres utilisations des DayTypes dans NeTex (qui n'ont rien à voir avec un calendrier indiquant les jours de circulations d'une course).

[albanpeignier]

Pour éclairer la discussion autour de l'utilisation des UicOperatingPeriods, voici un exemple de calendrier avec uniquement un UicOperatingPeriod:

<DayType id="daytype-1">
  <Name>Sample</Name>
</DayType>

<DayTypeAssignment id="assigment-1">
  <OperatingPeriodRef ref="period-1"/>
  <DayTypeRef ref="daytype-1"/>
</DayTypeAssignment>

<UicOperatingPeriod id="period-1">
  <FromDate>2030-07-01T00:00:00</FromDate>
  <ToDate>2030-07-31T00:00:00</ToDate>
  <ValidDayBits>1000001100000010010011000001101</ValidDayBits>
</UicOperatingPeriod>

Certes, cela permet de définir les mêmes jours qu'un DayType/DayTypeAssignment/OperatingPeriod. Donc, on peut imaginer réduire tous les calendriers à cette forme (1 DayType, 1 DayTypeAssignement et 1 UicOperatingPeriod).

Comme indiqué dans le ticket dédié : #58, cette approche parait jolie au premier abord, mais complexe dans la pratique.

En effet, beaucoup d'applications représentent leurs calendriers sur une (voire des périodes) avec des jours d'inclusion/exclusion (comme fait le GTFS). Donc passer à un ValidDayBits "pur" est loin d'être innocent.

Dans Chouette, nous avons mis en place des algorithmes pour pouvoir passer d'un ValidDayBits à des Periodes/inclusions/exclusions (et inversement) de manière transparente pour l'utilisateur.

Mais utiliser uniquement les ValidDayBits pour définir les calendriers va rendre la vie plus compliquée pour toute une partie de la chaine IV. Et risque de donner en sortie des données calendaires de piètre qualité.

[Aurige]

ça me semble tout Ok, et je confirme que l'utilisation du ValidBetween sur un DayType sans passer par une OperationPeriod est à proscrire (mais ne le dites pas aux Néerlandais ;-) )

[prhod]

Tentative de clarification dans la PR #150