Time to Trip

[fpurcell]

(Ticket assigned to David Emory to spur discussion on this...)

I'd like the web-api to add a new (relative) time element to the XML/JSON called 'time-to-transit'. The value would indicate the number of seconds (was minutes) between now (current date/time at the Transit Agency) and when the transit vehicle departs the first boarding stop of an itinerary. This value could then be used on the UI to 'warn' the customer when she has barely enough time to walk/bike to the boarding stop. The need for this parameter came up today at TriMet when discussing 'Arrive By' trips, and how those types of trips planned with the current time can surprise a customer with how little slack time they have to get to their stop (e.g., "...and warn when you have barely enough time to walk to your boarding stop. The latter is trickier, since it depends on your personal walking speed: "You've got 10 minutes to walk 0.62 miles. You'd better run, or you'll miss your bus!").

NOTE: we also need to add a 'current time' to element to the web-api, ala https://github.com/openplans/OpenTripPlanner/issues/456

See #558

[abyrd]

fpurcell wrote:

and warn when you have barely enough time to walk to your boarding stop. The latter is trickier, since it depends on your personal walking speed: "You've got 10 minutes to walk 0.62 miles. You'd better run, or you'll miss your bus!").

This would be cool to have in the interface - a warning that this itinerary is only useful if you leave right away, or even that the itinerary starts in the past, so you can't possibly arrive by the specified time. However, is it better for this warning to be generated on the server or client side? It seems like all the client needs is the itinerary and its internal clock to generate the warning.

NOTE: I prefer the value of this parameter to be in minutes (minutes is easier to deal with on the UI...and more readily makes sense to the customer), but maybe seconds is more appropriate, especially if it has uses beyond the customer narrative...

David Turner and I briefly discussed putting everything (server-side and API) in seconds (rather than milliseconds), to avoid problems with mixed units. I would tend to favor doing a /60.0 on the client end rather than mixing units.

NOTE: we also need to add a 'current time' to element to the web-api, ala https://github.com/openplans/OpenTripPlanner/issues/456

I'm just guessing, but it seems like the intended use of the "current time" element is to decide when to give "departure imminent" warnings to the end user, even when that user's clock is incorrect or they are in another time zone.

Including both the agency time when the response was generated and some precalculated time-to-transit info seems redundant, not that that necessarily hurts anything.

If the idea is to support multiple time zones, there are a lot of other things to take into account: we would need time zones on request parameters, and we need to account for multiple agencies in different time zones on the same server.

[fpurcell]

David Turner and I briefly discussed putting everything (server-side and API) in seconds

Yeah, seconds is good for all time/duration elements...consistency more important in the larger scheme of things...switching minutes to seconds in my original

However, is it better for this warning to be generated on the server or client side? It seems like all the client needs is the itinerary and its internal clock to generate the warning.

Agreed that it's the client's job to craft (and determine when to show) the warning. But in regards to calculating time, I was thinking that they're going to be multiple clients; so rather than repeating the time logic in multiple places (of which, some client environments are less-elegant than others when it comes to parsing timestamps), it would be better to do this once server-side. Then the client(s) need only look at some pre-computed number (e.g. seconds before the vehicle arrives) to determine whether a warning is shown, etc...

Further, I hate relying on the customer's PC clock for anything due to their inherent inaccuracies. Plus, there are potentially a mix of places (client and server) where things are rendered within a session (thus different clocks, if time calculations were up to the client). For example, the javascript UI would use the customer's PC clock. And hitting the print button might render a simplified HTML document on the server (using the server's clock).

I'm just guessing, but it seems like the intended use of the "current time" element is to decide when to give "departure imminent" warnings to the end user...

Might also want to show the Agency Time to the customer (at least for the "run to your stop" warning...maybe in other places as well).

If the idea is to support multiple time zones, there are a lot of other things to take into account...

From TriMet's perspective, we'd be happy with server time, since that (for the foreseeable future) will always match agency time on our planner. So maybe we start simple here...

...need to account for multiple agencies in different time zones on the same server.

Yeah, could get a bit complex. Would have to retain timezone stamps for each agency from the GTFS, then query that based on the itinerary and offset the timezone of where the server is hosted, etc... And not to mention agency's/trips that cross timezones. Grrr...didn't mean for this to be .

[abyrd]

@fpurcell Is this two-year old issue still current? This looks like another case where functionality could be either on the client or server side.

[fpurcell]

Hey Andrew...no one is pushing for this at the moment. Okay to close (and/or implement if you see it a good idea).