Horaires - Ajout de EarliestDepartureDayOffset et LatestArrivalDayOffset

[ArnaudOggy]

En complément de l'ajout de DepartureDayOffset et ArrivalDayOffset dans la PR #245,

nous avons noté qu'il manque également les éléments EarliestDepartureDayOffset et LatestArrivalDayOffset pour les courses utilisant EarliestDeparture­Time et LatestArrivalTime.

Ajout de ces éléments manquants ainsi qu'un reformatage/adaptation du tableau.
La PR ainsi que les descriptions des éléments peuvent être modifiées à votre convenance bien évidemment.

[prhod]

@ArnaudOggy est-ce que tu peux préciser le cas d'usage ?
Sur le principe il est effectivement possible d'ajouter les propriétés, mais l'objectif est de garder un modèle le moins complexe possible. Je n'ai trouvé aucun fichier sur le PAN avec la propriété EarliestDeparture­Time.
Merci

[ArnaudOggy]

@ArnaudOggy est-ce que tu peux préciser le cas d'usage ? Sur le principe il est effectivement possible d'ajouter les propriétés, mais l'objectif est de garder un modèle le moins complexe possible. Je n'ai trouvé aucun fichier sur le PAN avec la propriété EarliestDeparture­Time. Merci

Décidément. Je ne vois jamais vos notifications. Il faut vraiment que je vérifie mes settings.
Désolé sincèrement pour ce retour tardif 🙏

Concernant le use-case il s'agit d'un cas de production.

Les dernières dessertes de certaines lignes régulières d'une AO bien connue vont être remplacées (surement à des fins d'économie) par des véhicules TAD, partant d'un point d'arrêt "régulier" pour desservir un bassin TAD le soir/nuit, afin de ramener les gens à domicile.

Exemple

<JourneyPatternRef ref="ServiceJourneyPattern:27433ed7-c870-4915-98af-fcc9e1339a05:LOC" version="any"/>
<passingTimes>
  <TimetabledPassingTime version="any" id="TimetabledPassingTime:68274_763_0_0-0:LOC">
    <StopPointInJourneyPatternRef ref="StopPointInJourneyPattern:local-209733-C02579-153-335-27433ed7-c870-4915-98af-fcc9e1339a05:LOC"/>
    <LatestArrivalTime>00:55:00</LatestArrivalTime>
    <LatestArrivalDayOffset>1</LatestArrivalDayOffset>
    <EarliestDepartureTime>22:55:00</EarliestDepartureTime>
  </TimetabledPassingTime>
  <TimetabledPassingTime version="any" id="TimetabledPassingTime:68274_763_0_0-1:LOC">
    <StopPointInJourneyPatternRef ref="StopPointInJourneyPattern:local-209733-C02579-153-336-27433ed7-c870-4915-98af-fcc9e1339a05:LOC"/>
    <LatestArrivalTime>00:55:00</LatestArrivalTime>
    <LatestArrivalDayOffset>1</LatestArrivalDayOffset>
    <EarliestDepartureTime>22:55:00</EarliestDepartureTime>
  </TimetabledPassingTime>
</passingTimes>

[prhod]

@ArnaudOggy si je comprends le besoin, c'est d'avoir des courses qui transforment les bouts de ligne en TAD arrêt à arrêt, c'est ça ?
Dans ton exemple, je comprends que l'heure de passage d'une course à l'arrêt peut être entre 22h55 et 24h55, mais il y aura plusieurs circulations dans ce créneau je suppose ? J'ai du mal à voir comment un consommateur peut comprendre qu'il s'agit d'un TAD Zonal en ajoutant simplement cette propriété.

Nous avons eu des discussions au niveau NeTEx récemment, et j'ai proposé une modélisation de TAD zonal dans NeTEx-CEN/NeTEx#1008. La discussion est en cours, mais avoir ton avis dessus serait intéressant !

