Hi, we noticed that since 06/08/2024, new objects are used to describe stops for rail replacement services. BEFORE: for all bus services (regular and replacement): StopPoint objects were used AFTER: regular services still use StopPoint, but replacement services use AnnotatedStopPointRef.
The ‘AFTER’ is the preferred setup, based on the TxC 2.4 schema (p38):
StopPoints may be declared as either a StopPoint, or AnnotatedStopPointRef, indicating that further details may be found in the NaPTAN database. The latter is the normal mechanism.
Is this new use in TfL TxC intentional as part of the 2.4 migration?
@jamesevans
I doubt that this is to do with the change of TransXChange version but just one file this week has a quite different structure. The file in question is tfl_8-289--y05-61295.xml.and I am comparing it with tfl_8-289--y05-61296.xml. Neither is a new file and the differences between file structures were not there last week,
The most obvious change, because it crashed my processing, is in the StopPoints block, where 15 data items have been reduced to 5. What is more, the previous 15 all started /StopPoints/StopPoint/ whereas the new 5 start /StopPoints/AnnotatedStopPointRef.
As my processing looks for particular strings in the descriptions, the change makes it fall over because, for example, /StopPoints/StopPoint/AtcoCode is not there to be found. The eastings and northings aren’t there either.
There are also format (or worse) differences in the data, even where the description in the same. For example /Services/Service/ServiceCode goes from 8-289--y05-61296 to UZ000ALNO:289. /JourneyPatternSections/JourneyPatternSection/@id has gone from (for example) from JPS_8-289--y05-61296-1-1-I to JPS_8-289-_-y05-61295-4-O-1 (so the direction is indicated by 1/2 rather than I/O).
I suspect this is mess-up rather than deliberate, as only one file out of 800 or so is affected.
Our timetable import and export routines were re-implemented essentially from scratch. Due to differences in how these routines process the data, you will see changes in the TransXChange files we publish, but they should conform to the TransXChange 2.4 standard.
As we import and export new timetables we receive from operators, we expect these changes will become more prevalent. Therefore, I recommend ensuring your software supports both StopPoint and AnnotatedStopPointRef elements.
@LeonByford
Thanks. I had not connected the issue with just one normal bus file (so far) with the change noted for rail replacement services. Now I know to expect both I can search for both. However, it looks as if I will no longer be able to pick up eastings and northings from the new style Datastore files and would have to go to another source if I really wanted to pick them up (which I might not, to be fair, as I was picking up the location data “because it was there”).
It would have been useful to have had advance warning of this and the numerous other changes to fields. I appreciate that it is migration to a standard that 2.4 prefers rather than 2.4 forcing changes but for the end user that is a fine distinction.
What I will now have to check is whether, once I have tweaked the coding to pick up stop point data, there are changes to the actual data which affect what I do. I have mentioned a couple in my initial post but until I have tried to process the file fully I don’t know. I doubt that anything is insuperable but doing this while running live, so as to speak, is not optimal.
Hi @LeonByford thank you for the update. We tweaked our processing to be able to support both StopPoint and AnnotatedStopPointRef elements. Yeah as said by @mjcarchive , advanced notice of such updates would be useful in the future, as even a small change like this, can break our pipeline
