National Operator Codes – Why We’re Migrating

22 Nov 2019 by Emer Coleman

TransportAPI’s Director of Delivery Dr David Mountain on our move to NOC

Bus operator codes should be simple: each different operator should have their own distinct identifying code, and everyone should use that code, right? If only it was that simple. At the top level, we have the group franchises: First Group; National Express; Stagecoach, etc. Think of each of these as a group of individual operators but a referencing system based on them is too wide, so we need something more granular to identify your regional operator. Then at the bottom level, we have garage or depot codes literally representing the bus depots from which buses operate and because each operator has many depots this turns out to be too fine a resolution.

Back in the day when Bus Timetables were a little less complex. From Essex Bus
Service in the 1970’s CCBY-SA 4.0


Transport industry data is peppered with these codes representing anything between too large and too small so frequently in TransportAPI we have to find ways of usefully mapping between these levels. We want to identify something that isn’t too big (such as First Group) or too small (such as Hanley, Hinde Street Bus Park bus depot). The regional franchises are associated with user-facing brands and from the perspective of identifying distinct operators, these feel just right (e.g.First in the Potteries).


So, we know the resolution we need to correctly identify operators, but what referencing system should we use? A reliable referencing system is one that is complete and without duplicates. Many operators have, over time, developed their own systems but most of them don’t pass this reliability test. All too often they contain duplicates within their own system and even more when multiple proprietary systems have been merged. 


When bus schedules were first released as open data as the Traveline National DataSet (TNDS)regional operator codes were used. The regional system is almost unique, but we in TransportAPI think it’s the worst kind of unique. Most codes are only used once, but there are examples of some that get reused in different regions. E.g. the regional code CB could refer to Cardiff Bus, Yorkshire Tiger, or Coombs Travel. We briefly considered developing our own system but in a in a world of multiple competing referencing systems we didn’t think introducing yet another one was a good idea.

Thankfully Traveline’s National Operator Code database appeared on the battlefield like a knight in shining armour. We’ve long recognised it as the primary system we wanted to use to represent bus operators so over the next few weeks we’ll start using this in all our bus endpoints.

Do you need to do anything?
Most likely, no. All the endpoints will still operate in the same way, with the same request and response structures. If you have operator codes hardcoded into your application logic, and you use these to look up services in requests, or to identify services operated by particular operators in responses (e.g.to highlight them in your app) then these codes will have to change. The NOC database is the place to check the codes you were using, and what these will change to. (The NOC codes structures are very similar to the regional ones: e.g National Express West Midlands has the regional code NXB and is TNXB in NOC).

We’ve lots of ideas about operator endpoints we can develop to help users lookup these codes in a more reliable way. E.g. searching on the basis of operator name, or retrieving all the regional operators within an umbrella group. So if you want to know more, please contact us and we’ll be happy to help! 

Transport API