Continuous replanning

Navigation SDK for Android is only available upon request. Contact us to get started.

Route update mode

This mode specifies whether or not the system should try to periodically update the active route and look for better route proposals. There are two possible values:

• ENABLED - The system periodically updates the active route and looks for better route proposals, based on replanRouteInterval. The way that better route proposals are handled is defined by BetterProposalAcceptanceMode.
• DISABLED - The system does not update the active route nor search for better route proposals.

By default, RouteUpdateMode is set to ENABLED. It is configured in the following way:

1val options = RouteReplanningEngineOptions(
2    routeUpdateMode = RouteUpdateMode.Enabled
3)
4val engine = RouteReplanningEngineFactory.create(routeReplanner, options)
5val onlineConfiguration = Configuration(
6    context = context,
7    locationProvider = locationProvider,
8    apiKey = apiKey,
9    routeReplanner = routeReplanner,
10    routeReplanningEngine = engine
11)

Route refresh

Every trip takes time and the road situation is constantly changing. As a result, route data may become outdated during a trip. Route refresh provides users the most up-to-date route information such as:

• Travel time and ETA (Estimated Time of Arrival)
• Traffic information (delay and amount of traffic)
• Updated legs and sections

Route refresh works only if RouteUpdateMode is set to ENABLED.

Route refresh might fail if the initial route planning was done with densely placed supporting points in comparison to route geometry. The replanning is made based on the geometry of the current route, where the density of coordinates may be lower.

Replanning response

The updated route will always be automatically applied and the reason will be set to RouteUpdateReason.Refresh.

Continuous Replanning - finding better alternatives

If you would like to receive alternative route proposals, RouteUpdateMode must be set to ENABLED. The frequency of searches for better route proposals is defined with replanRouteInterval. The Navigation module will then, based on this interval, periodically attempt to find a better alternative to the current route. This is what continuous replanning refers to. BetterProposalAcceptanceMode defines how a better route proposal is handled.

The RouteReplanningEngine provides a default RouteProposalSelector implementation for selecting the best route. This can be configured by setting the following fields in RouteReplanningEngineOptions:

• minTrafficDelay - Minimum traffic delay on the current route to trigger a search for a better alternative.
• minTimeDifference - How much the alternative route has to be faster to be used as a replan proposal.

By default, minTrafficDelay is set to ten (10) minutes and minTimeDifference to five (5) minutes.

1val options = RouteReplanningEngineOptions(
2    minTrafficDelay = minTrafficDelay,
3    minTimeDifference = minTimeDifference
4)
5val engine = RouteReplanningEngineFactory.create(routeReplanner, options)
6val onlineConfiguration = Configuration(
7    context = context,
8    locationProvider = locationProvider,
9    apiKey = apiKey,
10    routeReplanner = routeReplanner,
11    routeReplanningEngine = engine
12)

Providing a custom RouteProposalSelector

If the default implementation of the RouteProposalSelector does not perform as you desire, you can provide your own object when creating the RouteReplanningEngine. Note that it’s up to the provider of the custom route proposal selector to make sure that a reachable proposal is chosen whenever the current route has a blockage.

1val engine =
2    RouteReplanningEngineFactory.create(routeReplanner, options, customRouteProposalSelector)
3val onlineConfiguration = Configuration(
4    context = context,
5    locationProvider = locationProvider,
6    apiKey = apiKey,
7    routeReplanner = routeReplanner,
8    routeReplanningEngine = engine
9)

Replanning response

A better route proposal is added to the navigation session with the following reasons:

• BetterRouteProposed - A better alternative was found for the current route.
• AvoidBlockage - A better alternative has been found due to blockages on the current route.
• WithinRange - Only used in cases where an electric vehicle is navigating: a better alternative has been found due to insufficient battery charge.

Better proposal acceptance mode

There are three ways to handle a better route proposal:

• Automatic - Better route proposals are automatically applied as active routes. The user is informed first by the RouteAddedListener, that the new route was added to the navigation. Then the new route is set as the active route, the ActiveRouteChangedListener notifies the user about the active route change.
• Manual - The better route proposal is added to the navigation session, the user is informed about it by the RouteAddedListener. To apply the found better route, the user must call the TomTomNavigation.selectActiveRoute(RouteId) method. After selecting the new active route, the ActiveRouteChangedListener is triggered.
• UnreachableOnly - The active route is automatically replaced with a better proposal only if the current route contains a blockage or its itinerary is not reachable due to insufficient battery charge. Otherwise, a better route proposal is handled in the same way as in the Manual mode.

Automatic mode is set by default and can be changed by passing the BetterProposalAcceptanceMode to the navigation configuration (e.g., Configuration) during the TomTomNavigation initialization.

1val onlineConfiguration = Configuration(
2    context = context,
3    locationProvider = locationProvider,
4    apiKey = apiKey,
5    routeReplanner = routeReplanner,
6    betterProposalAcceptanceMode = BetterProposalAcceptanceMode.Manual
7)

The current BetterProposalAcceptanceMode can also be checked and changed during runtime, even if the navigation is already started.

navigation.betterProposalAcceptanceMode
navigation.betterProposalAcceptanceMode = BetterProposalAcceptanceMode.Manual

Automatic handling

Replan proposals are applied automatically. The user is notified by the RouteAddedListener, which provides both a new Route and a RouteAddedReason as the reason the new route was added. Then the new route is set as the active route, the ActiveRouteChangedListener notifies the user about the active route change.

1navigation.addRouteAddedListener { route, reason ->
2    /* Your code goes here */
3}
4navigation.addActiveRouteChangedListener { newActiveRoute ->
5    /* Your code goes here */
6}

Unreachable_only handling

