Future VSTP overlays

[David Turner]

Hi,

Apologies if this is answered somewhere already (I can't find anything obvious to help on the Wiki).

In the VSTP feed yesterday there were a number of overlay schedules created for UID H39030 on 2016-10-31 through 2016-11-03, which according to the CIF would otherwise have run as the permanent SX schedule that started on 2016-06-20. My understanding is that this means that someone put them directly into TOPS rather than going in via TPS, bypassing a certain amount of validation and conflict-detection and so on. They didn't get a mention in the subsequent CIF update.

I think this indicates our current process is not quite right: when we process the next CIF update we wipe out any existing VSTP records, treating the CIF as canonical until new VSTP messages arrive (TBH this never made much sense to me as it raises the question of _when_ to clear the VSTP database out). Instead I think we should keep track of all VSTP schedules rather like the ones from TPS, but this raises a couple of questions around the meaning of replacement/deletion and of overlays:

1. Is the set of VSTP schedules completely independent for create/replace/delete purposes? More precisely, if there's a VSTP message with `transaction_type` set to `Delete` then this shouldn't delete anything from the CIF-based database, only a previously-created VSTP record?

2. When working things out using the STP indicator (i.e. the process where cancellations override additionals which override overlays which override permanent schedules), what happens in the case of a clash between two schedules with the same STP indicator on the same day, one from the CIF and the other from the VSTP feed? ISTR Peter Hicks answered something like this question some time ago approximately "there's a process that means that can't happen" but I can't find the message any more, and I can't quite see how such a process would work in practice: e.g. how would a TPS operator know not to create a new overlay for the H39030 on one of the days mentioned above?

I'm also kinda curious about why these schedules might have gone straight into TOPS rather than going in via TPS.

Many thanks,

David

[Peter Hicks]

Hi David

Purging VSTP schedules isn't the right thing to do - you may have a VSTP variation for a train on Sunday, and if you purge VSTPs when you receive tonight's CIF, you'll not have the variation for Sunday.  There's no interaction back from TRUST to TPS, so you could create a VSTP on TRUST which is then duplicated by the same through CIF tonight.  I think TRUST will show both schedules if they have different UIDs (i.e. the VSTP schedule was an STP), and only one schedule if they have the same UID, and I think it's the VSTP one.

I treat schedules from VSTP as independent from those through CIF, storing them with a schedule source of 'V', and CIF with a source of 'C'.  That way, I can't have a VSTP Delete inadvertently deleting a CIF schedule and messing up the next CIF extract I get if that schedule is modified.  I then calculate which schedule is valid based on the normal WTT, VAR, CAN priority for CIF, but also take in to account that a VSTP VAR could overlay an existing CIF VAR.  I think you can also have a VSTP STP overlaying a CIF WTT or VAR, although I'm not sure whether TRUST will create the schedule with an all-numeric UID, effectively leaving the CIF schedule untouched.

I'll check on TRUST later today and see if I can add further clarity.  Incidentally, although the VSTPs may show a source of TOPS, they can only be entered in to TRUST - the train service code defines whether TRUST sends them to TOPS.  Creating VSTPs on TOPS itself is (or was) an awkward process - I've seen the commands TRUST sends to TOPS and they're best described as 'a bit scary'.

Peter

 

--
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 post to this group, send email to openrail...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Turner]

Thanks Peter. Clear and comprehensive as always :)

Cheers,

David

To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-talk+unsubscribe@googlegroups.com.
To post to this group, send email to openraildata-talk@googlegroups.com.