Upon importing a TransXChange dataset, for each stop, we look up the ATCO code in NaPTAN for any additional data not provided by the TransXChange stop definition.
Whether TransXChange or NaPTAN is used depends on the field in question:
Field | Primary Source | Secondary Source | Default |
|---|---|---|---|
ATCO Code | TransXChange |
|
|
Location | TransXChange | NaPTAN | “0,0” - Null Island |
Common Name | TransXChange |
|
|
Locality Name | TransXChange | Bundled NPTG with TransXChange |
|
NaPTAN Code | NaPTAN |
|
|
Plate Code | NaPTAN |
|
|
Timing Status | TransXChange (per journey timing link) | NaPTAN | “OTH” (other) |
Indicator | NaPTAN |
|
|
Bearing | NaPTAN |
|
|
Stop Type | NaPTAN | “bus” |
Passenger does not recommend overriding the values in NaPTAN with TransXChange, other than as a short term resolution until NaPTAN can be updated.
Including other data within the stop common name field
Some customers have expressed interest in including other fields within this common name field (such as locality or indicator) so that this is presented on timetables.
We do not recommend doing this, as it goes against the use of fields defined in the schema and can possibly introduce duplication in future if Passenger chooses to change what fields are used.
Continue to the next article on Managing Stop Data: Updating NaPTANd