Another inconsistent stop sequence

@matthewscanlon
Christmas would not be complete without me raising a problem, though it’s more of a data corruption than a data inconsistency this time.

The file tfl_54-U3-_-y05-58285.xml was fine last week but in this week’s zip file it seems to have gone awry. Specifically, if I look at the JourneyPatternSections area there are only 198 entries, compared with over 3200 last week. Furthermore, some of the 198 have no stop information etc to go with the JPS reference.

Looking at the XML code I can see it going it going from OK to empty then seemingly giving up the ghost (of Christmas present?) entirely.

First file that I’ve ever seen like this. I haven’t checked for any further data loss or corruption within the file.

1 Like

@matthewscanlon
Understandably the U3 file was still malformed in the Datastore file created on 24th December. What is more concerning, I think, is that it was joined by two more with similar “features” (ass Microsoft would call them). These are tfl_48-131--y05-59672.xml and tfl_54-282--y05-60242.xml.

I have no idea whether this affects Journey Planner results or other outputs. I suppose that might depend on the stage at which the error creeps in.

All OK this week. Goodness knows whether it has just healed itself over Christmas!

1 Like

Hi @mjcarchive

Looking at the examples shown, these files were vaild for Boxing Day only but contained some erroneous schedule data which was not picked up, the regular files for these routes do not contain these errors so should be ok.

Regards
Matthew
(cc @GerardButler )

1 Like

@matthewscanlon
Looking at the dodgy XML files, yes they were all either Bx or Bx & Su when they went wrong. All three files has however been present with a full set of operating days up to that point. All three also carry the correct Service Change Numbers (so we have Working Timetables for them).

I am well used to hundreds of files being added to the zip file around Christmas but these usually have concocted Service Change Numbers. It is unusual in my experience to see the non-concocted SCN file transformed from the regular service into a seasonal special. Maybe this happens a lot more but without the erroneous data.

While it offends my nice tidy mind, I appreciate that the file naming used for the files is unlikely to have operational implications (though the erroneous data might).

Haven’t had any problems for some weeks to be fair but the file tfl_21-207-N-y05-61231.xml is a mess. There are a number of empty journey pattern sequences, while for those which are present only the PTP stops (the timing points included in working timetables) are included, Most stops are OTH rather than PTP so are excluded.

I think this is a timetable for the Platinum Jubilee, so plenty of time to sort it out!

1 Like

Plenty of time but not an infinite amount! Two weeks on it is still an unusable mess.

I don’t think this file was ever sorted out but N207 is now represented by a different (correctly formatted) file.

Another one this week. This time tfl_48-W15-_-y05-61611.xml. This looks like a timetable for the diversion via the Green Man roundabout, so it is probably not with us for long.

What seems to have happened is that three stops in the outbound direction on the diversion have not been given a sequence number (there is a gap of three in the sequence). The corresponding inbound stops are sequenced correctly.