Generate exportable transit isochrone polygons server-side

[Medformatik]

Problem

The transit reachability overlay is useful for interactive exploration, but it is an estimated client-rendered travel-time field. It cannot return valid polygons for export, area/population analysis, or reuse by API consumers.

Current state

• MOTIS one-to-all reachability and exact finite-destination filtering are implemented.
• integrations/overlay-tool-travel-time/transit-field-layer.ts renders continuous WebGL bands and optional samples.
• docs/docs/administration/transit-reachability.md explicitly documents that the field is estimated and not exportable.
• The API already has a Valhalla isochrone provider for non-transit modes.

Proposed solution

Add a bounded server-side transit-isoline composer. For each contour, identify reachable transit stops, compute the remaining walking budget, generate walking catchments, then union, validate, and simplify the geometries. Preserve exact point checks as the source of truth where boundaries are ambiguous and expose provenance/limitations in the response.

Acceptance criteria

• A versioned API accepts origin, departure/arrival semantics, contour times, walking profile, and accessibility options.
• Responses contain valid GeoJSON Polygon/MultiPolygon features with stable contour metadata and attribution.
• Multiple contour thresholds are nested or normalized deterministically.
• Walking-isoline fan-out is concurrency- and size-bounded, cancellable, and protected by request limits.
• Union, holes, antimeridian behavior, invalid-geometry repair, and simplification tolerances are tested.
• Cache keys include schedule/profile inputs and data release identifiers.
• A benchmark compares polygon inclusion with exact destination checks and records error behavior.
• The UI can switch between the current fast field and exportable polygons without regression.
• GeoJSON download is available and clearly marked as modeled/estimated.
• Metrics cover runtime, fan-out, cache hits, geometry size, and failures.

Alternatives considered

• Polygonizing only the WebGL field retains sampling artifacts and lacks a reusable server contract.
• Current MOTIS integration exposes one-to-all results rather than exportable contours.

Area

Transit, routing, geospatial API, map overlays.

Dependencies and non-goals

Station-entrance modeling (#298) can improve access/egress accuracy later. Demographic analysis is not part of this issue.

References

• docs/docs/administration/transit-reachability.md
• integrations/overlay-tool-travel-time/
• https://valhalla.github.io/valhalla/api/isochrone/

[Medformatik]

Implemented on main in 60c989cb (not yet pushed).

Built MOTIS-native rather than as proposed here: transit reachability must not call Valhalla, so instead of unioning per-stop walking catchments, travel times are sampled across a bounded Web Mercator lattice via one-to-many-intermodal and contoured with marching squares (packages/mobility-core/src/isoline/). MOTIS runs one timetable search per request and reuses it for the whole batch, which is what makes sampling affordable.

POST /api/integrations/transit/reachability/isochrone returns nested RFC 7946 contours; the download carries its own sampling resolution, accuracy note, and attribution. The existing WebGL field stays the interactive default and the two are switchable without regression.

The artifact is sampled, never exact — accurate at its sample points and interpolated between them. That wording is kept distinct from the estimated field and from exact point checks in the UI, docs, and export metadata.

Ships with an accuracy benchmark comparing polygon inclusion against exact one-to-many checks. Disabled by default behind exportableIsochronesEnabled; enable only after measuring cost on real hardware, since the tiny local fixture can't give a meaningful latency figure.

Operator docs: docs/docs/administration/transit-reachability.md.