Integrate real-time information

[barbeau]

Real-time information could be retrieved from OneBusAway (OBA) instances, and be added to the mobile UI after a trip is planned.

More advanced integration of real-time info into the trip planning algorithm itself is also possible, but this requires server-side integration between OTP and OBA.

[barbeau]

Real-time info is now included in OTP server responses, when the server is configured with a GTFS-realtime feed. So, we can pull real-time information as part of a trip plan directly from an OTP server. See https://groups.google.com/forum/#!topic/opentripplanner-dev/G2SSwDAzBNU

[barbeau]

Latest on GTFS-realtime support from main OTP project - https://github.com/openplans/OpenTripPlanner/pull/1274

[barbeau]

For reference/ideas, here's how Google displays real-time Trip Updates information for transit (note the crossed-out schedule times, replaced by real-time info, along with small animating icon indicating real-time info):

[barbeau]

When we start this real-time work we will get into some questions about how to separate features in OTP Android vs. OneBusAway (OBA) Android.

So far, OTP has been about trip planning (no real-time), and OBA has been for showing real-time arrival estimates to answer the question "Where is My Bus?" (but no trip planning).

I think showing real-time in the context of a trip plan within OTP Android (similar to what Google Transit has done as shown above) is still a clean separation of the two apps without duplication of resources.

