Differing station names across JSON APIs?

[David Reed]

I'm working on a mapping application that shows both station locations and train positions. My objective was to be able to navigate fluidly from a train's position on the map, to its schedule, to the schedules of upcoming stations, and so on back and forth. I'm using the JSON APIs.

A challenge I have run into is that the different JSON APIs and the GTFS data use a lot of different names for the same stations, and seem to use them rather inconsistently. As far as I can tell, there are five different station identifiers, not all of which can easily be correlated with each other.

• The Location ID (GTFS and System Locations JSON API). It is also accepted in some cases by the Arrivals & Departures JSON API, but fails mysteriously for some stations (e.g., Allegheny, 90218 according to GTFS, returns an error from Arrivals & Departures when specified by Location ID, but works with the name).
• The station name as specified in GTFS.
• The station name as specified in the Regional Rail Inputs table, which is usually but not always the same as the GTFS name.
• The station name "parameter" as specified in the Regional Rail Inputs table, which is what is required by the Arrivals & Departures API.
• The station name as returned by the Regional Rail Schedules JSON API, which is usually the same as the "parameter" but sometimes a short version like "30th St" that doesn't match any of the others.

There are stations for which all four of the possible name values are different. E.g., Norristown's values are 90226 (ID), "Norristown T.C." (name in GTFS), "Norristown Transportation Center" (name in Regional Rail Inputs), "Norristown TC" (parameter in Regional Rail Inputs), and "Norristown" (sometimes but not always shown in Regional Rail Schedules).

Can anybody help me make sense of this? I hope I'm missing something obvious, and I would love it if there turned out to be a way to make one identifier work across the APIs or a correlation table, especially for the values returned by the Regional Rail Schedules JSON endpoint.

Thanks,

David

[Baudru, Yannick]

Hi David,

 

Thx for your inquiry. We are short on staff for the remainder of the week but we will get back to you next week.

 

Thx

 

Yannick

--
You received this message because you are subscribed to the Google Groups "SEPTAdev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to septadev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Reed]

Good morning,

I was wondering if I could check back in on this question.

Thanks,

David

To unsubscribe from this group and stop receiving emails from it, send an email to septadev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "SEPTAdev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to septadev+unsubscribe@googlegroups.com.

[Greg Apessos]

Hey David,

   Sorry for the delay, but we reviewed the Arrivals API and its input values and found a number of issues, including the ones .  We didn't handle every permeation for some stations, like Temple, but made sure that the GTFS names (Temple University), the internal names (Temple U) and all stop_ids will resolve probably.  Internal names are what you see in TrainView, RRSchedule and the like and from a cursory glance that's in the Regional Rail Inputs table.  I haven't yet checked the table to verify all those stations match up.

   Let me know if this update didn't fix all your issues or if you found any new ones.

Thanks,
   Greg