Reduce hard-coded isochrone smoothing factor in gateway to speed up large isochrones

[sfc-gh-obielov]

Context

The routing gateway hard-codes 'smoothing': 10 in the isochrones request payload sent to ORS:

• services/gateway/routing_service.py line 453 (_handle_isochrones_tabular)
• Same file, line 479 (post_isochrones_tabular)

output_rows.append([row[0], get_ors_response('isochrones', row[1], {
    'locations': [[row[2], row[3]]],
    'range': [row[4] * 60],
    'location_type': 'start',
    'range_type': 'time',
    'smoothing': 10
}, format, ors_host)])

Problem

smoothing controls the polygon-densification pass ORS runs over the reachable cell set after the Dijkstra flood-fill completes. Larger values produce smoother polygons but cost extra compute and memory. On continental graphs (e.g. USA driving-hgv, no fastisochrones enabled), the polygon at large ranges is huge and the smoothing pass adds a meaningful fraction of the gateway timeout budget — not the dominant cost, but a noticeable slice.

We just bumped the gateway timeout for isochrones to 300 s and added an engine-side maximum_range_time: 7200 cap (separate change). Reducing or making smoothing configurable is the cheap follow-up that buys more headroom without a graph rebuild.

Proposed fix

Make smoothing an optional caller-controlled parameter (default 0 or omit entirely):

1. Add an optional smoothing INT parameter to:
   • OPENROUTESERVICE_APP.CORE.ISOCHRONES(method, lon, lat, range, region [, smoothing])
   • _ISOCHRONES_RAW service function
2. Update the gateway endpoints (_handle_isochrones_tabular, post_isochrones_tabular) to forward the smoothing value if present, omit the key otherwise (ORS default behaviour).
3. Default to smoothing=0 in the SQL function to skip the smoothing pass unless the caller asks for it.

Acceptance criteria

• USA HGV isochrones at range = 120 min return at least 5 s faster than baseline.
• Existing callers that pass 4 args still work (signature stays backwards compatible).
• Re-deployed gateway image bumped from routing_reverse_proxy:v1.0.2 to v1.0.3.

Related

• Plan: investigation of HGV USA isochrones gateway timeout. Already deployed: gateway timeout 120s -> 300s for isochrones, engine-side maximum_range_time 2147483647 -> 7200.
• See routing_service.py:_probe_ors_state for warming-up vs computation-time distinction.

[sfc-gh-obielov]

Addressed in PR #120 (commit b930b04).

Implementation in 02_routing_functions.sql:

• New 6-arg ISOCHRONES(method, lon, lat, range, smoothing, region) overload — caller-controlled smoothing.
  • 0 = engine default (fastest, no smoothing pass).
  • 10 = previously hard-coded gateway value.
  • 50 = engine maximum (slowest, smoothest polygon).
• 5-arg legacy form retained — gateway treats missing smoothing as omitted (engine default), so existing callers get faster isochrones immediately without any code change.

Backward-compatible function overloading; both forms have COMMENT tracking tags.