Problems with /Line/Route/Sequence 1/1/2024 to 30/6/2024

Result of intermediate update on 10/2/2024:

Line deleted: 412

Lines duplicated: K1, K2, K3, N65

@nickp
I have a question about these threads. Do you find the errors using the journey planner API and if so are there always identical errors in the weekly uploads of XML timetables which I use? Your original post in May 2017 starts “After the weekly updates, some line routes consistently return …” but did not state your source and I don’t think it has ever been mentioned. :slightly_smiling_face:

Hi! Nick can correct me if I’ve misunderstood, but I understand this is the Route Sequence data in the Unified API. For example, you can query Route 63’s data by making a request to:
https://api.tfl.gov.uk/Line/63/Route/Sequence/All

Since the Unified API’s data is generated from the TransXChange data (XML files), any errors in the TransXChange data may result in errors in the Route Sequence data. So you may see the same error in both.

That said, the published TransXChange data and the data in the Unified API aren’t always in sync, so you may notice some temporary inconsistencies between the two data sources.

Yes, as Leon says (clue is in the title of the thread).

In the case of the latest post, line 412 was in the last main build, dated 6/2/2024, and in the TxC file, but disappeared from the index (/Line/Route) yesterday

The duplicated line problem is a long-running issue, specific to the API, where branchId is duplicated within one line. In its simplest case this results in two inbound branch 0 and two outbound branch 1. In the TxC files you would simply see two (or more) different routes for the same line.

This is compounded, in more complicated cases, by some branches being missing altogether, leaving dangling Next & Prev links. I have nearly 1500 warning messages relating to these errors each week, mainly in rail and riverbus modes.

I believe this is caused by a faulty routine that is attempting to remove duplicate route sections and I have given up reporting on them.

Thanks @LeonByford and @nickp for the clarifications.

This comment touched on the reason behind my question:

Last year I wrote programs to create up-to-date sequence CSV databases from first the XML set and then, having found that approach has regular errors, the JSON output from the API (by following a suggestion from @LeonByford). I have been trying to work out which source is the most accurate without success and I now know why. :slightly_smiling_face:

Because the Unified API consumes from the TransXChange data, there is an inherent risk that it will introduce errors through incorrect processing. Of course, sometimes there’s also garbage in, garbage out; if the TransXChange data is faulty, then the Unified API’s data will also be faulty.

That said, whether you’re using the TransXChange data or the Unified API, we do try to resolve any problems promptly, whether they’re issues with source data or errors introduced through faulty software.

We’re currently looking into the issues with the missing 412. We should hopefully have this restored some time tomorrow.

Thanks,
James

@nickp The 412 is now restored.

Thanks,
James

Thanks @jamesevans
Result of update dated 12/2/2024:

Line restored: 412
Line deleted: N18
Lines duplicated: K1, K2, K3, N65

464 has some sort of weird loop outbound, this may be intentional

Hi @nickp - the N18 is now restored. We’re looking at the 464

Thanks,
James

The 464 is currently in two bits, with a minibus doing the last bit from Biggin Hill to Tatsfield. The regular service may well be routed differently in Biggin Hill.

Not quite on topic but I have seen an article online which suggests that the connections are really awful; you always just miss it (either direction) and have to wait another half hour.

Result of update dated 13/2/2024:

Lines restored: 464, N18
Line duplicated: K1, K2, K3, N65, RB6

1 Like

Result of update dated 19/2/2024:

Line restored: RB6
Lines duplicated: K1, K2, K3, N65