Journey Planner Datastore file oddities/errors

Thought I might as well make this a serial thread.

The new file for 246 (SCN 52747) has some journey patterns with sequence numbers missing. I think these are the Sunday Chartwell journey patterns. As the Mon-Sat times should not have changed this is probably a difference between days of the week.

The current N21 file (SCN 61478) has for several weeks been describing some stops as PTP in some journey patterns and as OTH in others. Probably a day of the week thing again.

Update.

N21 still has stops inconsistently described as OTH and PTP (should be consistent throughout file).

246 seems to have been sorted by providing an entirely new file rather than amending the erroneous one.

Picking up on points raised in other threads, 312 is still messed up northbound between Old Lodge Lane and Purley. The 309 had a new file last week which only included principal timing points. This has been “solved” by removing this file but as it was supposed to have new times, relying on the old file surely means that the times are wrong, doesn’t it? (unless the change was cancelled).

312 and N21 still wrong. I have not found any new problems this week.

@jamesevans @GerardButler
Not sure if anyone is reading these posts so I’ve “named” the two of you!

The 312 error is a real issue which affects other outputs from the TfL system. I’ve been pointing it out since the routes was extended to Old Lodge Lane but five weeks on nothing has changed.

For example, if I go to 312 bus timetable - Transport for London and look at the time of the last bus from the first few northbound stops, I get 0010 for the first seven stops, 0011 at Purley Tesco, 0012 at Purley Station, then a jump to 0018 at the next stop, Downlands Precinct. This is obvious nonsense and people could assume that the last bus has gone when it hasn’t.

I presume (but have not checked) that incorrect results would be returned by Journey Planner itself for journeys starting at the intermediate stops.

The N21 issue - most stops being described as PTP in some journey patterns and OTH in others - probably has no knock-on effects of the same nature but it does seem rooted in a more familiar issue. When the actual timetable only changes for certain days of the week but there is change (addition, deletion, metadata change) to the stop sequence, it is sometimes left unchanged (and therefore inconsistent) for days where the actual timetable has not changed. Hope that makes sense!

hi @mjcarchive

There is an issue with the source data provided by the operator around a month ago when the timetable was published. This was reported back to them at the time.

Unfortunately, this timetable change included a routing change (not just timings) so the Journey Planner team released this so the correct route was being returned at least.

We’ll chase the operator again to get a progress update on this.

The N21 is most likely related to a timetable imported from the previous source system. We’ll see if we can re-import this and see if that resolves the issue.

Many thanks,
James

@jamesevans @GerardButler
Cannot report on bugs this week … as there is no new zip file (as at 10.30 on Wednesday). It usually appears around 7pm on a Tuesday.

Hi, due to the bank holiday, it’s due today although we’re looking into an issue with the file generation at the moment.

Many thanks,
James

Thanks, James. I don’t think it usually gets delayed by a Bank Holiday but I could be wrong.

The file is there now.

It is missing the new timetables for EL1 EL3 65 and N65. I know these are new because the WTTs came out on Sunday. The temp timetables for 368 and EL2 are present; EL1 and EL3 are for the same road works.

I also note that most of the new files are clock change specials which operated last weekend and won’t operate again. Useful for transport archaeologists perhaps but not for journey planning! I presume they were actually in place on Journey Planner itself before last weekend.

Also worth noting that all the new files have a start date of 30/03/2024, with nothing new for any future changes. That could be OK but it is very unusual.

I have not checked 312 and N21 yet.

@jamesevans @GerardButler
As far as I can see, the new timetables from over a week ago for EL1 EL3 65 and N65 are still missing from the zip file.

As an example, the file for EL3 shows buses every 10 minutes during the day right now today. Journey Planner itself shows buses every 11 minutes, which is consistent with the working timetables for the temporary timetable (works in Movers Lane). So, if it is in JP itself, why is it not in the zip file?

I note that the info for EL3 thrown up by Google Maps also shows buses every 10 minutes, so whatever they use is wrong. Thankfully all three day routes are high frequency.

I have not done similar checks for the other three routes but presumably I would get similar discrepancies. There may of course be other routes with similar issues.

Indeed, the S2 could be another one. This has had a Summer school holiday working timetable loaded. This shows differences throughout the day compared with the bog standard MF times. However, the Datastore file does not show this variation. Nor (in this case) does JP. This is a low frequency route so it matters more. (It begs a wider question of why operators are able to get away with seemingly unnecessary differences in school holiday times in the middle of the day; it just makes it harder for passengers to remember the time of their bus).

The 312 northbound is still rubbish south of Purley. The N21 OTH/PTP issue is still present as well.

@jamesevans @GerardButler

Another week, no correction (or explanation if I am wrong).

In particular, the 312 has been wrong for SIX WEEKS. The operator may have been chased but thus far they can run faster than you can.

The errors (if they are) on 65 EL1/3 N65 are infants by comparison, in their third week.

hi @mjcarchive - the Journey Planner team have been unable to process the working timetables for these routes due to data errors at source. These issues have been escalated back to colleagues in London Buses and as soon as correct schedules have been provided, they will be processed.

Many thanks,
James

@jamesevans @GerardButler
Thanks. Are these data errors a new phenomenon or have they just gone under the radar before?

The 312 has of course been processed - it’s just wrong. Unless a correct version exists but cannot be processed due to other data errors.

A question, I suppose, is whether it is better to leave incorrect timetables in place or to leave a gap, though the latter would require realisation that there was an issue for the route.

The Journey Planner team have processed the 312 schedule as this was a significant route change that was not covered by previous timetable available. Otherwise journeys on the extended section would not show at all. This is the exception to the rule whereas EL1, EL3, 65 & N65 were schedule changes only (i.e. no stop changes).

It’s now with our buses data team to liaise with the operator to ensure these are correct before re-processing.

Many thanks,
James

1 Like

@jamesevans
Thanks again. I am still wondering whether it would not be better to remove timetables known to be incorrect, though I appreciate that sometimes differences are trivial. Perhaps there ought to be a way of informing users that there are known issues on certain routes. Once upon a time there was a Journey Planner Newsletter which helped users but I presume that was a victim of financial necessity.