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
#15

Another one to report this week

The file tfl_8-370-_-y05-57760.xml uses two separate codes inbound for Romford Station, namely 490001243V and 490001243ZA. This makes the stop sequencing throw a wobbly.

(Perhaps the dual codes go back to a time when a different routeing was used in the evenings? But that was a long time ago.)

As it happens, this file has been absent since May 2020, when (I now see) exactly the same dichotomy is visible. That conforms that it is an old problem, only uncovered because the stop points section of the file is sorted differently and I had to change my coding!

I assume that the file’s reappearance has something to do with reintroducing schedules which had been replaced for some period of the Covid crisis. A bit odd though, as I thought new Service Change Numbers were generally used for reinstatements. Having said that, it seems to be quite common for SCNs to be reused (not always for the same timings, often not even for the same route!). Makes it difficult to follow but the main aim is to have Journey Planner working OK, not to satisfy my wish for tidiness.

Michael

#16

Hi Michael we’ll look into this one as well.

#17

Is it possible that Romford station is being rebuilt?

#18

Hi Michael,

I’ve had a look at our data and can see only one stop listed for Romford (490001243V) this is also shown in the new service change (tfl_8-370_y05-52034) from Saturday.

It is also worth noting that some SCN have been reinstated due to some services no longer having special schedules due to COVID so rather than issuing new schedules under a new SCN London Buses are only notifying the the previous non-Covid schedules are to be reinstated.

Regards
Matthew

#19

Matthew

Thanks. It’s not worth worrying about if the schedule is being replaced tomorrow (a bit odd that 57760 was reinstated for a one week farewell tour, but never mind!). However, it probably is worth documenting the symptoms a bit more thoroughly.

The second Romford Station stop is definitely there in the XML file contained in the Datastore zip file uploaded on 2nd/3rd March. Extracts below giving each each of the stops. Stop V gets a stop sequence number, stop ZA does not.

Here’s an extract with the ZA stop

		<JourneyPatternTimingLink id="JPL_8-370-_-y05-52791-172-I-4-49">
			<From SequenceNumber="48">
				<Activity>pickUpAndSetDown</Activity>
				<StopPointRef>490003157W</StopPointRef>
				<TimingStatus>OTH</TimingStatus>
			</From>
			<To>
				<Activity>pickUpAndSetDown</Activity>
				<StopPointRef>490001243ZA</StopPointRef>
				<TimingStatus>PTP</TimingStatus>
			</To>
			<RouteLinkRef>RL_8-370-_-y05-52791-I-4-48</RouteLinkRef>
			<RunTime>PT57S</RunTime>
		</JourneyPatternTimingLink>

And here is one with the V stop

		<JourneyPatternTimingLink id="JPL_8-370-_-y05-52791-25-I-2-49">
			<From SequenceNumber="48">
				<Activity>pickUpAndSetDown</Activity>
				<StopPointRef>490003157W</StopPointRef>
				<TimingStatus>OTH</TimingStatus>
			</From>
			<To SequenceNumber="49">
				<Activity>pickUpAndSetDown</Activity>
				<StopPointRef>490001243V</StopPointRef>
				<TimingStatus>PTP</TimingStatus>
			</To>
			<RouteLinkRef>RL_8-370-_-y05-52791-I-2-48</RouteLinkRef>
			<RunTime>PT48S</RunTime>
		</JourneyPatternTimingLink>
#20

Hi Michael,

Sorry I only checked 57760, as listed and not 52791 which does contain an error, however this has now been superseded by 52034 from Saturday. It looks like this may have been a similar issue to previous routes where only one schedule is published but with differing stop sequences to the current version.

With regards to schedules only being valid for a week, as you can appreciate the network is in a state of flux at the moment with schools returning so School day schedules are being reinstated at various times, with the 370 in this instance the 13/2 change was to reintroduce school holiday schedules to operate on Mondays to Fridays with the changes on 6/3 a resumption of School Day schedules which is also happening with quite a few routes across London at the moment.

Regards
Matthew (cc @GerardButler for reference)