This problem, which was a major bugbear in 2019, has not gone away. Lst week;s update saw examples for ther 18, 32 and 85.
I will concentrate on the 32 because it is so obviously wrong.
A set of WTTs under Service Change Number 54180 and dated 8th February were in place for some months. These were temporary timetables with reduced frequencies during works in Cricklewood.
A further set under Service Change Number 54425 and dated 9th May were uploaded around 12th May. These were for the reversion to normal timetables once the reduced frequency was no longer considered necessary.
So far so good but in this week’s update it was back to SCN 54180.
Looking at the Datastore file of Journey Planner timetables, it appears that a third set of WTTs (SCN 55176) has kicked in.
So, one the face of it the system has recognised that 54425 is no longer current but has somehow managed to revert to the even less current 54180, which must have been marked as expired when replaced by 54425. It may well be that files for 55176 were unavailable but reverting to a set that is two versions out of date would be an odd response to this.
I appreciate that in practice special timetables have been (and may well still be being) operated but that should not disrupt the process, nor has it for nearly all other routes.
Is it possible for someone to look a this example and track down exactly what has happened?
Michael
1 Like
Perhaps ping @jamesevans for comment?
@jamesevans
We are back in the twilight zone. Overnight, over 200 obsolete schedules appear to have overwritten newer counterparts. For example, the 483 apparently is back terminating at Ealing Hospital rather than Windmill Park.
While many schedules are returning to normal, reversions are never, as far as I am aware, effected by resurrecting expired schedules. A new Service Change Number is usually allocated. At first sight, some of the files given new SCNs for thisd very purpose last week are amongst those that havebeen overwritten this week.
I thought this problem had been largely overcome last year and it was note just isolated instances. Seems I was wrong.
Michael
Here is the “list of shame”.
For those in bold, all or nearly all WTTs have incorrectly been overwritten. For the rest, it is partial, though this may because the files overwriteen were themselves a partial update, if that makes sense.
2 3 8 14 16 26 35 40 45 57 59 65 69 71 72 81 86 88/N88 90 121 132 133 143D 152 159 167 183 186 189 190 200 222 228 229 230 237 243 245 249 260 274 277 279 295 299 328 333 337 344 345 365 430 483 533 602 603 606 632 643 681 718 E3 E6 K4 P4 R70 W8 W12 N2 N3 N11 N15 N18 N22 N74 N86 N133 N155 N205 UL3
This is in addition to the errors already there for routes 18 32 85 277 (also occurs above) 323 D6 D7
1 Like
Most of the overwritings from last week have been corrected this week. Not all, though, nor have the earlier errors been corrected.
This is the current list of (what I am pretty sure are) errors:-
3 14 18 32 72 85 86 152 228 274 606 UL3 (bold means most or all of the WTTs for the route are affected).
The big time re-emergence.of this problem last week is worrying. It suggests that if any solution was put in place a year ago to overcome this it can easily come apart at the seams. It would be helpful to know the nature of the problem and what is in place to prevent further reoccurrence.
1 Like
Hi,
I’ve had a look, the live version of the 483 is shown starting and terminating at WIndmill Lane, this hasn’t changed since 23 May when this change occurred. With regards to the Overwritten files, as you can appreciate buses are in a state of flux at the moment with the ongoing pandemic, where buses are starting to resume their normal service some operators are not providing new schedules instead they are just resuming the pre-Covid 19 schedules. With this the normal pre-Covid 19 schedules are being reactivated (and not overwritten) with the new resumption date.
Hi
Thanks for responding. I appreciate that Covid-19 has led to all kinds of difficulties and ad hocery. However that is not what is going on here.
The 483 was right when first loaded and it is right now.(SCN 48875, with the extension). However, this time last week the MF Sa and Su (but not sSu) schedules had reverted to SCN 48753, dated 3/1/18 and obviously missing the extension.I have a list of files downloaded which demonstrates this if it helps.
As I have said, most of the overwritings last week were reversed this week. If the overwriting last week was to do with reintroducing normal schedules, why are they not still present?
There have even been examples of schedules with the old operator overwriting the correct new contract schedules!
An example which has been around a few weeks now is route 32. This had temporary timetables (SCN 54180) from 8/2/20 with reduced frequency (every 9 minutes) for works in Cricklewood. A new set of schedules (SCN 54425) was loaded for 9/5/20 with normal frequencies reinstated. Shortly afterwards SCN 54180 overwrote them again and this has not changed since. The live Datastore file (in the Journey Planner zip file) is tfl_54-32-_-y05-54425.xml, with the normal 8 minute frequency. So even if SCN 54180 is right there is a disconnect between the two sources.
Whatever is going on is not in my view the result of Covid-19, though I can see that other priorities may have led to, ahem, slightly less rigour in file handling and version control! Whatever is going on, if it is not understood it is going to happen again.
Michael
Matt
Bang on cue - look at the live 483 schedules as of now.
It’s like the hokey cokey - the extension schedules came in, then they went out, then they came in again, now they are out again. This is exactly the pattern that was seen a year or so ago, then solved (without revealing what the issue was), now apparently back with us big time.
There are 535 new files in the update run last night. Of these, 12 had no counterpart last week, so 523 are like-for-like replacements. Of these 364 are reinstatements of schedules which had previously been replaced. I am yet to analyse them properly but I would be surprised if the majority of them were not bogus and not explicable in terms of post-Covid reinstatements. I accept that some of them are likely to be correct because they are reversing last week’s errors.
However, if the vast majority of the 364 were bogus, that would mean that roughly 10 per cent of the WTTs available via the TfL website are the wrong files. Some will only be trivially wrong (a stop change, say) but others, like the 483 are now very obviously wrong…
My uninformed guess is that either there are two files marked as current (or as “not expired”) and that the system has no way of knowing which to choose. If there were no files marked as current, presumably the file would not appear at all. Perhaps that is the first thing to check, specifically on the 483 and perhaps the 32, which has been wrong for several weeks.
I am happy to help with documentation, despite being …
… a very fed up Michael
My own file handling let me down so I overegged the numbers but the point made remain just as valid.
There were 390 (not 535) new files, of which 378 are like-for-like replacements.
Correct reinstatements (i e replacing previous errors) as follows:
9 142 206 318 358 649 651 655 G1 N9
Incorrect reinstatements (i e overwriting newer files) as follows:
2 27 35/N35 40 45 59 67 69/N69 76/N76 81 88/N88 97 132 143D 167 186 189/N189 190 195 200 222/N222 237 243/N243 262 277 279 290 296 302 328 333 337 344/N344 422 430 436 453/N453 473 483 606 631 632 643 718 E1 E3 E6 E7 E9 E10 E11 P4 W8 W12 N2 N22 N68 N136 N155 N199 N205 N242 N551
Some of these were only loaded last week. The 67, according to this, is back with Arriva rather than London General.
Bold denotes that pretty much the fill set of WTTs for the route is involved.
1 Like
It gets worse and worse.
I will do a count later but I would be surprised if the error rate now is below 10%. If anybody is trying to sort this out, it is not evident from the (lack of) replies here, and certainly not in the output itself.
This week we have 474 “new” files, of which 457 are like-for-like replacements. Only 92 of these are genuinely new. The other 365 are reinstatements. 79 of these are corrections of previous errors (most of which remain uncorrected). So 286 are fresh errors, as follows (bold denotes all or most of the schedules are involved):-
5 8 9 12/N12 N14 15 16 17 21 22 36/N36 N37 41 N43 52/N52 60 62 63 65 74 78 90 93/N93 94/N94 108 133 140 142 143 145 156 159/N159 169 171 187 200 201 206 226 229 230 245 259 316 318 330 332 343 350 358 363 427 460 466 490 491 521 533 602 603 649 651 654 655 675 681 C1 C3 G1 H20 H28 K4 S3 U5 N3 N8 N9 N18 N21 N27 N28 N44 N63 N65 N72 N74 N89 N97 N109 N133
The 230 has thus joined the 67 in having schedules for the wrong operator.
OK, some counts. Numbers probably not 100% right, as mucking out the stables as they have been left by TfL is largely a manual job and thus itself liable to errors.
There are 3466 live bus WTTs available, higher than usual because of Covid specials
Of these I am confident that 374 are incorrect, as they have overwritten files for the same day but a different SCN (with a later date). A further 69 have the right SCN but have an earlier version of the file. So that is 443 which are wrong.
So more than one in eight of the links on TfL’s WTT pages will take you to a non-current file.
I should emphasise that I would not want the uploading of WTTs to be suspended, as it is still possible, with a lot of effort (like a day rather than the hour it should take) to make sense of it all but I am afraid that it really is rather shoddy.
Michael
“Just” 43 new incorrect overwritings this week, including 345 and 484. Many of the rest are for odds and ends schedules and they may not all be relevant any longer.
Two routes on the naughty step (18 and 337) have been removed through the arrival of completely new schedules. I think one other schedule has been corrected but the square root of *** all has been done about anything else.
Looks like we might be up to 500 errors by next week.
Michael
Given the deafening silence, is there any point in my posting?
I don’t expect this to be treated as top priority at any time, even less so given the pandemic. However, some evidence of recognition that there is a problem here would be a plus, along with something which shows that at some stage (not necessarily right now) there will be a plan to resolve it.
Frankly, I would have been embarrassed, to say the least, if this was happening in my working days on something for which I was responsible but I would be very keen to avoid the impression that I was just shrugging my shoulders. That is (I hope) unfair but it is the impression that is being given.
Michael