[ArnaudOggy]

si je comprends le besoin, c'est d'avoir des courses qui transforment les bouts de ligne en TAD arrêt à arrêt, c'est ça ?

Oh non. Ça c'était pour le contexte.
Le besoin est simplement d'avoir un véhicule (ou une flotte) TAD, commençant son service en fin de journée (22:55 dans ce cas-ci) et terminant le lendemain matin (00:55). Pas d'horaires fixes, mais une plage horaire de service.

EarliestDepartureTime et LatestArrivalTime sont déjà dans la norme Netex fr.
Mais il est à minima nécessaire d'y rajouter LatestArrivalDayOffset pour gérer ce cas de service TAD passe-minuit.

EarliestDepartureDayOffset c'est du bonus, et pour être iso aux xsd Netex. Même si dans les faits les cas d'EarliestDepartureDayOffset à valeur 1 et + seront quasiment inexistants.

Note:à ta dispo si tu as besoin de retour d'expérience sur la modélisation TAD.

[prhod]

@ArnaudOggy le problème, c'est que je ne comprends pas l'usage de ces propriétés dans un cas de TAD.
tu es sur un horaire d'une course, et tu indique une heure "au plus tôt" et une heure "au plus tard" à un arrêt, qui est associé à un JourneyPattern de course classique. Donc en consommation, tu n'as qu'une seule course qui peut passer entre 22h30 et 0h30, ça ne fait pas beaucoup !
Ma compréhension de ces propriétés dans ce cas est pour indiquer que le bus peut partir 5 minutes avant ou arriver 10 minutes après => notion d'engagement de service précisé dans la définition. Ce n'est pas pour de l'info voyageur.

[ArnaudOggy]

@ArnaudOggy le problème, c'est que je ne comprends pas l'usage de ces propriétés dans un cas de TAD. tu es sur un horaire d'une course, et tu indique une heure "au plus tôt" et une heure "au plus tard" à un arrêt, qui est associé à un JourneyPattern de course classique. Donc en consommation, tu n'as qu'une seule course qui peut passer entre 22h30 et 0h30, ça ne fait pas beaucoup ! Ma compréhension de ces propriétés dans ce cas est pour indiquer que le bus peut partir 5 minutes avant ou arriver 10 minutes après => notion d'engagement de service précisé dans la définition. Ce n'est pas pour de l'info voyageur.

Je ne vois pas (encore) là où tu bloques. Mais je vais arriver à comprendre là où tu veux m’emmener 😅

En l'occurence le ServiceJourneyPattern associé au ServiceJourney indiqué plus haut.

  <ServiceJourneyPattern id="ServiceJourneyPattern:27433ed7-c870-4915-98af-fcc9e1339a05:LOC" version="any">
    <Name>Inbound</Name>
    <RouteRef ref="Route:a25a9122-56e4-4323-aba0-b792544bb57b:LOC" version="any"/>
    <bookingArrangements>
      <BookingArrangementRef ref="BookingArrangement:a5687c8b-1a69-4f6c-8221-0c24993abc87:LOC" version="any" />
    </bookingArrangements>
    <pointsInSequence>
      <StopPointInJourneyPattern id="StopPointInJourneyPattern:local-209733-C02579-153-335-27433ed7-c870-4915-98af-fcc9e1339a05:LOC" version="any" order="1">
        <ScheduledStopPointRef ref="ScheduledStopPoint:local-209733-C02579-153-335:LOC" version="any"/>
        <ForAlighting>false</ForAlighting>
        <ForBoarding>true</ForBoarding>
        <FlexiblePointProperties version="any">
          <PointStandingForAZone>true</PointStandingForAZone>
          <ZoneContainingStops>true</ZoneContainingStops>
        </FlexiblePointProperties>
      </StopPointInJourneyPattern>
      <StopPointInJourneyPattern id="StopPointInJourneyPattern:local-209733-C02579-153-336-27433ed7-c870-4915-98af-fcc9e1339a05:LOC" version="any" order="2">
        <ScheduledStopPointRef ref="ScheduledStopPoint:local-209733-C02579-153-336:LOC" version="any"/>
        <ForAlighting>true</ForAlighting>
        <ForBoarding>false</ForBoarding>
        <FlexiblePointProperties version="any">
          <PointStandingForAZone>true</PointStandingForAZone>
          <ZoneContainingStops>true</ZoneContainingStops>
        </FlexiblePointProperties>
      </StopPointInJourneyPattern> 
    </pointsInSequence>
  </ServiceJourneyPattern>