But, if we want to allow the user to tap on the icon to pull up the next X real-time arrival predictions, I think it would be better to leverage the OBA Android code base, and maybe look at how we could call out to that app via Intents and pass the bus stop number and agency name (OBA has a similar multi-region concept, which we'd need to tap into as well). This would allow us to continue to leverage future improvements to OBA Android from within OTP Android, and would prevent us from duplicating existing code.

[barbeau]

@vreixo is looking at integrating real-time transit info into OpenTripPlanner for Android, and I think leveraging OBA Android directly via Intents to show real-time arrival info using ArrivalsListFragment would be nice, since we wouldn't need to reinvent the wheel and would benefit from continued improvements to OBA.

Looking at OBA Android, it already supports a feature to bookmark bus stops (accessible by going to the "My Stops" page from the main menu, and then long-pressing on the stop - code here, I believe), which places an icon on your Android homescreen. When you tap on this icon, it launches directly to the real-time information view of that particular stop. It seems that we could leverage this same intent/process from OTP Android.

@paulcwatts could you give us a pointer to the entry process in the OBA Android code when a stop shortcut on the home screen is tapped to launch the ArrivalsListFragment? I haven't worked with shortcuts before on Android and this wasn't obvious to me looking at the code. Any other thoughts on launching ArrivalsListFragment via an Intent from another app? Only caveat I can think of currently is that OBA Android would need to be launched at least once prior to use like this, so the region would be auto-selected. We could add some logic to auto-detect server if not auto-detected already, though.

[paulcwatts]

You could certainly do that, although I would like to make sure the permissions on those intents are explicitly stated that external applications are able to use them (exported).

[barbeau]

@vreixo Full GTFS-rt support is apparently now available in OTP server, via https://github.com/openplans/OpenTripPlanner/pull/1296 (though as of this posting, its not yet merged).

[JordenVerwer]

For the record, OTP still doesn't support all of GTFS-RT trip updates. Added, replacement and unscheduled trips don't work at all and partial trip cancelations don't work correctly. Stop time updates of scheduled trips and fully canceled trips are implemented, though, and if anything doesn't work there it's a bug. Documentation is still poor, though.

[barbeau]

@JordenVerwer Thanks for the clarification! We'd be primarily interested in stop time updates for trips. A question - are Trip Updates for frequency-based service currently supported in OTP? Sample GTFS that we would use is here. GTFS-rt feed for this would include a trip_id, stop_id, stop_sequence, as well as an absolute time for an estimated arrival.

[JordenVerwer]

I don't think they are. Much of the work that is currently being performed on GTFS-RT is related to The Netherlands, where frequency-based services don't exist at present (or if they do exist, they are rare enough that I can't name any examples). This means that our focus has so far been on timetable-based services.

[barbeau]

@vreixo - as a heads up - testing real-time in Tampa will be interesting, since OTP Tampa covers two transit systems - the USF Bull Runner (which is frequency-based) and HART (which is schedule-based). Riders can transfer between the two systems.

I'm cc'ing @mona77 on this as well, as she's indicated interest in adding support for GTFS-rt updates to frequency-based service to OTP, if time allows.

@JordenVerwer any suggestions to help get @mona77 started on this?

[vreixo]

Thanks for your work on this to @JordenVerwer and people behind OTP, it's great to know that OTP has RT updates working at least for scheduled-based trips. Of course if it's added for all the trips will be even better.

I will work adding the RT that the back-end supports and other major improvements to the app as support for "rented bicycle", starting on December for my thesis project.

[JordenVerwer]

I'm not sure what the best approach to frequency-based GTFS-RT updates would be. I haven't seen the parts of the spec that deal with it at all, so I have no idea how it works. I'm also not sure how well frequency-based trips currently work in OTP even without updates. The code doesn't seem to get much attention at the moment.

[JordenVerwer]

You can now use the mmri-rt branch of OTP if you want to try my code. It does overwrite all the agency fields of the AgencyAndId objects of your feed with the default agency, which might be problematic, but is necessary in order to support multi-agency GTFS-RT feeds. Please let me know if you have any feedback.

[barbeau]

Thanks @JordenVerwer! When you say "multi-agency" GTFS-rt feeds, do you mean a single protobuf file that contains Trip Updates for multiple agencies (vs. consuming multiple protobuf files)?

[JordenVerwer]

I mean a single source of GTFS-RT updates, be it through WebSockets or HTTP. It doesn't have to be file-based. Each GTFS-RT feed is associated with one GTFS feed according to the specs, not with a specific agency.

[barbeau]

@JordenVerwer Ok, thanks. Would the current implementation be expected to support multiple GTFS and GTFS-rt feeds being used in the same OTP instance? So, one GTFS and GTFS-rt feed for our USF Bull Runner, and one GTFS and GTFS-rt feed for HART?

[JordenVerwer]

Yes, that should work, although it may need some special care.

[vreixo]

@barbeau I'm starting with the implementation of real time but, at the moment, I'm not sure what will be the best way to approach to the problem.

From your addition to the wiki and the old forum post previously referenced I understand that OTP should be configured to pull updates and they will be taken into account on planned trips and start/end times. So, from that part, we don't need to change anything (in fact a parameter related to realtime is only needed to not include them), the problem will be to obtain future changes on planned trips. The only special part that I have seen on trip responses, for realtime, are alerts, but I'm not sure if will be the right moment to add them because I think that it would require some work, specially in the UI, and I don't have too much time and I'm also not sure that they're are going to be very used.

So, I was looking for some API call to retrieve updates for the obtained trips and I have found two possible queries:

• Patcher sounds good but it seems to be just for alerts.
• Transit index, for the documentation this API call may be the solution.

The problem is that I'm not sure how useful this will be without doing any navigation/tracking of user progress in the route. I guess that we can suppose that a user might be interested on a route meanwhile he doesn't plan a new one and limited with a time constraint (so we don't leak too much battery). I think that route update would be better without user interaction to trigger it and "magically" do them in background, to avoid the hassle to the user and keep a simple UI. Perhaps would be ok to poll every minute for updates? I suppose that will be better to coordinate these updates with bike rental stations updates #147 to don't wake up the device twice.

To finally notify the user we should consider if will be best to show a notification, only cross-out the old times, a popup....

[barbeau]

@vreixo Some responses below:

So, from that part, we don't need to change anything (in fact a parameter related to realtime is only needed to not include them)

I think we should at least indicate in the UI that the time the user is seeing is based on real-time information, not schedule information. It's possible to only have real-time updates for a subset of stop, so we need to be clear to the user what we are showing them. The Google Maps screenshot towards the top of this thread shows how Google uses a strike-through on the schedule time and an animating dot next to the real-time time to indicate this.

The only special part that I have seen on trip responses, for realtime, are alerts, but I'm not sure if will be the right moment to add them because I think that it would require some work, specially in the UI, and I don't have too much time and I'm also not sure that they're are going to be very used.

Showing GTFS-rt alerts would definitely be useful - for example, TriMet shows them in-line with the itinerary:

We'd need to think how this could work in OTP Android, and it would entail UI additions. Whether you have time for this is definitely the key question :).

I was looking for some API call to retrieve updates for the obtained trips and I have found two possible queries.

Agreed, the transit index /transit/stopTimesForTrip seems to be the most logical API call to retrieve times for a specific trip/stop. I assume that real-time data would be returned from this API as well (along with the realtime boolean flag), but please double-check to be sure.

The problem is that I'm not sure how useful this will be without doing any navigation/tracking of user progress in the route. I guess that we can suppose that a user might be interested on a route meanwhile he doesn't plan a new one and limited with a time constraint (so we don't leak too much battery). I think that route update would be better without user interaction to trigger it and "magically" do them in background, to avoid the hassle to the user and keep a simple UI. Perhaps would be ok to poll every minute for updates?

Yes, this is a difficult interaction without the user explicitly leaving the app in the foreground (e.g., like for Google Maps Navigation). Maybe the best option is to have a "Listen for real-time updates" button on the route itinerary that would trigger this, much like Moovit has a "Navigate" button to trigger real-time navigation:

In the notifications, for Android 4.1 and up we should include a "Dismiss" or "Stop listening" button in the notification to allow the user to easily cancel out of updates. IMO, we should only notify the user if the arrival times change from what we originally showed the user when they planned the trip.

And yes, we should definitely limit updates to within the planned duration of the trip. Updating once a minute during the trip shouldn't be too bad if done correctly.

I suppose that will be better to coordinate these updates with bike rental stations updates #147 to don't wake up the device twice.

Yes, we should definitely batch background API calls so they happen around the same time - see Android docs for "Batch Transfers and Connections" and "Schedulign Repeating Alarms - Understand the Tradeoffs". You should also check out the [AlarmManager.setInexactRepeating()](https://developer.android.com/reference/android/app/AlarmManager.html#setInexactRepeating%28int, long, long, android.app.PendingIntent%29) to see if we can use that.

Also, GTFS and GTFS-rt data for HART in Tampa is available (see here) if you need test data.

[vreixo]

Thanks @barbeau! I attach my answers too:

So, from that part, we don't need to change anything (in fact a parameter related to realtime is only needed to not include them)

I think we should at least indicate in the UI that the time the user is seeing is based on real-time information, not schedule information. It's possible to only have real-time updates for a subset of stop, so we need to be clear to the user what we are showing them. The Google Maps screenshot towards the top of this thread shows how Google uses a strike-through on the schedule time and an animating dot next to the real-time time to indicate this.

The problem is that is not possible to determine if times come from a realtime source on 0.10.0 or older 0.9.x, at least that is what I have undertood. So to implement this we will need to deal with the update to 0.11.0 or even master branch. I have made some tests with both branches and all seemed to work fine except for the routes of API endpoints and trip time which was in seconds instead of milliseconds. Although, if we want to support different API levels we need to make some decisions, I'll open a different issue to talk about this.

The only special part that I have seen on trip responses, for realtime, are alerts, but I'm not sure if will be the right moment to add them because I think that it would require some work, specially in the UI, and I don't have too much time and I'm also not sure that they're are going to be very used.

Showing GTFS-rt alerts would definitely be useful - for example, TriMet shows them in-line with the itinerary:

We'd need to think how this could work in OTP Android, and it would entail UI additions. Whether you have time for this is definitely the key question :).

True :-), my point is that I'm going to give "some" real time processing to the app because I still have more work to do with my thesis and I think that real-time arriving times are much easier to implement (weather they're more useful or not it depends, alerts could be more critical but updated stop times are going to be generated for a lot of trips every day, in Coruña almost all :-)).

I was looking for some API call to retrieve updates for the obtained trips and I have found two possible queries.

Agreed, the transit index /transit/stopTimesForTrip seems to be the most logical API call to retrieve times for a specific trip/stop. I assume that real-time data would be returned from this API as well (along with the realtime boolean flag), but please double-check to be sure.

Ok, I'll check it.

The problem is that I'm not sure how useful this will be without doing any navigation/tracking of user progress in the route. I guess that we can suppose that a user might be interested on a route meanwhile he doesn't plan a new one and limited with a time constraint (so we don't leak too much battery). I think that route update would be better without user interaction to trigger it and "magically" do them in background, to avoid the hassle to the user and keep a simple UI. Perhaps would be ok to poll every minute for updates?

Yes, this is a difficult interaction without the user explicitly leaving the app in the foreground (e.g., like for Google Maps Navigation). Maybe the best option is to have a "Listen for real-time updates" button on the route itinerary that would trigger this, much like Moovit has a "Navigate" button to trigger real-time navigation:

I'm not sure about this. Moovit has a "Navigate" button because it does provide some sort of navigation. In fact I plan to start working on another app in the next months developing something similar that I hope to merge into this app :-).

In the notifications, for Android 4.1 and up we should include a "Dismiss" or "Stop listening" button in the notification to allow the user to easily cancel out of updates. IMO, we should only notify the user if the arrival times change from what we originally showed the user when they planned the trip.

I think that I will start without the notifications just crossing-out the time and informing of the presence of "live updates" and if I have time I'll add them.

And yes, we should definitely limit updates to within the planned duration of the trip. Updating once a minute during the trip shouldn't be too bad if done correctly.

If it's not too much, this sounds like the best option.

I suppose that will be better to coordinate these updates with bike rental stations updates #147 to don't wake up the device twice.

Yes, we should definitely batch background API calls so they happen around the same time - see Android docs for "Batch Transfers and Connections" and "Schedulign Repeating Alarms - Understand the Tradeoffs". You should also check out the AlarmManager.setInexactRepeating() to see if we can use that.

Thanks for the information, I'll check the links.

Also, GTFS and GTFS-rt data for HART in Tampa is available (see here) if you need test data.

Great! At the moment I don't have anything similar for Coruña.

[barbeau]

I think that I will start without the notifications just crossing-out the time and informing of the presence of "live updates" and if I have time I'll add them.

Yes, that's good.

Moovit has a "Navigate" button because it does provide some sort of navigation. In fact I plan to start working on another app in the next months developing something similar that I hope to merge into this app :-).

That would be awesome! :) Just opened https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/issues/297 for turn-by-turn navigation. Feel free to add your work/comments/etc there.

[vreixo]

@barbeau I'm working on the step-by-step instructions to reflect live updates, and I think that having one step for get on and another to get off is very confusing, it seems that there are two buses (also the icon helps to this confusion). I think that would mach more clear to show on the same step at what time is the departure, arrival time, origin and destination (it would be similar to the Google Transit screenshot).

Update: at the moment I have removed the mode icon for take off steps, because I think that at least this is necessary for sure

[barbeau]

@vreixo Agreed, two icons is definitely confusing. Below is how a transit trip looks on Google Maps for Android. I like the single icon/step, but the boarding and alighting stop being at the boundaries of that step, and the dashed lines for walk and solid line for transit (including the lines/circles representing intermediate steps). Something relatively close to this would be good.

[vreixo]

@barbeau I agree that this is much more clear and beautiful that our design, but it's also quite different. We have a "full text" style, with a complete sentence instead of this approach much more schematic.

If we prefer to move to a schematic design I can make some changes and try to have something that would look similar to this, but we will need to make some important changes also in the string resources.

Now I have almost finished showing real time results and adapting to the new API, in step-by-step indications and on map markers (with custom info windows and a HashMap with extra information associated with each marker to know if it represents real time information). After this I'll add updates as they are implemented for bike rental stations (although these ones won't be stopped in onResume so, they are going to continue even when the app is in background).

