Open peter-mount opened 6 years ago
There's 2 sides to this bug.
The duplication is correct as the intermediate stop is cancelled and the new terminal one is in place. This is valid as the working timetable has changed & you can't change the wt, hence a new entry with just wta set at Chippenham.
For some reason we are not showing the original intermediate location as being cancelled. This might be down to us not resolving the correct location, so updates are picking up the original one hence not cancelling it.
For both we need to ensure that the primary key (Tiploc, wta, wtd, wtp) is adhered to. I have a feeling we're using the resolved time at that location and not the full working timetable key.
From the RDG:
It is not valid to change a location from one type to another, e.g. change a passenger calling location to a passing location, or a passing location to an operational calling location. Such requests shall be rejected with an error. To achieve such a change, the original location should be cancelled (if a passenger calling location), or deleted, and a new location added with the desired activities. Note however, as stated further below, if a location is cancelled, a new location cannot be created with the same TIPLOC and scheduled times as the cancelled location.
Scheduled times at locations are maintained as Public and Working times. Public times are those published in timetables and are made visible to the general public when the service is eligible for display. They are only defined for those locations that have (or have previously had) a passenger activity. Working times are those that the service is expected to run to and may be different from the public times. Working arrival and departure times must be provided for all “new” locations, regardless of passenger activity, except passing locations, origins and destinations (which only have one time, unless they were previously an intermediate calling point). Public times must be provided for all “new” locations with passenger activities, specifying relevant arrival and departure times as appropriate to the activity at that location, otherwise the request shall be rejected with an error.
If the activity at a location is modified to change the passenger activity, e.g. changing a destination to be a “through” stop and adding a new destination, appropriate public and working times must be added to reflect the new activity, i.e. in the example given, a public and working departure time provided for the old destination. If these times are not provided then the request shall be rejected with an error. If public and/or working times are provided where none are expected (no change to the activities), then they shall be ignored.
Once created, Public and Working times cannot be edited. No two locations with the same TIPLOC code, whether cancelled or not, can have the same working or public time for an event (arrive/depart/pass). For example, if location “GATLEY” exists with std=“10:00:00” then another location cannot be created where the TIPLOC = “GATLEY” and std=“10:00:00”, even if the other scheduled times are different. However, it would be permissible to create a location where the TIPLOC = “GATLEY” and stp=“10:00:00”.
src: https://groups.google.com/d/msg/openraildata-talk/Or3rbAyQPeo/cZvC1ly-BAAJ
Found during testing, a Bristol Temple Meads to London Paddington service was cancelled at Chippenham due to a person taken ill. However the entry for Chippenham got duplicated as the schedule was different:
2018 March 14, RID 201803146755252
New entry that caused the duplicate at CHIPNHM has timetable of pta: 16:53 wta: 16:53 whilst the original entry had the same pta: 16:53, wta: 1653, but also ptd: 16:55 and wtd: 16:55. I think the cause here is that the new schedule entry for the termination removed the ptd/wtd so when we look for an existing entry then we don't match.
Also, from the screenshot we may be showing the wrong last report at the end due to front end logic - that needs confirming.