Leading 0 missing from naptanId for some Slough stops

Unified API
1

The arrivals endpoint for a vehicle on route 81, e.g. https://api.tfl.gov.uk/vehicle/LK62DVH/arrivals, includes stops like “3700330”:

[
  {
    "$type": "Tfl.Api.Presentation.Entities.Prediction, Tfl.Api.Presentation.Entities",
    "id": "-850485982",
    "operationType": 1,
    "vehicleId": "LK62DVH",
    "naptanId": "3700330",
    "stationName": "Queensmere Centre",

But the stop’s actual id is 03700330, and accordingly https://api.tfl.gov.uk/StopPoint/3700330/arrivals returns “The following stop point is not recognised” but https://api.tfl.gov.uk/StopPoint/03700330/arrivals works.

(I guess this is a slight flaw of the NaPTAN numbering system - when 03700330 is entered into Excel it treats it like a number. 370 is the prefix for South Yorkshire)

1 Like
2

@josh These codes are very strange…

Looking at them in my database I can find these patterns:

  • Max length is 12 characters
  • Minimum length is 5 characters

The first character is never a 7 or 8

first character count
0 48812
1 85335
2 69465
3 62398
4 87170
5 27326
6 50309
9 6219

Second and third character is any digit.

The fourth character is always a zero. Following characters can be letters or digits.

It is therefore possible to work out if there is a problem with the code as the fourth character is always a zero.

I hope this helps.

(also see Scientists rename human genes to stop Microsoft Excel from misreading them as dates - The Verge !!!)

3

Hi @josh - we have a bug open for this at the moment. We’ve got a solution, but it requires a semi-simultaneous release of iBus data with our API data, so we’re sorting out the coordination of this with our colleagues that do that release.

I’ll update here once I’ve got more information.

Thanks,
James.

1 Like