TransXChange files and stop point locations

Open Data
1

Hi. I’m struggling with bus timetables, specifically that the TFL supplied TransXChange files don’t include latitude and longitude information on the stop points. This seems out of line with what appears to be standard practice. A case in point is Metroline, the Metroline Hertfordshire timetables have stop points that look like this:

210021510050 Lyndon Mead Hail & Ride -0.299608 51.781661

… whereas the TFL Metroline files look like this:

490000070F Edgware Stop F Edgware Greater London

… no latitude or longitude. So how am I supposed to know where the stops are? I guess I could cross reference to the gazeteer, but a) this is a massive download and data burden and b) the data is in eastings and northings - from which point I’m not clear. I’m told that converting this data to latitude and longitude is not trivial.

What am I supposed to be doing here? I understand that the data I need is available from other TFL Api services but it should surely be possible to work out the route from the TransXChange data alone. It is possible for other operators. Would it be possible to include latitude and longitude information in the files?

Thanks

2

@grahamwell

You can always use the https://beta-naptan.dft.gov.uk/Download/National/csv as that contains the columns Longitude Latitude ?

3

Someone (ahem) recently made a FoI request for updated copies of the bus stop list and bus route sequences .csv files, you might have thought they’d have updated them on the website too but no… However, see here >>> FOI request detail - Transport for London

:smiley:

Simon

4

Hi Brian, Yes, I tried that - (this is the ‘Gazetter’, correct?) Although it has the columns for Longitude and Latitude, if you scroll down to the London entries, you’ll find that they are blank. However Simon’s data allows these gaps to be filled.

Simon: Thank you! That will at least allow me to patch up the timetable information and display it on a map.

The more general point is that although data provided by TFL is way better than that which exists for the rest of the country, it would be helpful if techniques that work for the rest of the country (based on the TransXChange format) worked in London - and because of this missing data, they don’t.

5

@grahamwell Hmm. My code is getting the location of bus stops from somewhere cos I can see them on the map…RTI

image
image921×713 201 KB

Let me have a see where they’ve come from.

6

My guess is that they are coming from the line/route/sequence API call? This will indeed return a route with latitude and longitude information - but it only works for TFL services. As I said above, if the whole country was as well served with data as London, it wouldn’t be an issue and I’d just use that.

However for the rest of the country, and that includes buses passing by my door operated out of Hertfordshire by Arriva etc, the only data available is the TransXChange stuff. There’s no way I would use this if I didn’t have to, it’s horrible, but given that there’s no alternative, it would be good if what I’m writing for Arriva Hertfordshire also worked for TFL, and it doesn’t - for this simple, dumb reason. The data is there, could it be provided please?

7

@grahamwell Looking at the code the is a reference to

https://transportapi.com/v3/uk/places.json?type=bus_stop

so it’s possible that outside of London I’ve used https://developer.transportapi.com/ to colect the data I wanted (at 100 calls per day!)

8

Correct me if I’ve missed something but you don’t seem to be handling bus routes outside of the TFL area. When I use your website and select “Watford Junction”, I only see the TFL buses (142 and 258). There are a whole bunch of regional services too - and including those is the problem.

Thanks for that link though, it could be useful - even though it does seem restrictive/expensive. At first blush I can’t see that it doesn’t offer information that isn’t available from BODS but I’ll dig a bit.

9

Try York

Watford Junction has TfL services (London Overground) so it may be treated as a TfL place.

10

Hi, thank you for this request.

We will take this away and see if there is any way we can provide latitude and longitude in the TransXChange files.

However, we need to be a bit careful because if we add latitude and longitude, it would affect anyone already using the easting and northing due to the need to put them in a TranslationStructure. So there is the possibility of a breaking change.

Section 7.1 "LocationStructure" of the TransXChange schema guide, page 278

@SarahLS

11

The Datastore XML files include eastings and northings for each individual route contain eastings and northings for each individual stop served. Not sure why they are used in some files and lat/lon in others. IIRC converting from one to the other involves a horrendous formula. Almost makes me wish the earth was flat…

12

Hi Leon, it won’t be a breaking change because you’re not providing either at the moment.
The TransXChange data for TFL services only contains the stop point fields:
(angle brackets don’t work so well here, so I’ll replace them with curly ones)

{AnnotatedStopPointRef}
{StopPointRef}490000165A{/StopPointRef}
{CommonName}Northwood{/CommonName}
{LocalityName}Northwood (London){/LocalityName}
{LocalityQualifier}Greater London{/LocalityQualifier}
{/AnnotatedStopPointRef}

