Applying multiple validityConditions

[skinkie]

Within NeTEx we can have multiple AvailabilityConditionRefs on a single ServiceJourney. An example would be like below. In this specific example there is a base availability condition (positive) with a list of exceptions.

If we want to materialise two or more AvailabilityConditions should that be the sum of the positive availabilities minus the sum of the negative availabilities?

In the Dutch profile we are now proposing a variant like this. To make explicit when the journey does not operate. To have backwards compatibility our positive ValidDayBits does not include the days the trip does not operate. /cc @hilcokats

            <ServiceJourney id="Flix:ServiceJourney:001-29-1300032024-FR#M-00" version="1.0">
              <validityConditions>
                <AvailabilityConditionRef version="1.0" ref="Flix:AvailabilityCondition:001-29-1300032024-FR#M"/>
                <AvailabilityConditionRef version="1.0" ref="Flix:AvailabilityCondition:001-29-1300032024-FR#M_2"/>
              </validityConditions>

            </ServiceJourney>

            <AvailabilityCondition id="Flix:AvailabilityCondition:001-29-1300032024-FR#M" version="1.0">
              <FromDate>2024-03-01</FromDate>
              <ToDate>2024-03-31</ToDate>
              <IsAvailable>true</IsAvailable>
              <dayTypes>
                <DayType id="Flix:DayType:001-29-1300032024-FR#M" version="1.0">
                  <properties>
                    <PropertyOfDay>
                      <DaysOfWeek>Monday Thursday Friday Saturday Sunday</DaysOfWeek>
                    </PropertyOfDay>
                  </properties>
                </DayType>
              </dayTypes>
            </AvailabilityCondition>

            <AvailabilityCondition id="Flix:AvailabilityCondition:001-29-1300032024-FR#M_2" version="1.0">
              <FromDate>2024-03-03</FromDate>
              <ToDate>2024-03-24</ToDate>
              <IsAvailable>false</IsAvailable>
              <ValidDayBits>1100000110000011000001</ValidDayBits>
            </AvailabilityCondition>

[Aurige]

The documentation (Part 1) says : Note that ValidityCondition can be combined and ANDed (all the conditions shall be fulfilled at the same time) So that's correct

When you do this, do you also refer the DAY TYPEs inside the AvailabilityCondition from ServiceJourney.dayTypes ?

[skinkie]

At this moment not, because I would think that would be redundant with the AvailabilityConditionRef.

[Aurige]

That's probably a point where we need best practice rules (I know that some will systematically search for ServiceJourney.dayTypes )

[ue71603]

We try to only use bit fields and not arithmetic in the consumer.

[skinkie]

That's probably a point where we need best practice rules (I know that some will systematically search for ServiceJourney.dayTypes )

The question is basically if you refer a StopPlace, you assume that it also means the Quays below it. There can be more than one DayType, why wouldn't that be 'AND' but instead requires an extra reference.

[skinkie]

We try to only use bit fields and not arithmetic in the consumer.

This is my target as well for publications, but not for intermediates should match the source.

[Aurige]

Yes, bit fields are the recommended way for EPIP too The question is where to put it (and we need to be careful with Transmodel here) and how to articulate DAY TYPEs and VALIDITY CONDITIONs when both can be used

[duexw]

Both validDayBits and Daytype/DaytypeAssignment describe correctly the operating days of the journey. ValidDayBits have the advantage of minimal interpretation, you know exactly when the journey will operate. DayTypes on the other hand provide some semantic context, for instance you can create a "Monday to Friday summer holiday of LMU university". It has advantages if the data are imported into a scheduling system rather than a journey planner. However, I find it a little confusing if you have both and then you need to combine them. I would find it easier if they both needed to be complete if you use both.