Platform/Departing from information?

[Nick Blyumberg]

I'm curious to know if the platform information for LIRR is available in any of the MTA feeds\, possibly with the API key (I have not registered yet) or if it's proprietary to the MTA apps. I looked at the MTA website for their feed documentation and the GTFS feeds on Google but didn't find my answer yet. 

I'm using the TrainTime app to see what platforms the trains are departing from at Penn Station and wanted to figure out a better way than just hitting Update in the app. 

Thank you,

Nick

[Aaron Donovan]

Hi Nick,

It is not yet available via GTFS, but we should have it posted in the near future. 

-Aaron

[Nick Blyumberg]

Just curious if this information was ever made available. 

Was the Track/Platform information for the LIRR ever made available in the GTFS? I know track data can change at the last minute but I know at times the track is assigned as much as 10 minutes before departure from Penn Station and it would be handy to have that info available. 

Maybe John Larsen knows?

[John L]

Since there is no track attribute for the stop time, it is not included.

In the realtime feed, there is also no track attribute in the StopTimeEvent for a trip update.

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

[Patrick O'Hara]

The LIRR conveys track information in their countdown feeds through the TrainTime API—I’d recommend using that whenever possible.  It has track and platform information for stations as well as track information for terminals off the Solari boards.

The only downside is each station is its own separate feed, so to get the full picture, you have to pull 120+ different feeds. If the LIRR could consider providing a similar feed that conveys this level of information for all trains and stops in one place I think it’d be very beneficial to riders—even if it’s not directly tied to the static GTFS or GTFS-RT it could give developers willing to ‘think outside the box’ for their users the tools to do so.

…patrick…

--

[John L]

Patrick,

This is actually by trip (start station, end station) and will only give the status at the origin. It is true that track may be included shortly before departure time.

To get track to correlate to the GTFS RT feed, you would have to constantly call the Train Time feed with the location presented in GTFS RT and its destination.

[Nick Blyumberg]

Thank you so much for the Train Track API!

This may be even simpler than I had thought since it is JSON based.

My goal is straightforward in that I just want to push the track number of my trains to my watch and there are plenty of apps that allow to make JSON calls.

Does the train track API have a limit on the number of calls you can make? Or any other limitations on the feed similar to gtfs?

[John L]

As with any of the feeds, you have to host the data on your own servers and not allow apps to call them directly. 

With that said, for any of the feed data to be of any use, a station pair call per minute is reasonable but this could be in the thousands as well so take care.  If one were to just do the NYC terminal outbound to eastern stations, this could be ~20K calls per minute. 

I am not familiar with the data set returned but if it restricts the date and time, you would be better off getting all trains for the day rather than just a smaller timespan.

If track were invluded in the GTFS RT feed as an extension, would tbis be a better implementation and aleviate the use of this feed? 

[Nick Blyumberg]

Hi John,

A two part answer for this :)

In my specific use case, I would be polling the feed once or twice a minute 15 minutes prior to departure time for a Penn to a Port Jeff branch station (just one) with a script or app on my phone or if that's too much polling to the feed then to a server I have, parse the result-set for track number and if the resulting platform is null then sleep 30 and repeat until track is found. Then trigger a notification on the phone with the track information. I don't think I would run afoul of usage rules with this type of a pattern since I would most likely have at most 90 calls on a given day. Essentially this is what I do with my phone sometimes (Open the TrainTime app and hit that update button until a track pops up). 