I prefer to have all things working and finished for real time, maintaining actual basic appearance, and after that looking to improve the design.

[barbeau]

@vreixo Sorry for the confusion - yes, I agree that the Google Maps UI is a significant departure from/improvement to our current UI. My last statement was referring more to the single bus icon appearing between the boarding and destination stop info. Your current change of removing the second bus icon is a good step towards this, and within the context of your current changes that should be fine. Eventually I'd like to move towards the Google Maps-style UI, but that is a significant amount of work/change.

The other simple option is to put a vertical ellipsis where the 2nd bus icon was, to indicate that the current step is an extension of the previous mode. Something like:

We should try to use the Unicode character for this if we decide to implement it.

[vreixo]

I have added the ellipsis that you suggested as a temporary workaround off a better solution :-). It may be a bit small, but is not easy to adjust it perfectly. If we have an icon to fit in there will be even easier to add it. In the subdirections we still have a little bus icon, but I think that looks good like this.

[vreixo]

@barbeau I have also changed some font sizes, reducing the diversity, following Android guidelines (mainly some changes in between dp and sp and 14 to 15 or reversal to make them more uniform).

[barbeau]

@vreixo Thanks, looks better! :)

[vreixo]

@barbeau I have some problems detecting folder structure / location of API endpoints.

At first I have thought that all new deployments, all 1.x (1.0.0-snapshot at the moment), would have server info at http://example.com/otp and to plan a trip http://example.com/otp/routers/default/plan like my test server running latest master (which reports 1.0.0-snapshot as server version too), but I have found that is not true, I suppose that this is something related to use Grizzly or latest master/ 0.11.0. So, Netherlands and Coimbra are 1.0.0-snapshot with endpoints for server info at http://example.com/otp-rest-servlet-ws/serverinfo and for plan at http://example.com/otp-rest-servlet-ws/plan, so they can be treated as the old servers which where http://example.com/opetnripplanner-api-webapp/ws/serverinfo and http://example.com/opetnripplanner-api-webapp/ws/plan.

