ApiError : Could not find a matching ICS code for the Naptan Id 490016727S

Unified API
1

Dear Support,

Trying to retrieve the timetable for Line 192 at StopPoint 490016727S with the following API call:
https://api.tfl.gov.uk/Line/192/Timetable/490016727S?direction=outbound

Getting this error response:

{“$type”:“Tfl.Api.Presentation.Entities.ApiError, Tfl.Api.Presentation.Entities”,“timestampUtc”:“2020-02-11T20:56:45.3102073Z”,“exceptionType”:“ApiArgumentException”,“httpStatusCode”:400,“httpStatus”:“BadRequest”,“relativeUri”:“/Line/192/Timetable/490016727S?direction=outbound”,“message”:"Could not find a matching ICS code for the Naptan Id 490016727S. Argument name: fromNaptanId. "}

"Could not find a matching ICS code for the Naptan Id 490016727S. Argument name: fromNaptanId

Any advice on how to “correct the errors of my ways” would be appreciated.

Thanks.

2

When you posted about the csv stops and sequences files I was tempted to ask how up-to-date they were. The only trace I can find of 490016727S is as a stop some years ago on route 377, not 192 (though 192 might have served it in prehistory).

The current Datastore Journey Planner files show 377 serving 490016727Z westbound and 490016727Z1 eastbound. The 192 serves the first of these (towards Tottenham Hale). Do these codes give what you want?

I have no idea why the suffixes have changed, unless it is linked to the stop code changing from an H series code to an HC series code. Both represent Hail & Ride but maybe HC has some extra significance.

To return to my initial sentence, the question becomes why a code that appears to have been obsolete for some years is included in whatever supposedly current source (sequences?) you have taken it from.

Michael

3

Hi Michael,

As a newbie…I appreciate your expertise and insights.

In response to your first question, there is no indication of the date the csv files were produced (I assumed it’s the most current). It just so happen that the 192 bus serves the area close to where I live. For me to “fast track” my understanding and knowledge, I obviously started with the buses within my residential radius.

As you suggested the data “seems” outdated, however historical data (lines, routes etc) may have been left in for reporting and statistical reasons. From my experience, normally purging for data doesn’t happen, it is “flagged” as inactive, historical etc…which is an approach I would recommend with the csv files - if that is the case.

Again, from your insights, I may need to abandon using the csv files and get the most-up-to-date data through the API. However, during this early stage for me, 100% accuracy is not the main priority.

Once again, your time is much appreciated.

Thanks,
Winston.

4

@LondonTravel

n, there is no indication of the date the csv files were produced (I assumed it’s the most current)

I think you can assume that the CSV file is “well intentioned” but it’s not really a primary data source. It’s kept up-to-date by staff add/removing from a spreadsheet and the system posting changes here.

In theory the Unified APIis more normalized data. My approach is use the Unified API or old API calls for the bus data and then if you need to cross-check, use the CSV file to work out if something is really wrong.

I wouldn’t use the CSV for a data-source for an autocomplete, for example.

I have made great use of the CSV when doing work for Rail Replacement Bus Services as it lists the “ULxx” servicecs, which are the tube/TflRail RRBS.

5

Also, have you tried https://api.tfl.gov.uk/Search?query=490016727S ?

6

The ad hoc updating no doubt explains the dodgy characters in the files too.

You can scrape the full,list of stops served from pages such as 192 Bus timetable - Transport for London but you really would not want to do this manually for several hundred routes. The Datastore Journey Planner files are in XML format but in principle yield a list of stops served.

The issue with that though is that some stops are served in both directions, either because the first and last stop is the same or because there is a loop served in the same direction both ways. These stops only appear once in the stops listing. The 192 has an unusual variant on this as the Cross Road (I think) stop is served both ways despite not being in a loop.

While it would be possible with a bit of programming to use the Journey Pattern section of the Datastore files to produce a list which handled these double occurrences correctly, it would be quite a task to keep this up-to-date.

Michael

7

@briantist

Your tips, expertise and advice are much appreciated.

Couple of questions:

  1. You stated, “My approach is use the Unified API or old API calls for the bus data”. Of course, TfL is promoting the use of the Unified API, but you are continuing to use the old API - is that because the Unified API does not provide the functionalities in the old API (as of yet) for your existing application(s)?

  2. I was wondering why the RRBS buses have the UL prefix - do you know what the UL stand for and more importantly, can the get real-time arrival times for these UL buses when they are in service?

8

@briantist

I checked out your Search link and well…I am a bit mystified about its response.

Is the property match.score indicating how relevant the returned content (in this case match.highlights) is?

The response seems to be in descending order of the match.score.

From the API docs, this Search call “Search the site for occurrences of the query string”.

In examining the response, the URL properties (match.url), all origin from tfl.gov.uk and returns a wide variety of articles which I assume contains a reference with the queried parameter.

In what scenario would you use this Search call? (is it to check if there have been any published announcements or, are there more beneficial uses ie. the start of something…).

Thanks.

9

@mjcarchive

Hmmm…interesting conundrum you have pointed out that I will bear in mind going forward.

Thanks.

10

Ok, the answer to your second question is Underground Line.

UL codes.jpg4121×2983 1.32 MB

The unified API doesn’t stream bus data at you, it’s all stateless.

11

In what scenario would you use this Search call?

I would mainly use Search to cross-reference things that don’t seem to make sense. It’s a bit random at times, but it is able to find things without the need to search everything in every TfL endpoint.

12

Okay…good to know…thanks.

13

@briantist

Thanks…picture sure does speak a thousand words! …the map is very useful.

I have used the RBS on many occasions,

Does the API provide arrival times for this service?

14

The buses do not display UL numbers by the way, so when Google Maps (for example) show service UL79 (say) as calling at a stop it must confuse 99% of users. Buses usually show up as L1 and L2, or I have seen A, B and C, but these are likely to be used to distinguish different services calling at a single station and are likely to be duplicated across London.

One other point - the UL numbers themselves have been recycled in the past, which in turn means that different UL numbers have been used for the same routeing. You can see this at Working Timetable (Time Schedule) Graveyard - Rail (tube/LO/TfL Rail) replacement services
from which the working timetables are available.

I don’t know whether live times are available.

Michael

15

@mjcarchive

I am surprised that this occurs as it makes it (almost) impossible to reliably provide accurate arrival information. Although it is a temporary service it would greatly benefit the passengers.

Thanks.
Winston.