I think for broader usability by other developers who develop full time, having the platform information as an extension of the GTFS feed would definitely reduce reliance on the TrainTime API and allow for other apps to include this information. Platform change information is also something that is very "real time". I think this information is only truly relevant at a handful of stations (at least the ones I've traveled to) - Penn Station, Woodside, Jamaica, Long Island City, Atlantic Terminal and Hicksville as these all have more than 2 platforms. I could see how  the number of permutations for a Departure/Arrival combination can get quite crazy. I also think that on any given day the number of track changes is pretty low to the number of trips in the system.

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

[Patrick O'Hara]

The way the LIRR’s GTFS-RT feed is set up it only gives trip update information at a particular station only after the train has departed the station—I think there are few, if any, circumstances where passengers would want to know the track number a train stopped on after the train has already left that station.  I think adding the track number as an extension while leaving the rest alone wouldn’t be of much use.

All of the information is already conveyed in one form or another on the two TrainTime feeds, you just have to pull tons of different feeds to get a complete picture…if the railroad could figure out a way to convey this level of information on one feed in one place for all trains running (be it through a bunch of new fields in the GTFS-RT feed or an alternative feed through the TrainTime API) that would solve a lot of the issues and reduce demand on the railroad’s servers.  As an example, it could be configured in a way like this (based off the TrainTime API):

{

       TIMESTAMP: "04/25/2016 07:43:06",

       TRAINS: {

              {

                     TRIAN_ID: "1011"

                     CLOSEST_TRIP_ID: "GO104_151011"

                     OP_DATE: "04/25/2016"

                     DEST: "ATL",

                     STOPS: {

                           {

                                  STATION: "MPK"

                                  TIME: "04/25/2016 06:59:00"

                                  TRACK: "1A"

                           }

                           {

                                  STATION: "MQA"

                                  TIME: "04/25/2016 07:01:00"

                                  TRACK: "1A"

                           }

                           {

                                  STATION: "SFD"

                                  TIME: "04/25/2016 07:04:00"

                                  TRACK: "1A"

                            }

                           {

                                  STATION: "FPT"

                                  TIME: "04/25/2016 07:11:00"

                                  TRACK: "1A"

                           }

                           {

                                  STATION: "BWN"

                                  TIME: "04/25/2016 07:14:00"

                                  TRACK: "1A"

                           }

                           {

                                  STATION: "RVC"

                                  TIME: "04/25/2016 07:17:00"

                                  TRACK: "1A"

                           }                   

                           {

                                  STATION: "JAM"

                                  TIME: "04/25/2016 07:37:00"

                                  TRACK: "2"

                           }

                           {

                                  STATION: "ATL"

                                  TIME: "04/25/2016 07:54:00"

                                  TRACK: "1"

                           }                         

                     },

                     NEXT_STOP: "ATL"

                     DIR: "W",

                     JAMAICA: true

                     HILLSIDE: false

                     OTP: -60,

                     UPDATE_LOCATION: "JAY"

                     UPDATE_TIME: "04/25/2016 07:39:37"

                     }

              },

              { (and so on for all running trains) }

}

Thanks!
…patrick…

[Michael B. Justice]

Track change information is highly relevant at all stations that have more than one track, and certainly relevant at any station that has two tracks but does not have an island platform (Forest Hills, East New York, Main Line stations between Jamaica and Mineola and again between Mineola and Hicksville, etc.).  Even terminal stations that have an island platform (like Far Rockaway), knowing which track the train leaves on is very helpful.

On Metro-North the same use cases exist with different stations.

I can understand the argument for extending the GTFS feed to include a default departure platform, Train Time (or a similar real-time service) is the only way to effectively convey this information since it does change often.  

MJ

[John L]

There exists a version of the MNR GTFS-RT feed with track as an extension is why I bring this up.

However, if a mobile app calls a feed directly, you are in violation of the usage policy. You must always have your mobile app access data from a non MTA hosted application. That is made quite clearin statis as well as real time feeds.

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

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

[Alex Perl]

John - would you be so kind to share the link to this MNR GTFS-RT feed with track extension that you mentioned? I dont believe its listed in the MTA's datamine portal. Thanks.

[John L]

I will dig around the site ,it is buried in there.

On Thu, Jun 13, 2019, 3:23 PM Alex Perl <aper...@gmail.com> wrote:

John - would you be so kind to share the link to this MNR GTFS-RT feed with track extension that you mentioned? I dont believe its listed in the MTA's datamine portal. Thanks.

--

You received this message because you are subscribed to the Google Groups "mtadeveloperresources" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtadeveloperreso...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mtadeveloperresources/5d5a9a1b-cdc9-402b-9e1c-e06ab6113cae%40googlegroups.com.