I think it would be a good idea to unify the various issues with the WTTs in one thread. I should preface the raising of issues by making it clear what an excellent source it is (or perhaps nearly is!).
Four issues to be covered in later posts over the next few days. Some should be easy to sort, others perhaps less so as they may reflect circumstances that the system designers did not think of at the time.
i) links take you to wrong route (132 links take you to B15 WTTs)
ii) a link would be relevant to two different WTTs but can of necessity only take you to one (108 and 108D);
iii) alpha stop codes being replaced by the stop code (e g N38);
iv) trips in wrong order (lots of them);
I know there were issues with relief points being shown incorrectly (or not at all) but my impression is that these are gradually being corrected. It would also be helpful if the WTTs gave more of a clue for the reason for a change rather than just “Schedule” but that is a policy thing rather than a technical issue.
Issue (i) should be the easy one but I have pointed it out for some weeks now and it is still incorrect.
actually takes you to this.
Similar for the Sa and Su schedules.
Issue (ii) may be a bit harder. Where a suffixed version of a route exists, the link ignores the suffix. Thus
takes you to
which is the late evening double deck (108D) service. The main 108 Saturday service is not accessible. The weekday 108 schedules are not affected because they do not use the same day type codes as the weekday 108D. 143 and 481 have been similarly affected in the past. 110 and 281 are also potentially vulnerable because of the R suffix schedules.
Issue (iii) is illustrated by
On the first page we see
with the very first timing point showing “7964 Bakers Avenue” in the first two columns instead of an alpha code and description. This is a new timing point, just like those seen on the N89 a few weeks ago (there are some other cases). It looks as if input for new timing points is not always being done correctly. I appreciate that this may be a flaw in a dataset that the WTRs use rather than in the WTT process itself but if that is the case there may be other uses of that dataset that are also impacted.
Whatever the cause, it needs correction before it spreads.
And issue (iv). Look at page 5 of
and you will see this.
What is wrong with this picture? Simply that the vast majority of the trips are in the wrong order! This appears to be because the creation process has sorted journeys based on when they start, regardless of where they start. So, for example, trip 113 (the 0949 from Hackney Central) appears after trip 115 (the 0940 from Clapton) even though it runs 5 minutes after trip 113 thoughout!
This isn’t just an issue which affects routes with short workings like the 38. If the bus runs dead from the depot before taking up service, the same thing happens. Look at
and on page 4 look at trip 47 which is two journeys out of sequence.
Now I would have thought that this would get in the way of practical desk use of the schedules (by route controllers?). Oh, and before anyone asks, sorting on trip number would not always work either as (for example) school day extras may well have a trip number at the end of the sequence.
Just for clarity, this particular flaw has only been present since the system (Adiona?) changed. In the old system it was fine and I am struggling to see why this was not simply read across to the new system.
A few more errors/oddities to report.
The new N214 SaNt schedule has incorrectly been loaded under the 214 Sa link. This means that no 214 Sa schedule is available, also that the schedule loaded under the N214 SaNt link is obsolete.
The 242 Su file is missing an implementation date (and has been for several weeks). Only important if you run procedures which expect a date to be there (now I wonder who does that?).
Four mysterious files have appeared in the last two weeks for a route “n263”. They appear to be duplicates of the 263 files. As it happens there ought to be a N263 as it would be a better number for the N271 but even if a renumbering were contemplated, these files would have nothing to do with it.
