Estimated delay in timetables

[ue71603]

In some timetables with already know that there will be a probable delay (e.g. due to construction). We would prefer not to change the arrival and departure time (Arrival/Time and Departure/Time). We were thinking about using CheckConstraints also for that.

However, it seems we don't a CheckProcess or CheckService that reflects that.

<Call id="ch:1:Call:ch:1:ServiceJourney:33-15365-1-1_1_2" version="any" order="2">
    <ScheduledStopPointRef ref="ch:1:ScheduledStopPoint:8504416:3" version="any"/>
    <Arrival>
        <Time>17:30:00</Time>
        <ForAlighting>true</ForAlighting>
        <IsFlexible>false</IsFlexible>
        <CheckConstraint id="ch:1:CheckConstraint:2" version="any" order="1">
            <delays id="ch:1:delays:1">
                <CheckConstraintDelay id="ch:1:CheckConstraintDelay:1" version="any" order="1">
                    <alternativeTexts>
                        <AlternativeText attributeName="Name">
                            <Text lang="it">Ritardo stimato</Text>
                        </AlternativeText>
                        <AlternativeText attributeName="Name">
                            <Text lang="en">Estimated delay</Text>
                        </AlternativeText>
                        <AlternativeText attributeName="Name">
                            <Text lang="fr">Retard prévu</Text>
                        </AlternativeText>
                    </alternativeTexts>
                    <Name>Voraussichtliche Verspätung</Name>
                    <MinimumLikelyDelay>PT4M</MinimumLikelyDelay>
                </CheckConstraintDelay>
            </delays>
        </CheckConstraint>
    </Arrival>

We could use CheckProcess=none or other.

Questions:

1. Is this something to be stored in CheckConstraints
2. If yes, how to model the CheckProcess? New value?

[Aurige]

is it a delay for all ServiceJourneys of the calendar, or just on a specific (operational) day ?

The CheckConstraint does not really express a delay, but it's usually indicating that you need to be at the stop in advance in order to have sufficient time to cross the check

[ue71603]

It is a delay on a ServiceJourney (for the given Availabilitycondition). E.g. the we have a TRAIN NUMBER 1234. During July thereis construction, so we get two SERVICE JOURNEY:

• SJ1 Not July with no planned delay
• SJ1.1 July with such a planned delay

It is clear that this is not the idea of CheckConstraint. But there is no other mechanism in NeTEx. How would you do it?

[Aurige]

I recognise that it is not obvious I would create a SJ1.1 for the dedicated period, and add a dedicated Description and maybe an assigned Notice (where you can mention and explain the delay) and of course updated passing times. SJ1.1 can also be linked to SJ1 using derivedFromObjectRef, and a version o SJ1 can have a ServiceAlteration=replaced

I guess that, even if in your example it is a delay, it is more a service reorganisation due to the construction/works and it may also be early, or cancelled stops, etc. or a mix of all

[ue71603]

<ServiceJourney id="444" version="1">
   <AvailabilityCondition id="allYear"/>
    < TrainNumber>444</TrainNumber>
</ServieJourney>

planned delay for July 

<ServiceJourney id="444-1" version="1">
   <AvailabilityCondition id="allYearexceptJuly"/>
    < TrainNumber>444</TrainNumber>
</ServieJourney>

<ServiceJourney id="444-2" version="1">
   <AvailabilityCondition id="July"/>
    < TrainNumber>444</TrainNumber>
   <ServiceAlteration>replaced</ServiceAlteration>
</ServieJourney>

<ServiceJourney id="444-2a" version="2">
   <AvailabilityCondition id="July"/>
    < TrainNumber>444</TrainNumber>
    <derivedFromObjectRef  ref="444-2" version="1"/>
</ServieJourney>

[Aurige]

yes, something like that (note that derivedFromObjectRef is an attribute) ... I guess the the Description/Notice is also important for passenger information Also I see a risk that a journey planner dos not managed the replaced ... and use it in July. It may be nice to be explicit and set isAvailable=false in 444-2 AvailabilityCondition

[BredeD]

I think your use case are sinilar to what we use datedServiceJourney for, where we also can manage the links between multippel replacement buses to a previous planned train.