My actual solution to this problem is:

• Try to obtain server info from server base_url of the spreadsheet directly (will work for http://example.com/otp) or from base_url/serverinfo which will work for the others.
• If the first is working I assume a url prefix of /routers/default for next queries and if the second one the url prefix will be an empty string.
• Defined prefix is added to the base_url to obtain metadata, plan a trip or get bike rental stations.

The caveats of the solution is that there isn't a common pattern for URL's for the spreadsheet or a custom server, hence I was thinking on a more complex solution. Just ask for the real base_url on the spreadsheet (or in custom server entrance), like http://example.com and then try to determine the correct prefix, requesting all the possible URLs, which I think that are going to match one of these options (at least all of the servers in the spreadsheet match these):

• /opentripplanner-api-webapp/ws
• /otp-rest-servlet/ws
• /otp (adding to the defined prefix /routers/default).

Like this I think that would be also much easier for users to enter a server address.

I'm not sure if this last one is a clean and secure solution, so, what do you think @barbeau ?

[vreixo]

@barbeau I have found that Tuscany server has a different pattern http://otp.infomobility.toscana.it/otp_api/ws, so may be better to keep my actual solution for the moment.

[barbeau]

@vreixo Unfortunately I haven't really dealt with the new REST API structure, so I'm not sure what the path should be. I know the REST API is still in flux and won't be frozen until 1.0.0 (i.e., 1.0.0-SNAPSHOT structure can still change, depending on what commit is at the head of your project).

Ideally, we should have two patterns for REST API structure:

• 1.0.0+
• Pre-1.0.0

...and the base URL for each of these can be defined by the OTP server admin, but everything after the base URL path for each of the above should be consistent for Pre-1.0.0 and 1.0.0+. This may be a moving target until 1.0.0 is released.

I'd suggest emailing the dev list to ask if there are any additional planned changes to the REST API path structure, and the current timeline for freezing the path structure.

[vreixo]

@barbeau Ok, I agree, will be better to have the two patterns and ask to the admin for a confirmed URL. The only reamining problem will be to specify the pattern on the app, to enter a custom server but I think that it's a minor problem.

Btw, here are some screenshots of the current development of the branch. Please feel free to make any comments about the appearance and design.

Info window is now custom so we are free to make further changes on it (except that animations are not supported, is a limitation of the API). Step-by-step icon for live updates blinks.

[barbeau]

The only reamining problem will be to specify the pattern on the app, to enter a custom server but I think that it's a minor problem.

Agreed, but I think for that we can just try both patterns, and one should match. A developer will understand they need to wait a bit longer for it to work ;).

