OpenTripPlanner and GTFS-RT

[Travis Place]

Hey everyone,

I've been running on OTP instance for a while now, and use its API to power my mobile and web apps for the small community that I live in. A while ago I decided to try to enable the realtime updates, as the large transit company in my part of the state has recently brought out their own mobile app, with some realtime transit updates. Thankfully, access to these updates is provided by the state government and published as a GTFS-RT feed.

To try to configure this in my OTP instance, I added the following to router-config.json

{

    // Routing defaults are any public field or setter in the Java class

    // org.opentripplanner.routing.core.RoutingRequest

    routingDefaults: {

        numItineraries: 3,

        walkSpeed: 2.0,

        metric: true

    },

    updaters: [

        // GTFS-RT service alerts (frequent polling)

        {

            type: "real-time-alerts",

            frequencySec: 30,

            url: "https://gtfsrt.api.translink.com.au/Feed/SEQ",

            feedId: "translink"

        }

    ]

}

How can I know if this is working? In any of the returned data from a trip query using the API, the key 'realTime' is not set. Example (excerpt) below:

[legs] => Array (

         [0] => Array (

         [startTime] => 1520663670000

         [endTime] => 1520663700000

         [departureDelay] => 0

         [arrivalDelay] => 0

         [realTime] =>

         [distance] => 54.1594472834

         [pathway] =>

         [mode] => WALK

         [route] =>

         [agencyTimeZoneOffset] => 36000000

         

I have yet to see realTime be set at all. Am I missing something? Am I doing something wrong?

[Travis Place]

So on further investigation, ive added the following to my router-config.json

// Polling for GTFS-RT TripUpdates)

        {

            type: "stop-time-updater",

            frequencySec: 30,

            sourceType: "gtfs-http",

            url: "https://gtfsrt.api.translink.com.au/Feed/SEQ",

            feedId: "translink"

        }

Now I see information in the logs about TripUpdates, but the information doesn't look promising.. excerpt as follows:

14:39:43.515 WARN (TimetableSnapshotSource.java:333) No pattern found for tripId 10515152-BIC 17_18-BIC_SUN-Sunday-04, skipping TripUpdate.

14:39:43.515 WARN (TimetableSnapshotSource.java:260) Failed to apply TripUpdate.

14:39:43.515 INFO (TimetableSnapshotSource.java:265) Applied 0 trip updates.

14:39:43.515 WARN (TimetableSnapshotSource.java:333) No pattern found for tripId 10706149-SBL 17_18-SBL_SUN-Sunday-10, skipping TripUpdate.

14:39:43.515 WARN (TimetableSnapshotSource.java:260) Failed to apply TripUpdate.

14:39:43.515 INFO (TimetableSnapshotSource.java:265) Applied 0 trip updates.

14:39:43.515 WARN (TimetableSnapshotSource.java:333) No pattern found for tripId 10706209-SBL 17_18-SBL_SUN-Sunday-10, skipping TripUpdate.

14:39:43.515 WARN (TimetableSnapshotSource.java:260) Failed to apply TripUpdate.

14:39:43.516 INFO (TimetableSnapshotSource.java:265) Applied 0 trip updates.

14:39:43.516 WARN (TimetableSnapshotSource.java:333) No pattern found for tripId 10705497-SBL 17_18-SBL_SUN-Sunday-10, skipping TripUpdate.

14:39:43.516 WARN (TimetableSnapshotSource.java:260) Failed to apply TripUpdate.

14:39:43.516 INFO (TimetableSnapshotSource.java:265) Applied 0 trip updates.

this continues on, and happens every 30 seconds (when the feed updates). Is this because those trips dont have updates to show, or is something wrong and not working?

Thanks in advance.

[Johan Berg]

Hi Travis,

A possible source for problems like this is that the configured feedId in your updater is not correct. Is your GTFS feed configured with the feedId "translink"? You can verify this by opening the file feed_info.txt and verify that the feedId is set to "translink". You can also request the endpoint "/feeds". If your feed does not provide a feedId a numeric id will be generated (starting from one), you will see that id at the "feeds" endpoint as well.

Hope this helps

Cheers!

Johan

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

--

Johan Berg

+ 46 (0) 768132456
jo...@markupartist.com
http://markupartist.com/

[Travis Place]

I've never been able to get any of the endpoints to work on my OTP install.. so example, myhostname.com:8080/feeds just shows the error:

Not Found

Resource identified by path '/feeds', does not exist.

Grizzly 2.3.19

The contents of feed_info.txt as downloaded in the GTFS zip file are as follows:

feed_publisher_name,feed_publisher_url,feed_lang,feed_start_date,feed_end_date

Department of Transport and Main Roads - TransLink Division,http://www.translink.com.au/,en,20180306,20180430

On Sunday, March 11, 2018 at 12:31:22 PM UTC+10, Travis Place wrote:

[Johan Berg]

Given that info it's quite likely that the feedId OTP generated for your feed is "1". So I would try with configuring your updater with that. 

The full path to the feeds endpoint would be something like "/routers/default/index/feeds", sorry for the confusion.

Cheers!

Johan

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

[Travis Place]

Ok, so setting the feedId to "1" I now see different errors in the logs..

On Sunday, March 11, 2018 at 12:31:22 PM UTC+10, Travis Place wrote:

[Johan Berg]

That's great to see, this means OTP can consume the feed. The messages you see now has to do with the validity of the feed.

You might find this gtfs realtime validator useful to understand what's going on, https://github.com/CUTR-at-USF/gtfs-realtime-validator

Johan

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

[Travis Place]

So, it started providing realtime data updates, which was handy, BUT I had a few issues with it, so have disabled it for now.

The issues I was having are:

1) arrivalDelay and departureDelay were often strange numbers (like -296 which equates to 4min 56secs) which is fine I could round those if i wanted to,

2) it seems the startTime is changed to include the delay.. this causes issues.

