Metro North Rail GTFS RT Fix (tripId vs trip_short_name + tripId in FeedEntity and not trip object)

89 views
Skip to first unread message

kevin...@transitscreen.com

unread,
Sep 21, 2016, 9:44:12 AM9/21/16
to mtadeveloperresources
Hi,

We are using the GTFS RT feed for MNR and we're witnessing 2 issues with it.

1) Even if they explicitly say it on their website, the feed is using the  trip_short_name from the GTFS file to identify the trip update instead of the trip id. This is kind of unusual compared to how other GTFS RT feeds work.
2) From what we are seeing (see below screenshot), MNR is actually setting the trip_id (trip_short_name GTFS) in FeedEntity.id and not in the trip tag.



Do you think it would it be possible to have these 2 issues fixed at some point?


Thanks,

Kevin


John L

unread,
Sep 21, 2016, 9:58:00 AM9/21/16
to mtadeveloperresources

No

The schedule feed is 'compressed' so only the relevant trips are displayed and no duplicatiin across schedules.  This was done to reduce the size of the schedule feed.  At any time during sports seasons, 75 schedules can be active.

The trip short name is used in the real time feed because for an operational day, that is really all that is needed.

You would look up the scheduled trip in the schedule feed and then match by short name to the real time feed.

There is nothing broken in the feed so there is nothing to fix. If you look at the specification and all of the optional fields, you will understand what I mean by this.

Is it different, sure but it was done on purpose.


--
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 mtadeveloperresources+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

John L

unread,
Sep 21, 2016, 10:06:11 AM9/21/16
to mtadeveloperresources

Also the specific FeedEntity ID field definition is

"Feed-unique identifier for this entity. The identifiers are used only to provide incrementality support. The actual entities referenced by the feed must be specified by explicit selectors (see EntitySelector for more)."

It is incorrect to think or implement the trip id in the id field.

The TripUpdate TripDescriptor trip_id field is where that should be present.  This is an optional field.


On Sep 21, 2016 9:44 AM, <kevin...@transitscreen.com> wrote:
Message has been deleted

kevin...@transitscreen.com

unread,
Sep 22, 2016, 8:29:53 PM9/22/16
to mtadeveloperresources
Cool, thanks for the explanation!

But the tripId (tip_short_name) is actually in the FeedEntity and not in the trip object, that's what I wanted to say. I agree that I/we dont care about the FeedEntity.Id. It just looks like the trip_short_name is set in FeedEntity.Id instead of Trip.Id if you look at the screenshit.

But that's ok, we could fix that on our end, I was just wondering why it was that different from other GTFS RT feeds.

Thanks,
Kevin

kevin...@transitscreen.com

unread,
Sep 22, 2016, 8:34:38 PM9/22/16
to mtadeveloperresources
Also, in the trips.txt, several trips have the same trip_short_name so in theory, looking for trips from the trip_short_name to then identify the correct tripId does really seem the easiest way (need to take into account the date). But I understand your data size issue.

John L

unread,
Sep 23, 2016, 8:10:42 AM9/23/16
to mtadevelop...@googlegroups.com

The same trip short name will always be represented multiple times in the trips.txt file.
If there are weekday, Friday only, one day or event  schedules for example, there will be multiple entries in the calendar.txt and calendar_dates.txt file to determine which schedule is active on what date.


Thanks,
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.

--
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.
Reply all
Reply to author
Forward
0 new messages