Hi,
I’ve noticed there are two code standards for railway stations (e.g. Turramurra can be either 10101123 or 207410). Can anybody tell me how I should translate a code for a railway station ? Are there any downloadable translation tables ?
Thanks,
Steven
If you’re just after railway stations, there’s a mapping table between the two in the Location facilities dataset.
The two columns you’re after are TSN (207410) and EFA_ID (10101123).
Hi,
Thanks for the link. I presume the EFA_ID was for a railway only system that preceded today’s GTFS system.
Cheers,
Steven
It’s the location identifier generated in the Trip Planner API system.
Hi,
Thanks for the reply; I hadn’t studied the translation list properly. There seems to be a considerable overlap with these two codes lists but not totally. For instance I can do a departures enquiry for a bus stop using 2076165 or 10114232 (both refer to the same stop). But I can’t do a departures enquiry using 207410 (Turramurra station) even though it’s the TSN code for EFA_ID 10101123. Is this because the station is a parent ?
Thanks,
Steven
That’s right. You can query specific stop points (i.e. platforms or bus stops) using either TSN or EFA ID in the Trip Planner API. But since the Trip Planner API doesn’t inherit parent stations defined in the mode-specific GTFS bundles, you can’t query using parent TSNs (like 207410).
If you use the Complete GTFS bundle, you’ll see the parent stations are shown as PST<number>. The <number> suffix should match EFA_ID excluding the 1010 prefix.
Hi,
I’ve checked stops.txt in both the complete and real-time bundles with particular attention to the parent entries. With Turramurra both platform entries have Turramurra station listed as the parent. But the bus stops at the station don’t have a parent.
If I do a stop_finder enquiry on bus stand D (207470), the response contains the details for Turramurra station (10101123) rather than the actual bus stand. The same applies for any platforms or bus stands at this station. If I try a ‘&sftype=any’ enquiry I get all the ‘poi’ and other entries but still not the bus stands.
If I do a departure_mon enquiry on the station I get the station details in the header and departure details for all the platforms and bus stands in the departure sections. Fair enough.
What I am missing here is how the system knows the stop hierachy and how I can get this information. I’d like to be able to do an enquiry for Turramurra station (or Circular Quay for a more extreme example) and get all the stops associated with this “parent”.
The trip finder API documentation mentions a ‘odvSugMacro’ parameter which doesn’t seem to make any difference to me. It doesn’t mention the ‘sftype’ parameter which is critical. So maybe I’m missing something here. My enquiry URL is <‘https://api.transport.nsw.gov.au/v1/tp/stop_finder?outputFormat=rapidJSON&odvSugMacro=1&type_sf=any&name_sf=‘${STOP}’&coordOutputFormat=EPSG%3A4326&TfNSWSF=true’>.
Thanks,
Steven
Yeah, I getcha. As far as I know, what you want to do (search for a specific stop - e.g. platform or bus stand within a stop group) isn’t possible with the Stop Finder API. The folks at TfNSW may be able to confirm that.
Depending on what you’re trying to achieve, you might be able to get away by making an additional call to the coord API e.g. https://api.transport.nsw.gov.au/v1/tp/coord?outputFormat=rapidJSON&coord=151.21121090641793%3A-33.861967217542215%3AWGS84[dd.ddddd]&coordOutputFormat=EPSG%3A4326&inclFilter=1&type_1=BUS_POINT&radius_1=1000&PoisOnMapMacro=true&version=10.2.1.42
That’ll return a list of child platforms within the requested radius. TSN is defined in properties.STOPPOINT_GLOBAL_ID (e.g. 200065) and the stop group EFA ID defined in the first part of the id field (e.g. 10101103 from 10101103-53-D).
The coord idea with a very limited range is good. But it might be a bit wobbly because the range to capture all stops at Circular Quay might be too large for other suburban stations and include nearby stops which aren’t relevant. I’ll give your idea a try and see how it goes. It’s the fact that the TfNSW departure_mon can do it so well that makes me think there must be a way. I’m also wondering about grouping based on the start of the fullname but again it’s not necessarily foolproof.
Thanks,
Steven
Yeah, definitely not foolproof. Some start with and some end with the station name. e.g. “Botany Rd opp Green Square Station”. Some might not even have the station name in it at all! 
If you need a more exhaustive list, filtering based on the start of the id field is probably the way to go. e.g. below query is a 2km radius query for Turramurra. It’ll include a whole bunch of stops that aren’t part of the stop group but you can exclude them by checking the id doesn’t start with 10101123:
{
"version": "10.2.2.48",
"locations": [
{
"id": "10101123-10-TUR2",
...
"properties": {
"distance": 20,
"STOPPOINT_GLOBAL_ID": "2074182",
"STOP_AREA_NAME": "TUR1",
"STOP_POINT_REFERED_NAME": "Turramurra Station, Platform 2",
"STOP_POINT_REFERED_NAMEWITHPLACE": "Turramurra, Turramurra Station, Platform 2",
"IDENTIFIER": "TUR2"
}
},
{
"id": "10101123-10-TUR1",
...
"properties": {
"distance": 21,
"STOPPOINT_GLOBAL_ID": "2074181",
"STOP_AREA_NAME": "TUR1",
"STOP_POINT_REFERED_NAME": "Turramurra Station, Platform 1",
"STOP_POINT_REFERED_NAMEWITHPLACE": "Turramurra, Turramurra Station, Platform 1",
"IDENTIFIER": "TUR1"
}
},
{
"id": "10101123-20-X1",
...
"properties": {
"distance": 48,
"STOPPOINT_GLOBAL_ID": "207467",
"STOP_AREA_NAME": "BUS1",
"STOP_POINT_REFERED_NAME": "Turramurra Station, Stand A",
"STOP_POINT_REFERED_NAMEWITHPLACE": "Turramurra, Turramurra Station, Stand A",
"IDENTIFIER": "X1"
}
},
...
{
"id": "10114012-0-X1",
...
"properties": {
"distance": 101,
"STOPPOINT_GLOBAL_ID": "207414",
"STOP_AREA_NAME": "Swa",
"STOP_POINT_REFERED_NAME": "Pacific Hwy before Kissing Point Rd",
"STOP_POINT_REFERED_NAMEWITHPLACE": "Turramurra, Pacific Hwy before Kissing Point Rd",
"IDENTIFIER": "X1"
}
},
...
]
}
Notice how Pacific Hwy before Kissing Point Rd, which isn’t part of Turramurra Station, doesn’t start with 10101123?
All the grouping data is in the Trip Planner API system, but it’s not (as far as I know) exposed in an easy way to get at.
Thanks for the tip here - it is an excellent idea. And since the IDs have been created as they have it also explains to me why Trip Planner uses EFA_IDs rather than TSNs.
Cheers,
Steven
Hi there
Just adding my 2c here, and just confirming/clarifying a few points made in this thread.
As discussed, these two IDs have a parent-child relationship. This relationship is carefully crafted and continuously maintained, so please be careful if you are thinking of creating your own mapping table.
The EFA ID is used to reference a “stop group” which is a collection of “stop points”, referenced by TSNs. The stop groups are nothing to do with “railway only” and it doesn’t necessarily precede GTFS. This is the data construct in the backend system used to manage all of our trip planning data.
The stop finder request will never return a stop point as a result and this is by design:
First of all, almost nobody in the real world actually cares about stop points, especially for trip planning. e.g. The questions they want answered are like “I want to get from Central Station to Parramatta” - nothing to do with platforms or individual bus stands like Martin Place bus stand C.
Secondly, the trip planner is optimised to find the best trip possible, so it doesn’t make sense for customers to request a specific stop or platform, as the best service could be leaving from a different one
Thirdly, the trip planner is multimodal so (for example) specifying “Circular Quay Station” provides many user benefits over having to specify an individual stop point, as it will include options to travel by any mode which departs there, ie Train, Bus, Ferry, Light Rail.
I am not aware of any nice way to retrieve the information you are after, but the method which @jxeeno has suggested could definitely work. I would suggest narrowing the radius, as I doubt there would be a stop group which is spread over 2km. The biggest stop groups in mind are central station, circular quay, wynyard, town hall, martin place etc.
My overarching question back to you, however, is why do you need this information? We have never needed this information in our client applications since the backend handles all of this mapping for us. If you are using our other APIs for trip planning, then you shouldn’t need to worry about this mapping. If you are not using our other APIs, then you probably shouldn’t need to worry about using EFA IDs…
Vic
I’d imagine the primary use case would be when using the departure monitor API. For a user who’s already at a particular stop be it a platform or bus stand, they’d only be interested in departures from that particular stop point.
Hi Vic,
Thanks for your reply here and the warning about me creating any mapping table. I do not want to create any such table because I would have to (a) store it and (b) maintain it. Thanks to jxeeno’s excellent suggestion I can get the children TSNs if required. Admittedly my main reason for asking about this is that Trip Planner (departure_mon) does do it and I couldn’t see how because the parent details in stops.txt files don’t provide this hierarchy.
jxeeno is correct about needing the TSN to monitor just one stop of a group. For instance, all 575 buses leave Turramurra from a certain bus stand. Trip Planner (stop_finder) won’t return the entries for the individual stops at Turramurra station so unless I know the TSN for say bus stand A I can’t monitor it alone. But if I use jxeeno’s coord search and get the TSN for stand A I can use it in the departure_mon parameters and get a much more relevant list. I use this in the afternoon to watch the progress of certain buses which are notoriously late due to traffic and other hassles.
I’ve had to write a simple Trip Planner interface recently because since late last year the TransportNSW trip planner webpage no longer works in older browsers. So I’ve rushed into a totally new area for me and still have much to learn.
Cheers,
Steven
Hi Sorry for the delayed response. I am actively working with the trip planning backend vendor to understand how we can release an API which provides the information you need. I will update again when I have more information. Thanks
Hi Vic,
I have now created mapping lists for TSNs and EFA_IDs. I have about 46k TSNs and if I do a dummy departure_mon enquiry on a TSN the received header contains the EFA_ID. So it is possible to get the EFA_ID (if there is one) for each TSN but it requires 46k requests to your server and takes hours. I can supply my list (a .csv file) if anybody is interested.
Cheers,
Steven
Your method won’t work for all TSNs. only TSNs assigned to stop points and not for TSNs for stop groups because these are not used in our trip planning system at all.
We are working on getting rid of EFA IDs, in favour of just using TSNs… So don’t spend too much effort on this, but at the same time, we’re still in an analysis phase. This could require quite a bit of development for us to make this transition so also don’t hold your breath on this one.
Hi Vic,
Quite true what you say. For instance TSN 207410 doesn’t have an EFA_ID. But 207410 is the parent for 2074181 and 2074182 and will never appear in the stops list for a trip. My current use for this mapping is when a trip entry lists a stop (e.g. Chatswood platform 4) and I want to know all departures from the Chatswood hub at this time. Having both keys available means I can list just the departures from platform 4 (in case they want to continue their journey after a break) or all departures from the hub.
My issue with stop groups (e.g. 207410) is that the bus stands at Turramurra station don’t have 207410 listed as a parent. But both platforms and the four bus stands all have 10101123 as the EFA_ID and so I can use this key to get all departures from the hub/interchange (not sure what your terminology is here).
It is my understanding (please correct me if I’m wrong) that the Google system only supports a two-level hierachy (stops and groups). This seems a restriction to me and the local system that also supports EFA IDs seems far better.
Thanks,
Steven