That’s it. No {Location} field at all. There’s nothing to stop you adding eastings and northings if you want, but at present there’s nothing.

Compare with pretty much any other operator: Here’s an example from Red Rose Travel:

{AnnotatedStopPointRef}
{StopPointRef}210021902790{/StopPointRef}
{CommonName}Jewson{/CommonName}
{Location}
{Longitude}-0.425902{/Longitude}
{Latitude}51.644427{/Latitude}
{/Location}
{/AnnotatedStopPointRef}

Thanks

13

Hmmm… I see a <Location> element when checking tfl_8-301-_-y05-54753.xml, for example:

<StopPoint CreationDateTime="2018-05-15T00:00:00">
	<AtcoCode>490000987Z</AtcoCode>
	<Descriptor>
		<CommonName>Brampton Road / Lessness Avenue</CommonName>
	</Descriptor>
	<Place>
		<NptgLocalityRef>E0034035</NptgLocalityRef>
		<Location Precision="1m">
			<Easting>547602</Easting>
			<Northing>177450</Northing>
		</Location>
	</Place>
	<StopClassification>
		<StopType>BCS</StopType>
		<OffStreet>
			<BusAndCoach>
				<Bay>
					<TimingStatus>otherPoint</TimingStatus>
				</Bay>
			</BusAndCoach>
		</OffStreet>
	</StopClassification>
	<AdministrativeAreaRef>000</AdministrativeAreaRef>
	<Notes>Brampton Road / Lessness Avenue</Notes>
</StopPoint>
14

The TransXChange files that I’m referring to are the ones supplied by BODS. They appear under the operator sections, for example the 331 is included in the Metroline TFL section under Metroline Travel Limited 24.

It seems there’s a completely different set of TransXChange documents available from here:
http://tfl.gov.uk/tfl/syndication/feeds/journey-planner-timetables.zip
… which took such a long time to register that I thought the link was broken. These do contain much more detail - but as you say it’s in eastings and northings. That’s probably OK, now I know where they are I’ll see what I can do with them.

2 Likes
15
16

IIRC it doesn’t help that BODS and Naptan use different location standards. BODS obviously want lat/long as that’s what the buses’ real-time location systems will use but if I’m reading the Naptan 2.5 schema correctly, they want it in grid format (northing/easting):

(my bolding)

8.2 Location Element
The Location element (Figure 8-1) describes the spatial position of a stop. Coordinates may be
specified in Grid or WGS84 formats, or both. The primary coordinates used can be indicated by the
LocationSystem value (Grid or WGS84) specified on the NaPTAN &
NationalPublicTransportGazetteer document root elements.
Location coordinates must be supplied for all elements in the specified primary coordinates and may
optionally be provided in the other system as well. NaPTAN data should be submitted in Grid format.
NaPTAN data will normally be distributed in both formats.

While I’m having a moan at Naptan, how can they specify that the naptancode should be used for public facing systems but then make it an optional field?

3.5.3 Allocating NaPTAN (SMS) Codes for NaPTAN Stop Points
NaPTAN allows a short code to be specified for each stop, the NaptanCode. This is intended as a
unique reference for use in public facing systems such as SMS and web query apps.
The NaPTAN short code is distinct from the ATCO code (the latter is in effect a system identifier). A
NaptanCode can only be used once and cannot be reused.

image
image1223×606 144 KB

Simon

17

@sjcooper
The 5 digit SMS codes have been reused in London. So too have ARCO codes. Not very often in either case but I’m pretty sure that it has happened.

When I looked at grid-to-lat/lon conversion, all I could find was something which converted data for one point at a time. What I wanted was something I could feed with a huge batch of data. I did wonder whether it would be fit for purpose to convert points a km or so apart and then use linear interpolation for anything else but in the end I decided that I had better things to do!

18

I’d probably suggest using a library and predefined transformation to convert from Grid to Lat/Lon.

For reference, when we import NaPTAN data, we use the ProjNET4GeoAPI library and the 27700-1314 transformation.

19

@LeonByford,

Out of curiousity I would have thought that TfL would be the party responsible for uploading stop data to Naptan for the London (490) area, is that not the case?

Simon

20

comparison
comparison725×442 19.9 KB

This (if it works) is a side by side comparison of the TransXChange data for StopPoints for the same route, the 331. On the left is the file from BODS and on the right from the TFL datastore.

At a guess the one on the left (BODS) has been machine translated from the one on the right, or alternatively they have a common source. A further guess is that during the translation process, because the location data is in eastings and northings, it’s simply been thrown away.