Screenshots look good! Only two comments:

1. I would prefer to strikethrough only the time (and not repeat the date), if the date is the same for the scheduled and real-time times (which will usually be the case)
2. I would prefer to have the real-time icon directly after the real-time value, and then move the key (i.e., footnote) for this elsewhere on the screen.

So, for 1), something like:

13/7/2014 at 5:00pm 5:05pm

And for 2),

13/7/2014 at 5:00pm 5:05pm ... (elsewhere on screen) Real-time information

Both of these shrink the amount of space needed to indicate that a time is real-time in-line, and moves the key elsewhere.

The question for 2) is where to put the *Real-time information. I suppose you could put it in a floating View (that is only shown if real-time info exists) at the bottom of the map screen (just to the right of the Google logo and above the trip selection drop-down box over the map), and fixed at the bottom of the directions list, so it was always visible even if the user scrolls through the results.

Any ideas?

[vreixo]

1) Agreed. 2) It's clear for me now that is a real waste of screen space to display the key so many times :-). Are you thinking on also remove the live updates text from marker's info windows? I'm not so sure of that, in fact may be easier to display the key at the bottom of step-by-step screen instead of the map view. I can make tests with both options to finally see which one looks best.

Btw. I will write on OTP list to ask for an API call to the transit index to retrieve the real time updates, because I think that the previously discussed ones does not support them (because there is no special field and there is also this mail specifying which will be real time, although it's a bit old) . I hope it's not still under development.

[barbeau]

For 2), yes, I was suggesting removing the live update text (but leaving the icon) in the map marker info windows. The idea was to make the marker info windows smaller by removing the key text. But, let me know what you think looks best. If you do leave it in the marker window, I would italicize the text, and center align icon/text, to offset it some from the route name/description.