Replan proposals are applied automatically only when there is a blockage on the current route or if the current route is unreachable due to an insufficient battery charge (only in an electric vehicle use case). In that case, the user is notified by the RouteAddedListener. The notification is followed by the ActiveRouteChangedListener notifying the user about the active route change.

Manual handling

The obtained route is proposed using the RouteAddedListener with the RouteAddedReason set to BetterRouteProposed. You decide whether the proposed route should be selected as active with selectActiveRoute or ignored. The navigation is then updated with the proposed route.

1navigation.addRouteAddedListener { route, reason ->
2    if (reason is RouteAddedReason.BetterRouteProposed) {
3        navigation.selectActiveRoute(route.id)
4    }
5}

Specifying replanning intervals

By default, the intervals between route updates are set to three (3) minutes. The minimum remaining travel time is set to ten (10) minutes. After this point, route refresh and continuous replanning are automatically disabled.

These parameters can be set in RouteReplanningEngineOptions.

1val options = RouteReplanningEngineOptions(
2    replanRouteInterval = replanRouteInterval,
3    validRemainingRouteDuration = validRemainingRouteDuration
4)
5val engine = RouteReplanningEngineFactory.create(routeReplanner, options)
6val onlineConfiguration = Configuration(
7    context = context,
8    locationProvider = locationProvider,
9    apiKey = apiKey,
10    routeReplanner = routeReplanner,
11    routeReplanningEngine = engine
12)

Replanning on deviation

If a user has deviated from the current route, the navigation informs them of it. The navigation module may do one of the following things:

• Automatically plan a new route. If supporting points are provided in the initial planning stick to the route.
• Wait for the user to manually provide a new route.

A new route is planned by using the route optimization type defined in the RoutePlan.

Stick to route

If supporting points are provided in the initial planning and on navigation start, the current car position is not on the route; navigation generates a route that connects the current car position and the imported route, respecting its geometry. Suppose supporting points are provided in the initial planning, upon deviation. In that case, the generated route preserves the initial route geometry 1km from the deviation point or to the next waypoint, whichever is shorter. If the car continues deviating from the replanned route, a 1km cutoff is doubled after every deviation until the driver starts following the route. A cutoff is the distance at the beginning of the route that is not used as supporting points in the replanning.

Automatic handling

The default is to automatically plan a new route. To turn off automatic route planning, configure TomTomNavigation:

1val onlineConfiguration = Configuration(
2    context = context,
3    locationProvider = locationProvider,
4    apiKey = apiKey,
5    routeReplanner = routeReplanner,
6    deviationReplanningMode = DeviationReplanningMode.None
7)

This means the user doesn’t need to take any action, because the new route is automatically applied. The RouteAddedListener notifies the user when the new route is added to the navigation session. The notification contains the RouteAddedReason.Deviated as the reason for adding the new route and the Route itself. The ActiveRouteChangedListener then notifies the user about the active route change. When the new route becomes active the old route is removed from the navigation session. RouteRemovedListener notifies the user about the removed route.

Manual handling

This is the default route deviation handling strategy. Manual handling means that once a user is informed about a deviation from the route, navigation is stopped. Navigation only starts again once a new route has been planned and started.

A manual route update is made by calling TomTomNavigation.update(NavigationOptions). The NavigationOptions parameter contains RoutePlan. The RoutePlan is built with a Route for the user to follow and the RoutePlanningOptions used for planning that route.

1val routePlan = RoutePlan(route = route, routePlanningOptions = routePlanningOptions)
2val navigationOptions = NavigationOptions(routePlan)
3tomTomNavigation.update(navigationOptions)

To keep navigation guidance consistent, before calling TomTomNavigation.update(NavigationOptions), DepartureInstruction should be filtered out from the proposed route plan. An instruction is just an indicator of starting navigation.

Example of how to remove the DepartureInstruction from the first leg of the route:

1fun Route.removeDepartInstruction(): Route {
2    val firstLeg = legs.first()
3    return firstLeg.instructions
4        .dropWhile { it is DepartureInstruction }
5        .let { newInstructions ->
6            val newFirstLeg = firstLeg.copy(instructions = newInstructions)
7            val oldLegsWithoutFirst = legs.drop(1)
8            val newLegs = listOf(newFirstLeg) + oldLegsWithoutFirst
9            copy(legs = newLegs)
10        }
11}

Replan retry policy

If the replanning is successful, the Navigation module uses the returned route to replace the current one. Otherwise the Navigation module tries to replan the route again. The number of replan attempts and the delay between retries are defined by the ReplanningRetryPolicy interface.

Policy configuration

The default implementation of ReplanningRetryPolicy (see TomTomReplanningRetryPolicy) periodically retries the operation with increasing delays between calls. The default maximum delay time is ten (10) seconds.

The default parameters can also be overridden as follows:

1val replanningRetryPolicy = TomTomReplanningRetryPolicy(
2    maxRetryDelay = maxRetryDelay
3)

Once the policy is configured, it must be provided during initialization of the Navigation module:

1val onlineConfiguration = Configuration(
2    context = context,
3    locationProvider = locationProvider,
4    apiKey = apiKey,
5    routeReplanner = routeReplanner,
6    replanningRetryPolicy = replanningRetryPolicy
7)

Providing a custom replan retry policy

You can also provide your own implementation instead of using the default policy. To do this, implement the ReplanningRetryPolicy interface and pass it during the Navigation module initialization.

Incremental guidance computation

If the guidanceProgressOffset of the route is less than the length in the route summary, the route needs to be updated. Instead of calling the planRoute method, the replanning engine can call the advanceGuidanceProgress method. This adds more instructions and corresponding lane guidance to the route and increases the guidanceProgressOffset of the route.

Next steps

Since you have learned about route replanning, here are recommendations for the next steps:

• Route planning
• Location module quickstart
• Location context