Isochrones API FAQ

Why can I request a walking or cycling isochrone for up to 2 hours, but driving is capped at 1 hour?

This limitation is based on the computational complexity of the calculations. A vehicle travels significantly farther than a pedestrian or cyclist over the same duration, which means the underlying road network that must be analyzed expands exponentially. Driving is constrained to a 1-hour maximum (3,600 seconds)o ensure the API can return a response within a fast, real-time synchronous window, while walking and cycling are supported for up to 2 hours (7,200 seconds).

How do I calculate an inbound "commute-to-work" isochrone (traveling to a destination) versus an outbound isochrone (traveling from an origin)?

Both inbound and outbound calculations are supported in the v1 API using the travel_direction parameter:

  • FROM (Outbound): Calculates the area reachable from the origin point within the specified time limit. This is suitable for use cases like delivery zones or service coverage.

  • TO (Inbound): Calculates the area from which you can travel to the origin point within the specified time limit. This is suitable applications like commute-to-work features or determining catchment zones around a central office or transit hub.

Sometimes the returned polygon looks blocky or has jagged, stepped edges, especially for longer durations. Why does the level of detail change?

Isochrones API dynamically adjusts the resolution of its spatial calculation grid based on the requested travel_duration and travel_mode:

  • Shorter Durations: Use a highly refined, high-resolution grid because the total area is small, resulting in a detailed boundary.
  • Longer Durations: Transition to a coarser, lower-resolution grid to cover the vast geographic area efficiently without causing severe latency.

You can set the optional polygon_fidelity to HIGH, MEDIUM, or LOW if you require a specific, consistent level of detail regardless of duration.

Why does requesting an isochrone for a coordinate inside a park, lake, or large industrial complex sometimes return a "Not Found" error?

Isochrones API calculates travel times using roads and pathways. The API must "snap" the point to the nearest compatible segment before starting the calculation if your requested origin coordinates are not located on a recognized road.

Each travel mode has a specific maximum snapping distance threshold:

  • DRIVE: 200 meters (ignores pedestrian-only paths).
  • BICYCLE: 180 meters.
  • WALK: 150 meters.

If your origin coordinate lies further from a valid, mode-compatible road segment than these thresholds, snapping fails, and the API returns a NOT_FOUND error. To resolve this, ensure your coordinates are positioned close to a public street or pathway.

When I render the GeoJSON response on my map, the shape is displayed in the wrong place, is distorted, or fails to render. What is causing this?

This is almost always caused by a coordinate order mismatch.

Following the GeoJSON standard (RFC 7946), Isochrones API returns coordinates in the order of [longitude, latitude]. However, many mapping SDKs, including the Google Maps JavaScript API and various mobile map components, expect coordinates or LatLng objects in the order of [latitude, longitude].

If your map rendering is incorrect, you must loop through the coordinates in the GeoJSON payload and transpose the values before passing them to your map SDK.

Why are there hollow "holes" inside my isochrone polygon, and can I get a solid shape instead?

Holes represent areas with no reachable roads within the time limit. This is common in regions with large forests, water bodies, airports, or private properties where vehicles or pedestrians cannot travel.

The external v1 API does not expose a parameter to automatically remove holes. If your application requires a solid boundary, for example, to perform point-in-polygon containment checks, you can:

  • Set the polygon_fidelity parameter to MEDIUM or LOW to encourage the algorithm to generalize and merge over these internal gaps.
  • Use a client-side GIS library (such as Turf.js) to parse the GeoJSON and extract only the first coordinate ring (the exterior shell), discarding any subsequent interior rings (the holes).

Should I enable the enable_smoothing option for backend spatial analysis?

No. The enable_smoothing parameter is designed purely for visual aesthetics. It rounds off the sharp corners of the underlying calculation grid to make the shape look organic on a map.

Smoothing is not recommended for precise spatial analysis because it alters the vertices and shifts the boundaries slightly. For backend calculations, database queries, or point-in-polygon tests, keep enable_smoothing set to false to ensure you are using the mathematically precise calculated boundary.