For example, today I used my app to look for a ferry service..  it said the ferry was a 9:55am, so i rushed down to catch it.. it was actually a 10:00am ferry (which, when i searched) was running 5 minutes ahead of schedule)

Im looking now at ways around this.

On Sunday, March 11, 2018 at 12:31:22 PM UTC+10, Travis Place wrote:

[Andrew Byrd]

> On Mar 14, 2018, at 13:06, Travis Place <travi...@gmail.com> wrote:
> 1) arrivalDelay and departureDelay were often strange numbers (like -296 which equates to 4min 56secs) which is fine I could round those if i wanted to,

Why are these numbers strange, and why would you want to round them? It’s not clear what your expected behavior is.

> 2) it seems the startTime is changed to include the delay.. this causes issues.
> For example, today I used my app to look for a ferry service.. it said the ferry was a 9:55am, so i rushed down to catch it.. it was actually a 10:00am ferry (which, when i searched) was running 5 minutes ahead of schedule)
> Im looking now at ways around this.

This is the intended behavior, and a significant amount of work went into making it behave this way. It’s “a feature not a bug” :)

There’s a query parameter to ignore realtime information when routing: ignoreRealtimeUpdates=true.

Andrew

[Travis Place]

What I wanted to achieve was, the results to show the time the Ferry (in my case) is meant to leave/arrive, and then a delay amount, so I could show something like "10:00am" as its meant to with a little "+5 min" next to it in red, for example.

I think changing startTime to include the realtime delays, without still giving access to the correct time is strange. I would have expected startTime and startTimeAdjusted or something, or at least some way to still access the time the service was meant to arrive/depart.

As for the rounding, I'd do that for display purposes in my app, so i can do "+5 mins" as an example, not "+4mins 56secs"

Travis.

[Andrew Byrd]

> On Mar 14, 2018, at 15:08, Travis Place <travi...@gmail.com> wrote:
> What I wanted to achieve was, the results to show the time the Ferry (in my case) is meant to leave/arrive, and then a delay amount, so I could show something like "10:00am" as its meant to with a little "+5 min" next to it in red, for example.

I thought this was how most/all OTP clients display the information. You’ll probably want to examine how the default client does this. The routing API response should certainly contain enough information to reconstruct the 10:00 +5min representation.

> I think changing startTime to include the realtime delays, without still giving access to the correct time is strange. I would have expected startTime and startTimeAdjusted or something, or at least some way to still access the time the service was meant to arrive/depart.

The startTime in a routing response is meant to describe the time the passenger would leave the station, not the schedule. From the source code comments (which should show up in the API docs automatically):

/**
* For transit leg, the offset from the scheduled departure-time of the boarding stop in this leg.
* "scheduled time of departure at boarding stop" = startTime - departureDelay
*/
public int departureDelay = 0;

/**
* For transit leg, the offset from the scheduled arrival-time of the alighting stop in this leg.
* "scheduled time of arrival at alighting stop" = endTime - arrivalDelay
*/
public int arrivalDelay = 0;

So you can just subtract the departureDelay from the startTime.

> As for the rounding, I'd do that for display purposes in my app, so i can do "+5 mins" as an example, not "+4mins 56secs”

The contents of the API response are not meant to be displayed raw to the user. They are in seconds to provide the necessary precision in cases where the API consumer may need it. Typically a client would perform division to show minutes and seconds.

-Andrew

[Travis Place]

>The contents of the API response are not meant to be displayed raw to the user. They are in seconds to provide the necessary precision in cases where the API consumer may need it. Typically a client would perform division to show minutes and seconds. 

Yes, I get this.. I meant I do the rounding on my end, before customer display. My app talks to an API I wrote, which in turns talks to my OTP instance. My API can deal with rounding and display etc. I've done it this way because my own API does a lot of other things (business directory, location reminders, local events etc).

Now that I know about the ignoreRealtimeUpdates parameter, I have made a flag so I can switch it on/off on the fly and compare results of both responses, and work out how I will handle the data.

On another note, it seems that a lot of the OTP API endpoints dont work for me, or throw errors. Is there a way I can troubleshoot this, or a list of endpoints that SHOULD work, so I can compile a list of those that dont work for me?