Inconsistent Isochrone Containment When Using Separate vs. Combined Ranges

[maze2point0]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

Summary:
When generating isochrones via the isochrones/driving-car endpoint, I noticed that isochrones generated with separate requests for each range do not always properly nest, i.e., a higher-range isochrone does not necessarily contain a lower-range one. This breaks expected behavior and results in inconsistencies that affect downstream analyses. When not using separate requests, the ranges are topological correctly nested however odd shapes can occur that are different from separate range generated isochrones.

Context
I’m using openrouteservice to calculate isochrones for accessibility studies (e.g., 30- and 40-minute car travel ranges). Correct topological nesting (i.e., higher ranges always containing lower ones) is essential for producing clean range intervals and population overlays.

📍Issue 1 – Separate Requests Cause Invalid Nesting

Example: Andorra (30 vs. 40 minutes driving)
Using two separate requests:

# 30-minute
curl -X POST https://api.openrouteservice.org/v2/isochrones/driving-car \
-H 'Authorization: API_KEY' \
-H 'Content-Type: application/json' \
-d '{"locations":[[1.5307697660817783,42.50694164274659]],"range":[1800],"range_type":"time","smoothing":1}'

# 40-minute
curl -X POST https://api.openrouteservice.org/v2/isochrones/driving-car \
-H 'Authorization: API_KEY' \
-H 'Content-Type: application/json' \
-d '{"locations":[[1.5307697660817783,42.50694164274659]],"range":[2400],"range_type":"time","smoothing":1}'

Screenshot 🟥 Red = 40 min, 🟦 Blue = 30 min

Expected Behavior – Combined Request Works Fine

In the screenshot, you can see that the 30-min isochrone extends beyond the 40-min one in two regions, which should not be possible (circled for clarity):

When using a single request with multiple ranges:

curl -X POST https://api.openrouteservice.org/v2/isochrones/driving-car \
-H 'Authorization: API_KEY' \
-H 'Content-Type: application/json' \
-d '{"locations":[[1.5307697660817783,42.50694164274659]],"range":[1800,2400],"range_type":"time","smoothing":1}'

The resulting isochrones properly nest (30 min is always inside 40 min):
Though some irregular shapes occur, they are topologically correct.

⚠️ Issue 2 – Odd Shapes in Combined Range in Rwanda

In another case using range_type: distance, the combined request produced unusually shaped and disconnected isochrone rings.
Location: Rwanda, origin at 29.233557, -2.6216718.

Single high-range request (50 km):

curl -X POST https://api.openrouteservice.org/v2/isochrones/driving-car \
-H 'Authorization: API_KEY' \
-H 'Content-Type: application/json' \
-d '{"locations":[[29.233557,-2.6216718]],"range":[50000],"range_type":"distance","smoothing":1}'

Combined request with stepped distance ranges:

curl -X POST https://api.openrouteservice.org/v2/isochrones/driving-car \
-H 'Authorization: API_KEY' \
-H 'Content-Type: application/json' \
-d '{"locations":[[29.233557,-2.6216718]],"range":[30000,35000,40000,45000,50000],"range_type":"distance","smoothing":1}'

Result shows fragmented rings and discontinuities across ranges::

Grey shape in the background is a single 50km range. Yellow to green to dark blue shapes are ranges of 50km/5km intervals. Origin for both is the red star in the lower right corner.

Proposed solution

I will implement a post-processing step in my pipeline that:

• Computes each isochrone separately,
• Differences the higher intervals from the lower ones to simulate nested rings,
• But this adds unnecessary overhead and deviates from expected ORS behavior imho.

Would it be possible to:

• Ensure range nesting consistency across separate requests,
• Investigate and document behavior differences between single and multi-range calls,
• Optionally expose a parameter or internal mechanism to ensure containment logic is always applied?

Thank you for your great work on openrouteservice – it’s a fantastic tool! Happy to share more data or assist with reproducibility if helpful.

Additional context

No response

Forum Topic Link

No response