Journey: Coordinates of intermediate StopPoints missing

Unified API
1

My app draws Journeys on a map, including intermediate stopPoints (journeys.legs.path.stopPoints)

Problem: I don’t see coordinates in the result:

        "stopPoints": [
          {
            "$type": "Tfl.Api.Presentation.Entities.Identifier, Tfl.Api.Presentation.Entities",
            "id": "490G09267E",
            "name": "Monument Station",
            "uri": "/StopPoint/490G09267E",
            "type": "StopPoint",
            "routeType": "Unknown",
            "status": "Unknown"
          },
          {
            "$type": "Tfl.Api.Presentation.Entities.Identifier, Tfl.Api.Presentation.Entities",
            "id": "490G000934",
            "name": "Fenchurch Street",
            "uri": "/StopPoint/490G000934",
            "type": "StopPoint",
            "routeType": "Unknown",
            "status": "Unknown"
          }
    ]

Am I supposed to call https://api.tfl.gov.uk/StopPoint/ for each and every intermediate stop point just to get the coordinates or is there a way to tell the journeys API to include coordinates of intermediate stopPoints in the journeys response?

Thanks
Gerd

2

Welcome to the forum @GerdC

If you use the /journey API call you will find

https://api.tfl.gov.uk/journey/journeyresults/1000266/to/1000013

in the results a path->linestring which contains a drawable route. This ins’t just the route stops but also the junctions and other parts of a route

image
image1297×366 47.4 KB

3

Thanks for the answer.

Yes, I already use lineString to draw the route.

But with other APIs, I also draw the stopPoints with stopPoint names at the coordinates of that specific stopPoint.

With your answer, I don’t see where on the lineString I have to draw which stopPoint/stopPointName.

as an example you can see how I draw the intermediate stopPoints in Helsinki (using the Digitransit GraphQL API)

Simulator Screen Shot - iPhone 12 Pro Max - 2020-12-09 at 11.14.47
Simulator Screen Shot - iPhone 12 Pro Max - 2020-12-09 at 11.14.471284×2778 1000 KB

Gerd

4

@GerdC

I personally have a table that’s the cache of all the UK station locations. You can get most of them from “Stations.XML” and the rest you have to do using your 500 calls per minute you can do from TfL.

It’s not like they ever move!

1 Like
5

As a starter you’ve got the start and end lat/lng for each leg in the elevation section of the journey call, after that you could get all the intermediate stop locations from /line/route/sequence for the line and direction for each leg (fewer calls than for each stop point), as the stopPoint entries in there do have lat/lng

6

@nickp Yes, I have already implemented it that way in Trias that has the same problem (at least the Mentz implementation of Trias). Will do it again for TFL.

Thanks for the reminder.

If somebody from TFL is reading this: please fix this and insert intermediate stopPoint coordinates in the journey response.
At the moment, it is a waste of programmer time, waste of server calls, waste of bandwidth (money and time) on smartphones.

7

One look at the responses from the TfL API and their total unsuitability for mobile apps, I made a wrapper that I run on AWS Lambda. I have a couple of small lookup tables sitting in memory, one that converts from naptan codes to ics codes (they aren’t used consistently in the API) and another for looking up station details that aren’t included. When you consider the enormous amount of stuff that is included in a response that 95% of clients won’t want, skipping the stop point locations is odd.

I’m happy to share the JSON for the lookup tables I use (not covering all modes, but tube, dlr, overground & tflrail at least) with anyone that wants them.

Unrelated point, but I’ve noticed the fares have gone missing from the journey planner results lately too.

8

I really really wish I could switch off all of the “$type” return values. They serve no purpose whatsoever and make the API code unreadable.

"$type": "Tfl.Api.Presentation.Entities.Prediction, Tfl.Api.Presentation.Entities",

Why in a simple call like https://api.tfl.gov.uk/line/dlr/arrivals you need 516 of them?