SL10 - faster than the speed of light (but only in Hendon)

The SL10 is supposed to be fast but…

On the Datastore JP file, it is timed identically at Hendon Central and Hendon Stations, which are 3 normal (that is, route 83) stops away from each other. This can’t be right. In the other direction it takes 3-4 minutes.

I have pointed out other examples in the past of runs of three or more stops on Datastore files where times are identical, then there is a sharp change to the next stop. It is pretty obvious that times at many stops are interpolated from those for stops which are considered major timing points (the ones you can see in the working timetables) so that suggests that the info used for interpolation (distance? past experience?) is sometimes wrong. I presume that there is no check built into procedures to catch this sort of thing. It would have been easier to do this when times were calculated and shown to the nearest second but now they are shown to the nearest whole minute (or, on the right side error principle, as the whole number of minutes) it is quite possible for two successive stops to legitimately show the same times, as the two North Finchley stops do westbound for the SL10.

I can see that quoting times in seconds was spurious accuracy but was that the only reason why the change to minutes was introduced - or did it just happen by accident?

See also diamond geezer

image

I stopped off at Hendon station to see how things were going mid-route and was pleased to find the tiles and timetables were fully up to date. On closer inspection, however, the timings on the little strips across the top of the timetables were insane. The SL10 timings claimed that a journey from Hendon back to Kingsbury was 15 minutes and the time to Harrow Bus station was 33. The corresponding times for route 183 were however 14 and 31 minutes respectively, suggesting that the express bus is slower than the all-stopper, and which ludicrous database spewed this out?

Hi @mjcarchive

Thanks for highlighting this.

The Journey Planner team have identified an issue in the scheduling data processed by the operator.

They have fixed this manually in the Journey Planner system and a new TxC will be available later today for this. The underlying data error will be fed back to the scheduling team,

Thanks,
James

@jamesevans
Thanks. As I wrote though it is a wider issue and identifying both the cause and a means of trapping the error (made harder by only using whole numbers of minutes) are as important as correcting this one.

@briantist
Your comparison is obviously affected by Hendon Central times being used at Hendon Station for the SL10, so you probably need to knock 2-3 minutes or so off the SL10 times. However I think there is another factor at play. The Mon-Fri midday running times from Kingsbury Station to Harrow Bus Station are 20 minutes for the 183 and 17 minutes for the SL10. Not a huge time saving but then limited stop buses cannot wish other traffic out of the way.

The question I would ask is whether there is solid guidance as to which times of day should be used for the rough guides at the head of the timetables posted at stops. It is bound to be a rough guide as journey times can halve at the quietest times but like should be compared with like. (If we want accurate scheduled times for all times of day, then bring back the traditional timetable!).

Apologies if this is the wrong place to ask but the SL10 seems to be permanently omitted from the journey-planner-timetables.zip downloads. Is there a reason for that or is it an error?

@misar
It is there but has an unusual file name tfl_61-SL1-0-y05-6.xml which makes it look like another file for SL1, which is tfl_8-SL1-_-y05-1.xml. Different operator code is the giveaway.

I presume that a two letter prefix followed by two digits is too much for the system to handle in its proper form, so SL11 etc will see the same fudge.

Thanks @mjcarchive. I will have to modify the code I use to process the files because it interprets that filename as a duplicate SL1 just as you say.

@misar
It’s a minor annoyance. I had to do something similar when night routes such as N133 started being presented as 133_N and while I can’t remember I probably had to do the same with X140. Night routes such as N27 are presented normally.

1 Like

@mjcarchive I noticed and fixed the -N- routes when I started working with the XML files but I was puzzled about the reason until you mentioned the 3 character route ID limitation yesterday. I have never seen a file for X140 or any other X routes so I assume they were all replaced by the time I started looking in September.

1 Like