Exporting TransXChange

  1. Produce a single TransXChange XML file per service

    1. This prevents the need for merging across files, e.g. no weekend variants or school variants

  2. Ensure unique, consistent external ids, e.g. service/route/journey private codes, operator codes

  3. Sanity check your data before uploading to Passenger Cloud

    1. Export to PDF in your timetabling software, does it look right?

    2. Compare against other implementations, does DfT’s TransXChange Publisher produce the same timetable?


Within Passenger Cloud

  1. Upload the dataset as a draft

    1. This updates some persistent information that does impact end-users, e.g. new lines, expanding line start/end dates

  2. Check the data within Passenger Cloud

    1. Are all the expected services appearing in the Services/Line list? Is the start and end date correct?  

    2. Are the Descriptions and details displaying correctly? You can edit these using the free text boxes in Passenger Cloud in the Services/Line list section. 

    3. Does the timetable preview match previous PDF’s?

      1. Do timetables appear for dates the service isn’t running?

    4. Does the journey planning preview match previous expectations? 

  3. Publish the dataset

    1. This does not change any persistent information but publicised this to your app and/or website for customers to use via Timetables and Journey Plans