Ainsi que ces FlexibleStopAssignments.

<FlexibleStopAssignment id="PassengerStopAssignment:local-209733-C02579-153-335:LOC" version="any" order="1">
<ScheduledStopPointRef ref="ScheduledStopPoint:local-209733-C02579-153-335:LOC" version="any"/>
<FlexibleStopPlaceRef ref="FR::FlexibleStopPlace:50320005:FR1" version="any"/>
</FlexibleStopAssignment>
<FlexibleStopAssignment id="PassengerStopAssignment:local-209733-C02579-153-336:LOC" version="any" order="1">
<ScheduledStopPointRef ref="ScheduledStopPoint:local-209733-C02579-153-336:LOC" version="any"/>
<FlexibleStopPlaceRef ref="FR::FlexibleStopPlace:50320019:FR1" version="any"/>
</FlexibleStopAssignment>

La 1ère FlexibleStopPlace correspondant à une gare (et 3 de ses quais pour FlexibleArea).
La 2ème FlexibleStopPlace est le bassin TAD (et 90 quais/arrêts pour FlexibleArea).

Plus globalement, pour en revenir à EarliestDepartureTime/LatestArrivalTime, déjà présent dans la norme (fr), comment gérer l'arrivée au plus tard après-minuit ? Car EarliestDepartureTime ne peut être supérieur à LatestArrivalTime sans notion de DayOffset.
Si on prend l'exemple d'une représentation GTFS de ce véhicule (TAD) à horaires flexibles, quel est l'équivalent Netex d'un stop_time gtfs avec start_pickup_drop_off_window à 22:55:00 et end_pickup_drop_off_window à 24:15:00 ?

[stifoon]

J'ai l'impression que tu es parti sur ta première interprétation @prhod :

@ArnaudOggy si je comprends le besoin, c'est d'avoir des courses qui transforment les bouts de ligne en TAD arrêt à arrêt, c'est ça ?
Ce n'est pas un cas aussi complexe qui est remonté ici : en l'occurrence, @ArnaudOggy parle d'une ligne TAD toute simple:

• entre 2 zones flexibles
• dont les horaires de début et de fin de services sont EarliestDepartureTime et LatestArrivalTime
• comportant 1 à plusieurs passages, ce n'est pas décrit ici

Ces balises EarliestDepartureTime & LatestArrivalTime sont déjà existante dans le profil, mais il existe une ambiguïté pour les TAD de nuit qui serait résolue avec un DayOffSet comme sur les autres horaires.

A votre dispo pour en discuter de vive voix !

[TuThoThai]

@ArnaudOggy et @stifoon, je ferai une réponse plus détaillée par la suite mais à noter qu'il y a un en cours sur les services flexibles (et notamment mixtes) côté NeTEx CEN car on voudrait pouvoir le faire mieux.
Donc il y a des chances que cela aille plus loin que changer des éléments du profil France.

[prhod]

@TuThoThai Après un échange avec @ArnaudOggy et @stifoon je te propose de gérer ce sujet en deux temps :

• Merger cette PR qui ajoute les 2 propriétés présentes dans NeTEx
• Créer une nouvelle issue sur la modélisation d'un TAD zonal complètement flexible (pas de point fixe et pas d'horaire fixe)