Supported TransXChange
The TransXChange schema has had numerous iterations and can define the same data via numerous methods, we do not support all possible TransXChange.
Passenger targets the TransXChange 2.4 schema and compatibility with the TransXChange UK PTI Profile - an additional set of constraints and clarifications that sit on top of the TXC 2.4 schema, for compliance with the bus open data service (BODS).
TransXChange 2.1 is also currently supported for legacy systems, however, we encourage updating to 2.4.
Dataset Zip File Structure
A dataset zip file should consist of one TransXChange XML file per service, it should not contain zip files within the zip file. Files are merged in the order they are presented within the zip file (alphabetically).
A dataset should represent the state of the whole network for a specific effective period, if changes are made to the network during this period, these should be captured within distinct datasets from the date the changes come into effect.
Ideally, the number of datasets should be kept to a minimum, covering the scheduled state of the network for the next few months. Old datasets should be removed when they are no longer required.
Passenger recommends the following dataset file structure:
January | February | March |
Dataset A
| Dataset B
| Dataset C
|
Unsupported Datasets
Passenger does not support datasets with an individual service repeated in a dataset, as the order and precedence of different data in TXC files is often ambiguous, and can lead to undesired results.
January - March | |
Dataset A | |
|
|
In the above, TXC files 3 and 4 contain the same services as TXC files 1 and 2, which are in the same dataset. To remedy this, upload TXC files 3 and 4 as a separate future dataset.
Continue to the next article on TransXChange: External Identifiers