/Line/{LineId}/Route/Sequence LineStrings returning duplicates?


#1

Hello,

I’ve noticed that the /Line/{LineId}/Route/Sequence endpoint sometimes returns duplicate LineStrings.

For example https://api.tfl.gov.uk/Line/207/Route/Sequence/inbound seems to return an array of 2 line strings but they are both identical. Similar results for lines RB6 and 183 where each line returns multiple line strings but they all seem to be identical.

At first I thought that each line string represents a line route but that doesn’t seem to be the case. Each line string contains an array which contains arrays of coordinates. These arrays of coordinates seem to represent parts of the entire line. In the case of line 207 the line strings contain two arrays of coordinates. The first array of coordinates seems to represent the entire route Hayes By-Pass -> White City Bus Station. However the second array seems to only contain that last set of coordinates for the route Hayes By-Pass -> Twyford Crescent where it differs from the previously mentioned route.

Could you please clarify in detail what these line strings represent and why there seem to be duplicates?
Is there any way to connect a line string to a specific route?

Thanks,
Denis Mesaric Stih
Software Developer, UrbanThings


#2

In the case of the 207, I think you’ll find that the second set represent the alternative route for the school run from Twyford School at 1530 and 1537 on school days. Similarly for the 183 from the Jewish Free School. In general, I believe, if there are multiple sections of orderedLineRoutes, there will be corresponding multiple line strings.

The RB6 has 3 major linestring sections inbound, each of 4 subsections and 2 outbound, each of 6 subsections. The major sections correspond to the number of orderedLineRoutes, but the data in each section is identical. This is reasonable for both outbound and the latter two inbound routes as they are effectively identical (stopping at all stops versus non-stopping), but does not explain the first inbound route. How the subsections are derived is a mystery to me - it does not seem to correspond to the sections in stopPointSequences (mind you, see my note in Missing/duplicated branches in /Line/Stop/Sequence as there are two sections missing in each of inbound and outbound), which I would have expected.


#3

Thanks for the response, Nick.

As it happens, even in the case of 207 and 183 the line strings are identical. If we were to match the orderedLineRoutes to the line string we would end up getting the same line string for both the main and alternative route. In the case of 207 each line string contains two arrays of coordinates. The first represents the main route and the second represents only the segment of the alternative route where it differs from the main route, but there doesn’t seem to be a logical way of combining them.

Would someone from TfL be able to comment, please, so that we can understand how this is meant to be interpreted?