Turn-by-Turn Multi-Location Radius Parameter Issue

[ptncafe]

Hello,
I'm encountering an issue with the "radius" parameter in the turn-by-turn navigation for multi-locations.
When used with a route that includes a polyline crossing a body of water (e.g., a lake), the generated path seems to be incorrect.

Actual Behavior:
The route cross a body of water (e.g., a lake)

Expected Behavior:
The "radius" parameter should influence the generated route to prioritize roads and avoid exceeding the set distance from the provided path (polyline) even when crossing water bodies.

Information:
The request
https://valhalla1.openstreetmap.de/route?json=

{
  "locations": [
    {
      "lat": 21.027679,
      "lon": 105.804755,
      "type": "break",
      "radius": 200
    },
    {
      "lat": 21.024104,
      "lon": 105.807319,
      "type": "via",
      "radius": 200
    },
    {
      "lat": 21.020538,
      "lon": 105.808242,
      "type": "break",
      "radius": 200
    }
  ],
  "costing": "motorcycle",
  "date_time": {
    "type": 1,
    "value": "2024-05-07T11:05"
  },
  "costing_options": {
    "motorcycle": {
      "use_trails": 0.800000,
      "use_highways": 0.400000,
      "ferry_cost": 1200.000000,
      "exclude_unpaved": 0.000000,
      "use_living_streets": 1.000000,
      "use_tracks": 0.800000
    }
  }
}

Result

---

When removing the "radius" parameter from the location array

{
  "locations": [
    {
      "lat": 21.027679,
      "lon": 105.804755,
      "type": "break",
      "radius": 200
    },
    {
      "lat": 21.024104,
      "lon": 105.807319,
      "type": "via"
    },
    {
      "lat": 21.020538,
      "lon": 105.808242,
      "type": "break",
      "radius": 200
    }
  ],
  "costing": "motorcycle",
  "date_time": {
    "type": 1,
    "value": "2024-05-07T11:05"
  },
  "costing_options": {
    "motorcycle": {
      "use_trails": 0.800000,
      "use_highways": 0.400000,
      "ferry_cost": 1200.000000,
      "exclude_unpaved": 0.000000,
      "use_living_streets": 1.000000,
      "use_tracks": 0.800000
    }
  }
}

Result

I'm unsure if this is a bug or if I'm missing a parameter. When I include the 'radius' parameter in the multi-location turn-by-turn request. I've checked the documentation but couldn't find anything related to this behavior.
Could you explain it to me?

Thank you, guys.

[kevinkreiser]

when you use a radius on a location, it tells the route that you'd be willing to consider any edges in the graph within that radius around that location as an origin/destination for a leg of the route (eg. a 3 location route has 2 legs). at the end of the day when we return a route, it has to use only one of the candidate edges for a given locations origin/destination. at the moment, we compute the "legs" of the route in the order you provided (so long as you arent doing an arrive_by route, in which case its in reverse order). if the second location in your route had a bunch of candidate edges, we will have picked one of them as the destination edge in the first leg we computed. we will then force the second leg to start from that same edge candidate even if it would have been less efficient to pick a different edge candidate for the first-destination/second-origin location (ie locations[1]).

this has been a drawback to our approach for many years at this point. one can imagine a better strategy (similar to map matching) in which we try combinations of edge candidates and routes and optimize for the one that reduces the cost the most. this would be an excellent quality of life enhancement if someone had the time to implement it but it wouldnt be free in terms of latency as doing it the naive (maybe only) way means more graph traversal/tracking graph expansion.

[nilsnolde]

but how does that relate to the first pic shown? looks like a crow distance connection entirely unrelated to the network.. never seen that before.. quickly confirmed myself as well

[kevinkreiser]

that depends on what the data is like, specifically the access tags and reacheability. notice the departure time of day in the request. might be time turn restrictions