[vreixo]

@barbeau As soon as I finish with the new functionality I will work on these little design improvements.

Btw, I have continued with the approach that I have commented on the list, retrieving all https://github.com/opentripplanner/OpenTripPlanner/blob/da5599ccf40049bcc34b5d061b09922685ae9666/src/main/java/org/opentripplanner/index/model/TripTimeShort.java fort each leg with realtime field set to yes for all itineraries, every x minutes. Then I take first and last TripTimeShort and apply it to leg start and leg end (it seems to be an increment from the begining of the day). You can see an example output on the list.

[barbeau]

@vreixo Cool!

[vreixo]

@barbeau I'm finishing with fetching and applying the updates. At the moment I have set an interval for updates of one minute and I have been testing against modified static files. Although it should be working ok, I want to make some real tests, and I was wondering if you have or plan to have soon some instance of a Tampa server with an updated version and realtime updates configured (or perhaps @mona77 does?). If not I'll configure one for Tampa region too, according to OTP wiki should be easy, because I want to have something real to show as demo and I have contacted A Coruña buses and they don't have any kind of realtime feed at the moment.

Regarding the previous comments of visual design, I have solved 1) (also re-factoring some old functions that where too much complicated), but I have some problems with 2).

The problems with 2) derive from the fact that I thought that would be better to have the realtime icon blinking, but even-though it is more noticeable it might look a bit outdated. To make part of the text to be animated is very tricky in Android and some possible solutions that I have found seem to be very hacky. So, for my actual understanding about this, basically we have two options:

