Questions about applying CIF schedule updates

[Natsume]

Hi all,

I am trying to obtain a full timetable for each day by taking one full CIF schedule as the baseline and applying the subsequent daily update files.

While doing this, I have encountered several cases where it is unclear which schedule should remain active.

1. Overlay and cancellation on the same date

If an STP indicator = O schedule and an STP indicator = C schedule are both valid for the same UID and operating date, should the overlay still run?

2. Overlay and revised permanent schedule

If an STP indicator = O, transaction type N schedule and a later STP indicator = P, transaction type R schedule are both valid on the same operating date, should the STP indicator = O schedule take precedence?

3. Unmatched transaction type R records

I have found transaction type R records whose start date does not match any existing schedule. Since a schedule is identified by UID + start date + STP indicator, it is unclear which schedule these records revise.

My current code treats an unmatched R record as a new schedule. Is this the correct approach?

4. Multiple overlay schedules valid on the same date

I have also found cases where more than one STP indicator = O schedule is valid for the same UID and operating date. For example, UID W92440 has two overlay schedules valid on 7 February 2022 after applying the available updates.How should these cases be resolved?

Does anyone know how these cases should be handled?

Thanks very much.

[Peter Hicks]

Hello

As a first step, check that you are processing the CIFs correctly.  There shouldn’t be a case where you have a cancellation overriding a variation.

Are you expiring historical schedules correctly?  It might help if you posted the BS records here for two or three schedules you’re having trouble with.

Peter

-------- Original Message --------

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/053f146a-8d2e-45df-95b0-6b07db011435n%40googlegroups.com.

[Natsume]

Hi Peter,

Thank you for your reply. Here is one example for UID C30985.

In the full schedule dated 1 January 2022, I have the following BS records:

BSNC309852112122205080000001 PEE5Y3200 124676004 EMU 075D P

BSNC309852112122201020000001 1 C

BSNC309852201162201160000001 PEE5Y3200 124676004 EMU 075D O

BSNC309852201232201230000001 PEE5Y3200 124676004 EMU 075D O

BSNC309852201302201300000001 PEE5Y3200 124676004 EMU 075D O

BSNC309852202062202130000001 1 C

BSNC309852202272205080000001 1 C

The subsequent updates contain:

6 January update

BSNC309852112122201090000001 1 C

7 January update

BSDC30985220116 O

12 January update

BSNC309852112122201160000001 1 C

13 January update

BSDC30985220123 O

27 January update

BSNC309852112122202130000001 1 C

BSDC30985220206 C

After applying these updates, I still have the following records valid on 30 January 2022:

• the permanent schedule valid from 12 December 2021 to 8 May 2022;
• the overlay schedule valid on 30 January 2022;
• the cancellation added on 27 January, valid from 12 December 2021 to 13 February 2022.

All three run on Sundays, and 30 January 2022 was a Sunday.

[Ian Sargent]

1. Overlay and cancellation on the same date

If an STP indicator = O schedule and an STP indicator = C schedule are both valid for the same UID and operating date, should the overlay still run?

If the STP C record appeared in a later update then it cancels the services for that date, regardless of whether it is the permanent schedule or the overlay schedule.

2. Overlay and revised permanent schedule

If an STP indicator = O, transaction type N schedule and a later STP indicator = P, transaction type R schedule are both valid on the same operating date, should the STP indicator = O schedule take precedence?

A Revise schedule for the P record does not override the Overlay record. If the Overlay is also to be amended it will have it's own Revision (or a deletion 9 if it is to now folow the timings of the Permament schedule.

3. Unmatched transaction type R records

I have found transaction type R records whose start date does not match any existing schedule. Since a schedule is identified by UID + start date + STP indicator, it is unclear which schedule these records revise.

My current code treats an unmatched R record as a new schedule. Is this the correct approach?

A grey area. I have seen cases of a previously unadvertised train changing its category to become an advertised passenger train. If your CIF feed does not include unadvartised sevrices then you will not have seen the N record schedule, but will see the R record. In my view, the train category should never be changed after initial publication but some train planners have been known to do it in the past. 

Your approach is probably okay, however you need to beware that a train category has not been amended in error by the planners.

4. Multiple overlay schedules valid on the same date

I have also found cases where more than one STP indicator = O schedule is valid for the same UID and operating date. For example, UID W92440 has two overlay schedules valid on 7 February 2022 after applying the available updates.How should these cases be resolved?

If those Overlay schedules were received in separate updates then the second will replace the first. If received in the same night's update I would suggest that it's an error in the feed.

REMEMBER: after you have applied each night's update the resulting output is the base record to which you apply the next night's update. You don't go back to the full CIF extract again and apply all subsequent updates to it. 

[Daniel Chick]

"REMEMBER: after you have applied each night's update the resulting output is the base record to which you apply the next night's update. You don't go back to the full CIF extract again and apply all subsequent updates to it." 

Surely this is the same thing? Applying all updates in order since the full update is equivalent to applying the latest update to the base record from the previous day? Or am i missing something here?

Dan

[Ian Sargent]

That's the way all the rail industry's internal systems work. You get the full CIF extract and then apply the first update to create a new output file. The next night you apply its update to the previous day's output file to create a new output file, and so on each night until another full extract is downloaded.

If you keep the full CIF file and then consistently apply numerous updates to it at the same time you may have numerous overlay and revise records for the same UID and no idea which one to apply in which order.

CIF, as it stands, was meant to be used in a live environment, appling one update each day for both operating and retail systems. If you want to see what the current planned timetable is then you need to do the same. Those interested in historic CIF records may have to work out their own way of storing and applying the update files.