Journey Planner API improvements: Alternative Routes


We’ve got some improvements to our Journey Planner API coming up soon, details attached. The main improvement is that we’ve added an alternative route, alongside the fastest route and all the others that were already there.

We’re not changing or taking away anything currently existing in the API response, which hopefully means the change would be non-breaking for you, but please let me know if there are any issues.

It will be at least 2 weeks until we make the change

JP - Alternative Routes and Scenario changes V2.docx (90.2 KB)

Is there any documentation on the “Disambiguation” process - especially how it provides the matchQuality score? For an input value of “London Bridge” - the disambiguation list returns Uxbridge (score of 634), followed by Rexbridge (score 602) & then London Bridge (score 534) and two more with lower scores… Clearly not what one would expect - any thoughts?

Hi, thanks for your query. The disambiguation options you’re getting do seem a bit strange. I wonder if you could please provide an example request URL?

I tried making a request to the following URL:

In this case, London Bridge station is the first result with a score of 1000 (the maximum), and all the other results seem to include “London Bridge” in their name.

Just to summarise how the disambiguation process works: when Journey Planner cannot find an exact match for a ‘from’, ‘to’ or ‘via’ location, it returns a disambiguation result. This offers multiple disambiguation options, each with a matchQuality property that indicates the relevance of the match within the list. I’m not entirely sure how the results are scored since this is technology we licensed from our supplier, but I suspect it may be based on the edit distance from the original input. You can then use the uri property on each disambiguation option to make a new API request using that option.

If you wish to avoid the disambiguation process, you can first use the StopPoint Search feature of the Unified API and use the icsId value from a search result as a from, to or via argument when making a JourneyResults request.

Please let me know if you have any further questions about this. :slight_smile:

First off - Thank You for the detailed response - much appreciated…

I may have spotted an issue in my code based on your example above :slight_smile: -
since I am interested only in the Tube network, in my code, I am “standardizing” the input (From / To) stations before calling the journeyresults API - part of which includes removing “spaces” & appending “UndergroundStation” at the end.

So From- London Bridge / To-Camden Town - becomes something like below

Looking at your example above where you’ve maintained %20 I changed my code to retain the space & viola it works !!!

Of course, given that there is an element of “fuzzy” matching, I would still maintain that “London Bridge Underground Station” should have a higer match rate than “Uxbridge Underground Station” when matched against “LONDONBRIDGEUNDERGROUNDSTATION”

In any case my problem is now resolved - THANK YOU so much


1 Like

Hi everyone,

We are pleased to announce that the Alternative Routes feature is now available in the Unified API.

Example request:

For details, please refer to the previously shared documentation:

JP - Alternative Routes and Scenario changes V2.docx (90.2 KB)

Addendum to the above document

The following four scenarios have been added:

  1. Equivalent to Scenario 1 but without the fastest intermodal journeys
  2. Equivalent to Scenario 2 but without the fastest intermodal journeys
  3. Equivalent to Scenario 3 but without the fastest intermodal journeys
  4. Equivalent to Scenario 4 but without the fastest intermodal journeys

If you have any questions, just let us know. :slight_smile: