@neamanshafiq
The big clean up three weeks ago has held, inasmuch as none of the stuff which should not have been there has crept back in after being replaced.
However, there are still a few dodgy links. Few enough that I can easily list them here:
323 - all 7 schedules dated 11/01/2020 (s/b 25/01/2020)
362 - all 3 schedules dated 07/07/2012 (s/b 19/04/2020)
D6 - all 3 schedules dated 29/09/2018 (s/b 30/11/2019)
94/N94 - 3 schedules (Su SuNt and MTNt) dated 07/12/2019 (s/b 16/05/2020)
243/N243 - 2 schedules (Su and SuNT) dated 13/07/2019 (s/b 04/04/2020)
E3 - 1 schedule (Su) dated 28/09/2019 (s/b 16/05/2020)
UL18 - 1 schedule (sSuj) dated 08/09/2019 (s/b 13/09/2020)
UL69 - 1 schedule (sSuj) dated 22/03/2020 (s/b 13/09/2020)
“s/b” is not guesswork. Schedules with these dates have been available in the past but have been overwritten. Maybe these are special cases but without an explanation it is hard to feel really confident that all is rosy in the garden.
The same goes for the lack of any explanation of what was going wrong in the first place. We’ve been here before - mass cleanup of (nearly) all errors, then OK for a time, then kicking off again. It would be nice to have a reason to feel confident that that will not happen again.
@mjcarchive i’ll forward these details to our contact in the Buses team to investigate further. in the meantime, i’ll see if i can export the latest schedules for these routes for tonights transfer.
@neamanshafiq
Thanks. Just to confirm that the situation basically unchanged after last night’s upload. There is one newly reincarnated file (108, sSa) but I think this is because the version overwritten was for the clock change weekend and the file overwriting it is the seasonal special (of whivh there are bucketloads this week). So that one is explicable.
@mjcarchive i did have a response back from the bus timetable team. Apparently not every service change will have a set of new schedules uploaded if the timetable/service pattern will be identical to the last ‘live’ service change. the different service change reference which is generated is just a side effect of whenever the previous service change reaches its end date. we can double check any timetables to make sure they are indeed the current ‘live’ version as we have access to the BusNet tool which gives us this information.
Yes, I understand that. However, the 18 schedules in question have been available in the past but have since been overwritten.
To take the 323 as an example, the currently available set of schedules is dated 11 January, with SCN 51007. They are described as relating to a new contract. However, these have overwritten a set dated 25 January, SCN 53497, described as relating to a stop sequence change and (according the metadata) copied from the SCN 51007 files. All 18 files that I query have similarly overwritten later files.
Now it may be that (say) the later change never actually happened and the earlier WTTs were reinstated. If the much wider issue had never happened I would probably just have assumed that something like that was the explanation. But the wider problem did happen, which is what led me to think the remaining 18 cases could do with being double checked.
As an aside, the actual timetable is often unchanged between SCNs, I think, with the only changes coming in the fine operating detail such as crosslinks between routes, organisation of driver duties or similar, or in one of the stops which is not actually presented in the schedule (which i think is the case for the 323).
Is the Busnet tool, or at least output derived from it, available as open data?.
@neamanshafiq
No change this week - still 17 (there was no update last week, unsurprisingly). The absence of any new errors for some weeks now is of course good news.
SSu denotes Summer Sunday while sSu is special Sunday, which is usually used for tube replacement services. Given that the schedules are dated 24 December and are usually loaded afresh whenever needed, it seems highly unlikely that “Summer Sunday” is right, though the metadata on the file do seem to indicate that Summer Sunday is intended.
So what, you might say. But confusion can arise when (say) both SSu and sSu legitimately exist for a route. There is also the unfortunate fact that some software does not differentiate between uppper and lower case.
So what again, you might say. However, I am sure I have seen files titled SSu where the metadata say “special Sunday” and/or vice versa, so the potential for it to confuse TfL and/or operators itself seems occasionally to be realised.
I appreciate that the day type codes probably go back years but wouldn’t it have been better to have used a different prefix for special (sp would do the job)? Ho hum…
Yes, TfL for the filenames … if you use ASN.1 they could be named in a way that never caused the current naming convention. The name could carry a device- and medium- independant filename that carried the ability to mean “Summer” “Special” and “Saturday” and “Sunday” or “Tuesday” and “Thursday” without ever needing to resort to overlapping symbols (S, Sa, Su, SS etc)
Another idea might be … given that is now 2021 … slightly longer filenames with Upper names like UL16-SpecialSaturdaysSundaysWinter given that we can have filenames that are
ASN.1