Directions API accurate target distance response

[skunkgroup]

I am looking to create a round_trip route using the directions API that is within ideally a 10% threshold of a target distance. Everything works okay up until around 10km, for example when I set the target distance to be around 21km I get a 38km round trip returned. Has anyone else had this issue? If so, how did you tackle it?

Here is my implementation so far:

async function createNonBacktrackingRoute(center: [number, number], distanceInMeters: number, transitType: string) {
	// For round_trip, we only need the starting point
	const coordinates = [center];

	try {
		const response = await axios.post(`https://api.openrouteservice.org/v2/directions/${transitType}`, {
			coordinates: coordinates,
			radiuses: Array(coordinates.length).fill(5000),
			instructions: false,
			geometry: true,
			preference: 'recommended',
			options: {
				round_trip: {
					length: distanceInMeters,
					points: 4
				},
			}
		}, {
			headers: {
				'Authorization': process.env.HEIGIT_OPEN_ROUTE_SERVICE_KEY,
				'Content-Type': 'application/json'
			}
		});

		return response.data;
	} catch (error) {
		console.error('Route creation failed:', error);
		throw error;
	}
}

[jschnell]

Hey,

the round_trip-feature is and has always been a bit tricky and experimental.
How it roughly works internally is that there are points generated in a rough circle that might approach such a route, and then an actual route is being calculated using these points.

I recommend you have a look at the actual results - maybe beyond a certain range, one of the points falls on the other side of a river and thus long detours have to be taken to reach that point?

There is a bit of randomness in there, so it is quite hard to talk about these things, so it would make sense if you used "options":{"round_trip":{"seed":5}}} to seed the roundtrip generation, so that results stay deterministic.

Ideally, you could share a seeded request including coordinates and an image of the output.

Best regards

[skunkgroup]

Thank you for your reply!

How it roughly works internally is that there are points generated in a rough circle that might approach such a route, and then an actual route is being calculated using these points.

Does this mean more points may generate a more accurate total distance?

I recommend you have a look at the actual results - maybe beyond a certain range, one of the points falls on the other side of a river and thus long detours have to be taken to reach that point?

Could you expand on this point please

I have provided a seeded requested included coordinates and an image output as requtested:

await axios.post(`https://api.openrouteservice.org/v2/directions/foot-walking`, {
	coordinates: [[-2.744496, 53.722504]],
	radiuses: [5000],
	instructions: false,
	geometry: true,
	preference: 'recommended',
	options: { round_trip: { length: 21000, points: 4, seed: 5 } }
}, {
	headers: {
		'Authorization': process.env.HEIGIT_OPEN_ROUTE_SERVICE_KEY,
		'Content-Type': 'application/json'
	}
});

[amandus]

for the current request the 4 points (including the starting point) look somewhat like this:

the seed defines the angle the points are placed in.

More points wouldn’t solve the issue as then it would look like:

and would still need to cross the bridge to connect the 2 points on the left.

So the length you provide is just a proxy for how far apart it should place the routing points, not how long the result route will be.

Best regards

[skunkgroup]

I found a potential solution to this using the seed value. I create a maximum of 5 routes, and set a tolerance level of 15-20% (still tweaking). Each time I generate a route I increase the seed value (1, 2, 3 etc).

If the generated route is within the tolerance threshold I return it, otherwise I generate all 5 and then return the closest one to the target distance.

[amandus]

Sounds good if it’s working.

It is a very basic implementation, it would make more sense to have an angle (0-360) you could pass instead of a seed.
The randomness could happen before the request in the frontend.

[skunkgroup]

I wasn’t aware the API accepted an angle? I looked at the documentation and didn’t see that. Can you point me to this please?

[amandus]

It currently doesn’t… that’s why i’m saying, it would make sense to have one instead of the seed parameter (you could then still randomize the angle on your end before sending the request)

[skunkgroup]

Got you, and yes this would make sense and be very useful. If this was implemented I’d swap out my current implementation in favour of it since its a more predictable approach but at the moment my implementation produces acceptable responses.