109 has split personality

#1

Here’s a Journey Planner oddity. Select a direct bus journey from Fairfield Halls to Norbury Station on a Sunday and I am offered route 109, boarding at stop KC.image
Same thing on a Monday to Saturday and I am advised to walk to Park Street in order to catch the 109.image

I had a look at the Datastore XML file for the 109 and, sure enough, the file shows this dichotomy between Mon-Sat and Sunday operation. There is also an oddity in the Journey Pattern Sequence section of the file where the field which should order the stops in each direction suddenly becomes blank at exactly the point at which Fairfield Halls appears for the first time (about 5,200 rows in).

On the face of it this looks like an incorrect file driving Journey Planner, rather than a reflection of reality and even if the route does go a different way on a Sunday, this should not, I imagine, be any reason for the stop sequence numbers to disappear in this way within the XML

#2

gigo, as they say!

At some level I think that the JP shouldn’t have privileged access to accurate information!

I guess it might have been Covid-ed due to lack of drivers or some other pracitablity.

#3

hi @mjcarchive,

I’m discussing this now with the JP team.

Thanks,
James

#4

Hi @mjcarchive - I’ve been advised this has now been resolved.

Please let me know if there’s any further issues.

Thanks,
James

#5

Excellent! Park Street consistently on all days. Hopefully it is right as well as consistent.

You’ve probably guessed that I ran across the dodgy file first, then looked to see whether it actually mattered at all in terms of outputs.

1 Like
#6

THis time it is another Abellio route, the 159. The files

tfl_21-159--y05-57732.xml and tfl_21-159--y05-57752.xml

both have an inconsistency in the Outbound stops, which has the side-effect of leaving some stops without stop sequence numbers for some or all of the journey patterns.

In some journey patterns, stop 36 in the sequence is 490011515W. In others, the one that ought to be 36 in the sequence is 490000179D. In these journey patters, the stop sequence numbers for this stop and the four remaining ones in the sequence are missing.

It looks like Piccadilly Circus. Maybe there has been a stop change but if so it has not been applied consistently. I have not checked but I would take a wild guess that a change has been made for some days of the week but not others.

It may seem trivial but as the 109 glitch affected Journey Planner results, this might too. I’m happy to report anything like this off line, given a contact address.

Michael

#7

Oops - my mistake - just the second file tfl_21-159-y05-57752.xml

1 Like
#8

Another example this week, namely the new file tfl_59-314-_-y05-57905.xml for the 314. In the inbound direction, the Bromley South stop is 490001037W in some journey patterns and 490001037A in others. When it comes across the first occurrence of 490001037A, the process throws up its hands in despair and gives up allocating stop sequence numbers to the rest of that sequence.

I would be surprised if it is not associated with day of the week.

(Edited to include specific file name and codes)

#9

Hi Michael,

We will investigate this.

Regards
Matthew ( @GerardButler for reference)

1 Like
#10

Thanks, Matt.

I just happen to have found three cases since Christmas but I only found them because a change in the ordering of the StopPoint data on the xml files meant that I had to tweak my processing. It is possible that it has been happening occasionally for years!

1 Like
#11

Hi Michael,

We’ve found the issue and corrected this and the changes will be reflected in the next TxC release. There was a difference in stop sequences between 2 route versions,(where in this instance only new schedules for MFSc and Sa were provided and old files from MFHo and Su were needed to be used) which has caused a conflict in the data.

Regards
Matthew ( @GerardButler for reference)

#12

Thanks, Matt. Very much what I expected.

I know what I would do in (say) an Excel environment to trap these when the file is created but that’s not necessarily portable to mass fiel creation in a different environment. The question is, I suppose, whether it occurs often enough to make it worth avoiding what I assume is disruption to Journey Planner outputs.

If I find any more in coming weeks, should I just notify Gerard without posting here?

Michael

#13

Hi Michael,

for now if you continue to post these issues on the forum, that way we can keep a track of any more issues and this can also allow for other forum members to add to this if they find any further issues

1 Like
#14

OK, Matt, will do. I won;t normally bother reporting a clean bill of health but that’s what we have got this week.

Michael

2 Likes