• Red dot goes inline and not animated, it could be an icon or some unicode character with color.
• Red dot will be an animated view so would be at one side of the text, we can reorganize the text to make it look a bit "inline" but the result won't be the same. Off course I think that would be good to only put the text in a floating window and not everywhere :-)

[barbeau]

@mona77 just set up http://mobullity.forest.usf.edu:8080/index.html, which is using the OTP master branch. But, I'm not sure of the status of real-time updates in it. We were targeting the campus Bull Runner shuttle first (which is frequency-based, not schedule-based), and @mona77 has been working on adding frequency support for real-time info.

@mona77 Is there real-time data in the new server instance that @vreixo could test against?

@vreixo For the icon - I'm fine without animation inline as unicode or icon. Another option would be to color-code the dot for whether the arrival is behind (dark blue), on time (green), or early (red). This is how we present the information in OneBusAway (for reference - here's where the color value is determined, and here are the color values). I'm not sure about this in OTP, though, since the primary use case of a trip planner is a bit different than OBA. Your thoughts?

[Mona77]

Hi @vreixo https://github.com/vreixo & @barbeau https://github.com/barbeau,

I haven't tried to configured http://mobullity.forest.usf.edu:8088/trip-updates?debug http://mobullity.forest.usf.edu:8088/trip-updates?debug with real-time updates http://mobullity.forest.usf.edu:8088/trip-updates?debug yet.

So far, I have been working on mmri-rt branch and I was able to use real-time updates for Bull Runner( FrequencyBased ). But in some cases, the routing gets so sensitive to the destination point, which I believe it is an issue with mmri-rt branch in FrequencyBased mode.

That's why I have moved to new Master branch, I'll let you know as soon as I have a working version.

Thanks, Mona.

On Tue, Jul 29, 2014 at 2:50 PM, Sean Barbeau notifications@github.com wrote:

@mona77 https://github.com/mona77 just set up http://mobullity.forest.usf.edu:8080/index.html, which is using the OTP master branch. But, I'm not sure of the status of real-time updates in it. We were targeting the campus Bull Runner shuttle first (which is frequency-based, not schedule-based), and @mona77 https://github.com/mona77 has been working on adding frequency support for real-time info.

@mona77 https://github.com/mona77 Is there real-time data in the new server instance that @vreixo https://github.com/vreixo could test against?

@vreixo https://github.com/vreixo For the icon - I'm fine without animation inline as unicode or icon. Another option would be to color-code the dot for whether the arrival is behind (dark blue), on time (green), or early (red). This is how we present the information in OneBusAway (for reference - here's https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/src/main/java/com/joulespersecond/seattlebusbot/ArrivalInfo.java#L107 where the color value is determined, and here https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/src/main/res/values/colors.xml are the color values). I'm not sure about this in OTP, though, since the primary use case of a trip planner is a bit different than OBA. Your thoughts?

— Reply to this email directly or view it on GitHub https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/issues/21#issuecomment-50520940 .

[vreixo]

@barbeau for the icon I actually think that is a great idea to display the icon in colors, will be more information on the same space and even more visually appealing. I'll also keep your color code convention. So, I'll continue with the idea of static inline icon and I think I will use a unicode character, although I'm not sure yet if it will be an asterisk * or some kind of circle like ●.

@Mona77 thank you very much, would be great to have a working server with realtime updates! .

[barbeau]

@vreixo If we go with the icon colors, then we'll need to have an explanation of what they mean somewhere. One option would be to display the same type of subtext that we display in OneBusAway, where we show "5 min early" or "5 min delay" or "Ontime", but show it as part of the footer.

So, something like:

13/7/2014 at 5:00pm 5:05pm * ...

• Real-time - 5 min delay

...where the "*" and "5 min delay" would both be in dark blue. Over time users would then associate the color with the value (hopefully).

[barbeau]

@vreixo actually, that would only work with a single delay value, and with multiple legs of a trip, you could actually have a mixture of early/late/ontime in different legs. So we'd still need to figure that out.

