Enable snapping to closure for the origin of the re-route by default

[LukasPaczos]

There are situations where a user can intentionally turn into, or start a route from an edge that is marked a closed. In these situations, the router would continuously try to reroute the user until they leave the closed edge.

However, we could trust or map-matcher more and always allow for snapping to closures for the origin of the route which would prevent continuous reroutes and only attempt to drives us out of the closer as soon as possible.

cc @dudeuter

[LukasPaczos]

cc @mskurydin

[mskurydin]

It's more of a question of whether the routing engine allows starting from such edges. We pass a coordinate of the origin (potentially, with some additional data). Potentially, snapping_include_closures may help here:

[LukasPaczos]

Yes, this is exactly the param we'd want to use for the first waypoint of the route.

[dudeuter]

@mskurydin For devices with precached tiles prior to a closure, I'm assuming nav-native will happily match to them. But do the nav-native tiles contain closures, and if so will enhanced location avoid closures?

@LukasPaczos with respect to snapping_include_closures do we already imply that the expected default behavior of a route request is to start at the current location of the vehicle?

For example even in:

mapbox-navigation-android/libnavigation-base/src/main/java/com/mapbox/navigation/base/extensions/RouteOptionsEx.kt

Lines 82 to 96 in 12361fa

	/**
	* Takes a list of [Point]s and correctly adds them as waypoints in the correct order.
	*
	* @receiver RouteOptions.Builder
	* @param origin Point
	* @param waypoints List<Point?>?
	* @param destination Point
	* @return RouteOptions.Builder
	*/
	@JvmOverloads
	fun RouteOptions.Builder.coordinates(
	origin: Point,
	waypoints: List<Point>? = null,
	destination: Point
	): RouteOptions.Builder {

We accept a Point for the origin parameter instead of a LocationProvider, so it's not explicit that the origin should always be the device position.

I suppose we could add an extension function that does accept a LocationProvider for the origin waypoint, and also sets this (and possibly other Directions API parameters that may help in the case that we're assuming LocatonProvider will know that we're on a road).

[LukasPaczos]

Circling back to this ticket, @browndp08 @stari4ek should Nav SDKs default to including the origin of the route in snapping_include_closures?

do we already imply that the expected default behavior of a route request is to start at the current location of the vehicle?

We don't for the initial route request, we do for reroutes though, and we have a utility on the way that would pick the current vehicle's location automatically also for initial requests - #5427.

[LukasPaczos]

Capturing from the team discussion, renaming the ticket to track the change to our re-route controller to apply snapping_include_closures=true for the origin of each re-route request. The default request can remain as is.