When requesting isochrones individually for different time limits, a shorter isochrone (e.g., 180 seconds) can strangely expand beyond the boundaries of a longer isochrone (e.g., 300 seconds) starting from the same point.
This creates a topologically impossible result and confuses users.
However, if I use the multi-bucket approach within a single request (e.g., requesting a 300s limit with buckets=2 or specific time buckets), the layers are nested correctly, and the issue does not occur.
Steps to Reproduce
- Request 1 (Short Isochrone):
HTTP
GET /isochrone?point=55.750728,37.609623&buckets=1&time_limit=180&profile=foot
- Request 2 (Long Isochrone):
HTTP
GET /isochrone?point=55.750728,37.609623&buckets=1&time_limit=300&profile=foot
- Compare the geometries. You will see areas included in the 180s polygon that are completely missing from the 300s polygon.
*(Note: If you run a single multi-bucket request like time_limit=300 with buckets, the 150s/180s internal boundary stays strictly inside the 300s boundary).
*
Expected Behavior
The polygon for a shorter time limit ($T_1$) should always be strictly contained within (or match, but never exceed) the polygon for a longer time limit ($T_2$), given identical coordinates and profiles
Actual Behavior
The 180-second polygon “leaks” outside the 300-second polygon in certain directions.
