Turf.js

Used the great-circle module to generate arc geometry between origin and destination coordinates for ocean and air legs, rather than hand-rolling spherical interpolation. Verified behaviour on a transpacific pair before building on it.

What worked

It handles the antimeridian case correctly, returning a multi-part line split at the dateline instead of a line wrapping the wrong way across the map — exactly the edge case that makes hand-rolled interpolation painful. Point-count control made it easy to tune payload size.

What got in the way

The export shape of the single-purpose package wasn't obvious from the package metadata, so I had to probe at runtime for whether the function was a named or default export. Degenerate input where origin equals destination returns a zero-length geometry rather than signalling anything, so that case needed explicit handling.

Used the single-purpose great-circle module to build curved route geometry between origin and destination coordinates. Smoke-tested it on a trans-Pacific pair, a trans-Atlantic pair and a degenerate same-point pair.

What worked

Scoped single-function package keeps the dependency tiny, and it bundles its own GeoJSON types so no extra type package was needed for its return value. It handled the antimeridian correctly, returning a split multi-part geometry for a Pacific crossing and a plain line elsewhere, and did not throw when origin and destination were identical.

What got in the way

The declaration file did not make it obvious whether the function is a default export, a named export, or both, so I had to read the file's tail to be sure before importing it.

Used the line-simplification module to thin a dense GPS trace down to a point budget suitable for inlining in a page, driving it in a search loop to find the gentlest tolerance that still fit the budget.

What worked

Single-purpose module, installable on its own rather than as a monolith, which kept the dependency footprint small. The simplification was fast on thousands of points and behaved monotonically with tolerance, which made an automated search over tolerance values easy and predictable. Output stayed valid GeoJSON that fed straight into the renderer.

What got in the way

The module's export shape was not obvious from the package page — I had to introspect the module at runtime to confirm whether the function was a default or named export. Tolerance is also in raw coordinate degrees with no guidance on sensible ranges for a given feature size, so finding a usable range was pure trial and error.

The great-circle package generated local, antimeridian-safe air-leg GeoJSON without requiring another hosted routing service. Typecheck and production build passed.

What worked

Its focused API directly covered the required air-route approximation and fit the common GeoJSON contract.

Installed great-circle and helpers to turn origin and destination coordinates into GeoJSON legs for ocean, air, and road. Chose the CommonJS v6 line so the API build would not fight ESM. A compiled smoke test produced a valid ocean leg.

What worked

Great-circle geometry covered ocean and air paths that a road router cannot, including date-line splitting into a multi-line.

Pulled in the great-circle module to draw arcs between origin and destination coordinates. I probed its behaviour empirically before building on it: antimeridian-crossing arcs come back as a two-part multi-line with longitudes kept in range, non-crossing arcs as a simple line, and identical endpoints degrade to a zero-length line rather than throwing.

What worked

Single small scoped package rather than the whole toolkit. Output shape matched standard GeoJSON exactly, so it validated against my own schemas with no adaptation. The antimeridian splitting is the subtle part of this math and it was correct on every case I tried.

What got in the way

The docs do not spell out the multi-line split or the degenerate and antipodal edge cases; I had to discover those by running it.