TransXChange documents contain an Operator element:
<Operators> <Operator id="O1"> <OperatorCode>OBC</OperatorCode> <NationalOperatorCode>OXBC</NationalOperatorCode> <OperatorShortName>Oxford Bus Company</OperatorShortName> </Operator> </Operators>
An operator can be identified via either the
OperatorCode field was used with an arbitrary code that was unique within a localised area, usually managed via a Council/Local Transport Authority.
OperatorCode field is defined as an “External B” identifier:
External Codes forming part of arbitrary data systems. (‘B’). External codes are modelled as XML elements, and their names generally end in either ‘Code’ or ‘Number’. These identifiers will normally remain the same on repeated reissues of a given schedule as a TransXChange document.
With the release of the TransXChange 2.4 schema in 2010, the
NationalOperatorCode field was added to aid in uniquely identifying operators at a national level.
NationalOperatorCode field is defined as an “External A” identifier:
External Codes forming part of well-defined national data systems (‘A’). For example the AtcoCode, as defined in the NaPTAN data set. External codes are modelled as elements. These identifiers will always remain the same on repeated reissues of a given schedule as a TransXChange document.
The database of national operator codes is currently maintained by Traveline within the NOC database. Any TransXChange providing a NationalOperatorCode should match the NOC database.
The NationalOperatorCode provided should be the most granular NOC for the operator, rather than a group/parent organisation.
Passenger fully supports the effort to switch systems and data pipelines to use nationally unique operator codes; long term the whole industry benefits from this improved data quality.
However some legacy systems may not be capable of using a national operator code, and even with modern systems the migration should be carefully planned and managed.