This post is more of a suggestion than anything else. It would be nice if we have the 5 digit SMS code added to the StopPoint data model in the Unified API. It seems a bit strange that we can query with the code but can’t get the value returned for the corresponding result. Would be useful for those who save StopPoint information locally in their applications. I’m trying to find ways to reduce the number of API calls my app makes.
New stops still get allocated a SMS code. I have a suspicion they are sometimes recycled.
1 Like
They’re very easy to remember. Sometimes it’s useful if you’re at a stop you can still use an app to search for the code and it will still return the correct result (thanks to the Unified API)
I totally agree with you: easy to remember, handy when you want to add/search stops.
I don’t get why they’re so neglected. Besides these kind of ids are very common in cities around the world, there must be a reason.
1 Like
The reason is that 20 years ago people had phones with SMS and no GPS. Now almost everyone who has a phone has internet access, all-you-can-send SMS messages and Google Maps or something similar. No one needs to pay extra for static feeds of bus-only data when they can get this
for free.
I’m not saying that it’s useful as a sms code and indeed it’s not but I think it’s still a valid unique identifier.
Most of the cities I’ve visited are using this kind of short ids which tipically consists of 5 digits.
Two points:
- In London the only thing people look for is the white-on-red big letter(s) to find their stops; and
- As you can’t find out what the codes are in advance of getting there they are totally useless for journey planning.
Almost as useless as entering a sensible text description (in the TfL journey planner) like “Edmonton, Cambridge”! I get offered a choice of stops in roads in Kilburn or Sutton which contain the word “Cambridge” but nothing at the Cambridge roundabout or for that matter anything on the Great Cambridge Road. If I type in “Edmonton, Cambridge Roundabout” I get offered four stops at “Palmers Green, Cambridge Roundabout”. OK, that’s the right place, though arguably the wrong locality - buses terminating there display “Edmonton, Cambridge” - but why do they not come up as a response to the shorter search string?
Rant over…
They do, but annoyingly there are many stops that don’t have white-on-red letters.
Journey planner shows them for departure stops, but not for the arrival destination or interchange points. Many times I’ve wished it would. Especially at interchange points, where it’s useful to know whether the stop you’re arriving at is the same as the departure stop or you have to cross the road or go elsewhere.
Openstreetmap knows the codes for most stops, but you have to extract them from the API as no standard map shows them.
1 Like
I’m not sure that this is rebuttal of my points?
It’s a perfectly good rebuttal 
I can pull up LVF and type in the code displayed on the stop far quicker than the GPS on my phone can locate me and feed it back to whatever website. Give LVF a try the next time you’re at a stop. 
Page 3 “The NaPTAN Identifier System”
For each stop there are two associated NaPTAN identifiers, each unique within the UK
- A 12 character system identifier (the AtcoCode)
- A short (7 or 8 digit) version suitable for plating on stops and other public facing systems (the
NaPtanCode). This number has been designed to be suitable for use in SMS and other delivery
channels requiring direct reference to a stop identifier by the general public. It can be keyed
easily on a mobile keypad.
For TfL stops, the SMS code is the short NaPTAN code in most cases (If anyone from TfL is reading, as of 24th June there were 88 stops with matching long codes in the London 490xxx series that had non-matching Naptan short codes and TfL SMS codes).
Outside of London, certainly in my part of Kent, the (Stagecoach) stops display the shorter NaPTAN code such as “kntgdgdj” which isn’t much better than it’s longer version of “2400A063210R”.
Simon