And on the right here is a sample from pretty much any other TransXChange file from the BODS database.
I’d say the BODS data is direct from Metroline as outside London operators have a legal requirement to provide this data to BODS.
https://data.bus-data.dft.gov.uk/timetable/dataset/5122/
https://publish.bus-data.dft.gov.uk/org/24/dataset/timetable/5122/report/16420/#Critical
I’d suspect though that both sets of data originated from Metroline’s scheduling team and have, as you say, been translated in some way.
It might be worth comparing the BODS submissions for by Uno for TfL routes 692 & 699 or Sullivan’s for TfL routes 217, 298, 327 & 626 (link) with their equivalents from the TfL Journey Planner TxCs.
Simon
Correct. However, in addition to data about our own bus stops, we require data about rail stations (910), bus stops outside Greater London, amongst other kinds of stops. Therefore, we not only supply data to NaPTAN (for 490) but also consume data from NaPTAN.
1 Like
Hi Simon. Checking the files for Uno and Sullivans, for the lines you mentioned, shows exactly the same thing. It’s actually easy to do because those routes are clearly separated in different directories from their other routes and for both operators, the format of the TransXChange StopPoints are exactly the same as the Metroline example above, with no location data beyond the general locality name.
For both operators, their other routes (I haven’t checked them all, but the sample seems conclusive), the format of StopPoints gives Latitude and Longitude data in the same format as the Red Rose sample above.
Yes, the Txc format allows for both Naptan-referenced data (AnnotatedStopPointRef) and provider-supplied data in full Naptan format (StopPoint). This is to allow data providers to override the base Naptan file with more recent or temporary updates.
It seems the BODS data for the operators is provided by TFL. This is the take from Metroline:
“… for all of our services operated on behalf of TfL, they create and provide us with the TransXChange files that are used for the upload into Bus Open Data – and that explains why some other operators have the same problem.”
Nick, I understand what you’re saying and it looks as if TFL are doing it ‘by the book’. However the result is that there are three different types of TransXChange files circulating:
- TFL datastore which contains location data but in easting and northing format
- TFL data provided to operators which doesn’t contain precise location data
- Operator generated data which contains location data in latitude and longitude format
For 2 it should be possible to cross reference the Naptan code to the Gazeteer, but again this only provides easting and northing data (and is a PITA).
Because 3 seems to be a standard outside of London, it would be really helpful if TFL could follow this standard - if only for the data that they provide to operators.
Perhaps worth noting that the files supplied to Traveline are the same (or at least close to the same) as those on Datastore, thus also have just eastings and northings.
I am unclear as to whether BODS will eventually eliminate trhe need for the Traveline files but they are still updated regularly at the moment.