Retrieve the StopPoint id using common name


I am trying to retrieve the StopPoint id of a station given the common name, but the id returned by the StopPoint/Search endpoint seems to be wrong.

Here is an example searching for Farringdon:

Here is the response:

  "$type": "Tfl.Api.Presentation.Entities.SearchResponse, Tfl.Api.Presentation.Entities",
  "query": "farringdon",
  "total": 1,
  "matches": [
        "$type": "Tfl.Api.Presentation.Entities.MatchedStop, Tfl.Api.Presentation.Entities",
        "icsId": "1000080",
        "modes": [
        "zone": "1",
        "id": "HUBZFD",
        "name": "Farringdon",
        "lat": 51.520214,
        "lon": -0.105054

The id HUBZFD seems wrong to me and if I try to use this id with the StopPoint/:id/Arrival endpoint, I get no results.

Meanwhile, if I look for the id of Farringdon station using a different endpoint (i.e. the Line api), I get 940GZZLUHSC, and this id works perfectly with StopPoint/:id/Arrival,

Now, can you explain why the StopPoint/Search is returning the wrong id?


Hi @pasine
That’s a hub ID which is an amalgamation of nearby StopPoints that make up a transport hub. We created these for our own products. So for Farringdon that will include tube and National Rail plus likely closest bus stops. Here’s a handy blog post to explain how to search for Stop IDs. It also explains what a hub is. Let me know if it helps answer your question.



You know that there is a hub there but most potential users presumably do not, so have no idea whether what they will get back from a simple name search will be a hub or a stop. Perhaps there is a method by which the user can specify which they would get if both exist?

In some circumstances a complete list of departures from every component of a hub could be very useful but I take it from the original posting that nothing is generated.

As an aside, if I search for “Farringdon Station” on journey planner and I do not actively select the single entry underneath with a tube symbol next to it, I am told that more than one matching location has been found - but only one option is shown! If I search for Farringdon on its own I get a list of options, which is fair enough.

The geographical hierarchy may be perfectly clear to those who set it up but from the outside it seems like a little imp is in there trying to make it more difficult than you would (perhaps naively) hope.


@mjarchive We are very much aware of the limitations of our open data products. The Unified API was built primarily to power our website and the needs of third party developers were not at the forefront when designing it. We’ve learned from that and aim to bring in feedback from third party users when designing any new data products. Tackling the tech debt of the existing products is also on our wishlist but, with limited resources, subject to other priorities. Our Tech Team wrote the API blog posts to try to mitigate some of the quirkiness in the API, including this anomaly. I’ve raised a ticket for this (SVC-6072) to be considered as a future enhancement so it’s in our backlog and hopefully sorted out properly at some point. I’ll pass the JP issue on to the relevant product manager to take a look at.


@theochapple thanks for your article. I must admit the system is not really straightforward.
So, assuming I want to know all the arrivals at Farringdon Tube Station, I would have to

  1. Make a request using StopPoint/Search using the common name (i.e. Farringdon)
  2. Retrieve the ID, without knowing if it’s a hub Id or a platform id
  3. Make a second request to StopPoint/:id (i.e. HUBZFD)
  4. Loop through the results to find a match for the mode I am interested in (i.e. tube) or naptam type? (i.e. NaptanMetroPlatform)
  5. Retrieve the ID of the platform (i.e. 940GZZLUFCN is the first id I get if I look for NaptanMetroPlatform)
  6. Make a third request to StopPoint/:id/Arrivals to get the results

Is this the right procedure or there is a better one?


Theo - Thanks. I fully understand that a lot of Open Data comes from applications which preceded the goivernment’s open data initiative best part of ten years ago. I can distinctly recall the Big Announcement at the time, followed almost the next day by being hassled by the progenitors because our data were not immediately available in machine readable form!

I also know from experience that there are lots of questions to which the answer is obvious - but only once you know it. That can lead sometimes to those who know not appreciating how impenetrable it can seem to those who don’t.

I’ve never been convinced that the hierarchy/approach in Journey Planner really fits passengers’ needs but that, while a bit related, is part of a different story. In planning I don’t usually care much which stop/platform a bus/train leaves from but in presenting Countdown data on describers separating them out is paramount. I think that gives rise to some of the tensions that I see.


It doesn’t do even that very well, assuming you include the Journey Planner as being one of the most essential parts of the web site.

Here’s an example:


I’ll overlook for the moment that it asks for a disambiguation that seems to be totally unnecessary:


But much more of a problem is that the planned journey stops 10 minutes short of my searched destination, at a bus stop that serves the station but is not actually in sufficiently reasonable proximity to be considered to be the end point of the journey.


That isn’t an isolated example – here’s another


Again, leaves you at a bus stop that’s more than half a mile from the station:


Yet surely, if the search criteria includes the word station it’s reasonable to expect the final destination to be the station, not the nearest (or sometimes, not even the nearest) bus stop and to show the final leg of the journey. There’s no way that the average member of the public should reasonably be expected to know that the journey planner has ignored the final 10 minute walk.

I think the journey planner needs rethinking to do the job that its users need rather than what was convenient for the developers – and in doing so, you might reasonably come to the conclusion that stop groups are an unnecessary nuisance which in many cases is far more of a hindrance than a help.

Perhaps it’s time for a public consultation about how “well” (or in the above cases, how “badly” the journey planner is meeting their needs, and we might get something that’s a little more fit for its purpose.


Oh, and I forgot – in that second answer, it still dumps you half a mile from the station even if I specify a “least walking” route – and even though there’s a 191 bus that could have been used to complete the journey.

That I suspect is entirely down to the misunderstanding that the journey planner should dump people anywhere within a stop group instead of doing the job properly and taking them to their actual chosen destination.


I have a different take to Harry. Stop groups of some sort are necessary; I do not want to have to specify one of three stops close to each other at each end in order to plan my journey, particularly if the journey could be done from more than one of the stops. What is wrong in the Ponders End and Turkey Street example is the inclusion of the stops in the stop groups (or whatever) associated with the stations. Fair enough to include something somehow that indicates that you are at the closest point on the route to Turkey Street Station but not to actually call the stop that.


Journey Planner groups platforms, lines and bus stops around station areas, and looks for the fastest route to something in that group. It sounds like those groups at Turkey St and Ponders End need some revision, we know there are similar issues with bus stops at London Bridge, and DLR at Canary Wharf.

Next steps will be to review those groupings, and remove bus stops or station platforms which are over a certain distance from the station itself…which would definitely include those bus stops which are >0.5 miles away.