[vreixo]

@barbeau here is a possible new solution which in my opinion looks much better than before, please tell me what do you think.

Now I have encountered two more problems:

• If a trip is so delayed that the connection will be lost (or almost, we might need some safe margin maybe?) I suppose that we should eliminate the trip.
• If a trip is planned to very far in the future to interrupt the updates when the trip is finished won't be reasonable. I'm thinking on use a security limit for updates of one hour or something similar.

[barbeau]

@vreixo This looks good! I like it. One thing - could you color the time text in the marker pop-up balloon to match the "*On time" , etc. indicator below it? This would show that the two values are linked and draw attention to the time, and it would also match the written itinerary.

If a trip is so delayed that the connection will be lost (or almost, we might need some safe margin maybe?) I suppose that we should eliminate the trip.

Do you mean when showing the user the initial trip plan results? If so, I think this should be taken care of server-side - I believe the trips returned by the OTP REST API should all be feasible, including transfers, given the real-time info.

If a trip is planned to very far in the future to interrupt the updates when the trip is finished won't be reasonable. I'm thinking on use a security limit for updates of one hour or something similar.

I think you're saying you would only alert the user of real-time updates for a trip if the start time for the trip is within the next hour? This seems reasonable to me.

Related to this - at some point I'd like to look at integration with OBA Android, since OBA Android has a feature where you can schedule an Alarm via AlarmManager to be reminded when your bus is X min away. This feature is exposed via Intents in OBA, but to my knowledge it hasn't been used yet by any other apps. I created a demo app here that illustrates sending Intents to schedule a trip. I verified that OBA Android does receive the Intent, but didn't actually test the alarm scheduling part, so that may still need some additional work. We'd also need to ensure we're using the same format for agency name/stop_id as OBA.

[vreixo]

@barbeau 1) Is not totally straightforward to change that color because I'm using a standard marker snippet which only supports a plain string, but I thing that is doable. I'll try now. 2) I mean with the updated results. For example first bus arrives at 7:00 and first transfer is at 7:15, if we receive a delay of 20 minutes when we make the first request for updated times for the first bus trip, route won't be valid anymore. 3) I meant when to stop the updates not when to start them, but it's a good idea, and related to the problem, to start them one hour before the trip time (now I just use the same interval to determine the start, so they begin one minute after the trip is planned). My original question was if would be good to stop the updates after some amount time has been elapsed retrieving updates (like one hour) even if the final arrival trip time is not reached, but if we don't start the updates just after the trip is planned and wait to the departure time to be close, won't be such a big problem.

[barbeau]

I mean with the updated results. For example first bus arrives at 7:00 and first transfer is at 7:15, if we receive a delay of 20 minutes when we make the first request for updated times for the first bus trip, route won't be valid anymore.

Ok - yes, I assume we should alert the user at that point, and also provide an option that would let them easily re-plan the trip (i.e., maybe we cache the initial TripPlan)? I think we should request a fresh trip plan from the server at that point.

but if we don't start the updates just after the trip is planned and wait to the departure time to be close, won't be such a big problem.

Sounds good.

[vreixo]

@barbeau I'm sorry but I forgot to answer to the OBA question before. All the leverage with OBA sounds very interesting to me, but I'll discard it for the moment because I won't have time to finish my project on time otherwise.

At the moment I have finished with the basic part retrieving updates and the new visualization of realtime info. App starts retrieving updates one hour before first leg departure and stops when the time of the last departure of all itineraries is over-passed, finally I didn't put an extra limit.

Now the remaining parts are:

• Remove itineraries if some trips are not possible anymore, doing something if we remain out of possible itineraries (I think that usually the backend sends three itineraries).
• Add an option through settings to stop updates.
• Add notifications.

I have made my checks with the modified files and all seems to work ok, including bike rental additions.

[barbeau]

@vreixo Re: OBA - sure, I don't expect you to do this, but I wanted to capture it in this issue for possible future work.

Sounds great! What is the refresh rate you're using for retrieving real-time updates?