Incorrect Data

Not checking your data before you upload it to Passenger Cloud can result in undesired results.


We encourage you to check data correctness when exporting TransXChange, by exporting PDF files within your timetabling software and comparing against other sources, such as DfT’s TransXChange Publisher.


Once you’ve confirmed the data is correct, you can upload it to Passenger Cloud as a draft., this will update persistent information immediately, such as services/lines/operators.


You should use the timetable and journey planning previews within Passenger Cloud to confirm the results match the prior PDF files, then publish the dataset.


Invalid XML

Invalid XML cannot be imported, your timetabling software should produce valid XML.


If you are manually editing the XML, you should not need to, your timetabling software should support everything required.


Manually editing XML is highly discouraged, as it can introduce data errors, inconsistencies and produce invalid TransXChange.


We would encourage you to contact your timetabling software supplier to remove any need for manually editing XML.


Invalid TransXChange

Sometimes timetabling software can produce valid XML, but invalid TransXChange.


Invalid TransXChange may successfully import into Passenger Cloud, but cause unexpected results.


Ensure you enable validation in your timetabling software when exporting, to ensure the data conforms to the schema.


This can also be done with an XSD validator and the correct TransXChange XSD schema if your software doesn’t support validation.


TransXChange Identifiers

TransXChange elements must have unique identifiers in order to be imported and used correctly.


These identifiers are used to cross-reference TransXChange elements within a file, across files and across systems, e.g. a service references the operator running that service.


TransXChange Identifiers can be broadly categorized into internal and external identifiers.


  • Internal identifiers are used to reference elements within a single TransXChange XML file

  • External identifiers are used to reference elements between multiple TransXChange XML files, or between multiple systems (e.g. Passenger and SIRI suppliers)


A list of identifier fields can be found on page 145 of the TransXChange 2.5 Schema.


We encourage the use of correct “External A” identifiers, such as NationalOperatorCode and ATCOCode.


  • The NationalOperatorCode should exist within the TNDS NOC Dataset

    • This should represent the most granular operator, not a group/parent

  • The ATCOCode should exist within NaPTAN


We also encourage the use of consistent PrivateCode identifiers, such as for Services, Routes and Vehicle Journeys.


By using the same consistent identifiers across multiple files/datasets, Passenger will be able to correctly identify elements, merging/skipping/creating/updating both persistent and dataset-specific information where appropriate.


We encourage you to produce a single TransXChange XML file per service (e.g. no weekend/school variants), to help eliminate the need for merging data across multiple files altogether.


Poor Content Quality

Some timetabling software can produce poor defaults for free text fields, such as:

  • Stop names

  • Destination display

  • Descriptions

  • Locations

  • and more...


We encourage you to check the content quality of such data within your timetabling software and Passenger Cloud on a regular basis.


Incorrect Journey Calendars

Sometimes your TransXChange can incorrectly define journey calendars, causing timetables and/or journey planning to show data for services that aren’t running.


We encourage you to double-check calendars within your timetabling software before importing into Passenger Cloud.


Once imported into Passenger Cloud, you should check the timetable and/or journey planning previews to confirm that no data is presented for days the service is not running, and data is presented for days it is.