Route traffic summary

[Guardiola31337]

This ticket tracks the discussion of adding a summary of traffic on the entire route, suitable for display to the user on the route overview screen.

This should summarize the traffic on the route currently (as opposed to comparing the current conditions to typical conditions of the same route).

Could be either

• enum, one of a fixed set of values.
• string, already-localized description (with localization).

Noting that @mapbox/navigation-ios is currently implementing and exposing this client side. Capturing from @1ec5

For reference, this feature is similar to one in the iOS navigation SDK that colors the ETA label at the bottom of turn-by-turn navigation based on the predominant traffic congestion level along the remaining portion of the route. RouteProgress.averageCongestionLevelRemainingOnLeg is public but undocumented. An implementation of the specific label above would be simpler in that it can consider every segment along the entire route unconditionally, so all that’s left is to iterate over those segments, summing up the durations of heavy segments, durations of moderate segments, etc., and determining the highest congestion level based on these sums.

@jyrigo @AhmerKhan1 is this a feature we want to support?

@mapbox/navigation-api @mapbox/navnative @danpat is this something we should expose on _Router_s side? Also cc'ing @vanmaxim for visibility as currently working on the Hybrid Router.

cc @zugaldia @truburt @mapbox/navigation-android

[AhmerKhan1]

@Guardiola31337 @zugaldia @jyrigo I'm okay with the ask for this. However, do you need to do it on each mobile platform independently. If we can get it done with an API call, wouldn't that be simpler? If we can't do that, I don't consider this to be a critical requirement for launch since the end user will be able to gage the level of congestion from the color coding on the active route.

[danpat]

I would definitely recommend that if we do this, we settle on a server-side calculation - that way, we can adjust going forward. Any "summary" like this tends to be pretty subjective and we'll probably want to iterate on the exact method for calculating it (like we have done quite a few times on the name summary).

[1ec5]

Agreed, anything at the route level should ideally be calculated server-side. The iOS navigation SDK has a client-side implementation for its ETA coloring feature because the calculation has to be dynamic, only considering the remaining portion of the route/leg/step. As such, it can be a starting point for a client-side implementation of a route traffic summary, as a stopgap until a server-side implementation is available. A client-side implementation of the ETA coloring feature would exist regardless because we can’t call out to the server on every location update.

[danpat]

@1ec5 it does bring up one interesting issue around consistency of implementation: what to do when the client-side calculates "average congestion remaining on leg". It's reasonable to expect that if there has been 0% progress along a leg, that the value calculated by the client would match what the server-side implementation might return for the whole leg.

The server-side API already returns duration and duration_typical, which can be used to determine how much delay has been added by traffic conditions along the route. Whether that's a little bit of delay along all parts of the route, or one big delay at a specific section is not captured at that level, you need to look at the duration/duration_typical fields at the leg/step level to get more detail.

Are there any examples of what we're expecting to display on screen here? Can some of those visuals be posted to this ticket? I'm not 100% clear on what the final UI looks like here, and it would help to see that so we can figure out how to populate the needed data.

[1ec5]

it does bring up one interesting issue around consistency of implementation: what to do when the client-side calculates "average congestion remaining on leg". It's reasonable to expect that if there has been 0% progress along a leg, that the value calculated by the client would match what the server-side implementation might return for the whole leg.

The ETA coloring feature implemented in mapbox/mapbox-navigation-ios#403 is not intended to be all that empirical; instead, it’s a subtle way for the UI to communicate a change in conditions. A previous design actually colored the ETA based on how well the user keeps pace with the expected duration, but we switched to a traffic-based heuristic on a hunch.

I only brought up the ETA coloring implementation as a technical stopgap solution, riffing off something a customer had started to investigate, but it is a distinct feature from annotating a route with a “justification” or alert based on traffic conditions. A comparison between duration and duration_typical would be a simpler and more intuitive way to indicate that a route – one of several on a preview map – is experiencing traffic congestion.

[LukasPaczos]

A comparison between duration and duration_typical would be a simpler and more intuitive way to indicate that a route – one of several on a preview map – is experiencing traffic congestion.

:+1: And wouldn't that solution always be more efficiently implemented client-side? We do have the data available to make a ratio and then it's only a design decision on what are the thresholds for specific colors/messages. Otherwise, the response would have to package that redundant data. Unless we'd like to be able to dynamically adjust what those thresholds are of course.

Computing and exposing the ratio for the remaining portion of the route feels like a good feature for Nav Native if we want to follow that path. cc @mapbox/navnative