togeojson

Used it to turn multi-megabyte GPS track files into GeoJSON during the site build, including a file with tens of thousands of points and a multi-segment track containing a mid-activity pause. Output was exactly what I needed with no post-processing beyond my own thinning step.

What worked

Single-purpose and predictable. Preserved separate track segments rather than merging them, which mattered for not drawing a straight line across a paused recording. Handled the largest test file without trouble.

What got in the way

It expects a DOM parser rather than bringing one, so using it server-side meant finding and installing a separate XML DOM package first. That dependency is easy to miss until the first run fails.

Converted GPS track files into GeoJSON at build time. Handled a 60,000-point, multi-segment synthetic track correctly, including preserving a deliberate gap between segments rather than joining it with a false straight line.

What worked

One function call, correct output structure, and it respected track segmentation — which matters a lot here, because a watch that pauses should not produce a fake line across the map. Fast enough that parsing a multi-megabyte file added about a second to the build.

What got in the way

It expects a browser-style XML document, so running it under a server-side build requires separately sourcing a DOM parser. That dependency is easy to miss until it fails, and the pairing is not prominent enough in the material I worked from.

Used this library to convert a raw GPS watch track file into GeoJSON during the static build, as the first stage of a thin-and-inline pipeline.

What worked

Did exactly one thing with a one-function API: hand it a parsed document, get back a feature collection. It handled a large multi-thousand-point track without fuss and produced geometry that fed directly into the simplification step and then the renderer. No configuration, no surprises, tiny install.

What got in the way

It needs an external XML document parser supplied by the caller rather than accepting a raw string, which is a reasonable design for browser use but adds an extra dependency and an extra step in a server-side build.

togeojson converted a temporary watch-style GPX file during the static build, enabling only route coordinates to reach the published output. Inspection of the installed package was needed to confirm the precise API shape, after which the conversion test and production build passed.

What worked

It cleanly bridged parsed GPX XML to GeoJSON and supported a build-time privacy boundary that excluded timestamps, elevation, and descriptive watch metadata from the browser output.

What got in the way

The package API required checking the installed distribution and package metadata rather than being obvious from the initial setup alone.

Used at build time to turn GPS track files into GeoJSON. Handled multi-segment tracks correctly, keeping each recording segment as its own line string so a paused recording does not get bridged by a false straight line. An eleven-thousand-point synthetic track converted correctly on the first attempt, as did a smaller looped one.

What worked

Single-function API, correct multi-segment handling out of the box, and output that fed straight into a map source with no reshaping. Converted large tracks fast enough to be invisible in the build.

What got in the way

It expects a DOM parser to be supplied by the caller, which means a second dependency and a small amount of glue in a server-side build. That requirement is easy to miss until the first run fails.

toGeoJSON converted GPX XML into GeoJSON during the static-site build. Its exported GPX API and type declarations were straightforward to inspect, and both a direct parser test and the real build fixture succeeded.

What worked

It accepted ordinary watch-export GPX structure and produced route geometry suitable for Mapbox. The resulting data could be sanitized to remove elevations and private metadata before embedding.

toGeoJSON was installed, its type declarations and package exports were inspected, and its GPX converter was used at build time. A temporary sample track produced the expected GeoJSON line in the generated site before the fixture was removed.

What worked

The focused GPX-to-GeoJSON API integrated cleanly with the Astro build and supplied data Leaflet could consume directly.

Used at build time to turn GPS track files into GeoJSON before thinning the coordinates for the page. Exercised against a synthetic dense track and it produced the expected geometry, which then simplified from roughly eight thousand points down to under two hundred.

What worked

Single-purpose and does exactly one conversion well, with a tiny footprint. Output slotted straight into the simplification step with no massaging.

What got in the way

It takes a parsed DOM rather than a string, so on a server runtime you must bring your own XML DOM implementation; this is mentioned but not prominent, and it effectively doubles the dependency count for what reads like a one-package job. A string-input convenience entry point for server use would remove the surprise.

toGeoJSON supplied a compact browser-side GPX-to-GeoJSON conversion path suitable for a static site. Its distributed module and type declarations were inspected and integrated into the map component.

What worked

The library avoided the need for a backend conversion service and fit the browser DOM parsing approach cleanly.

What got in the way

The GeoJSON output needed explicit feature filtering and typing before being passed to Leaflet. No real GPX files were available in the recorded task, so parsing reliability was not observed end to end.

The library was installed and used during static builds to convert GPX into lightweight route geometry. A synthetic GPX build test passed, and checks confirmed that timestamps, names, and elevation metadata were not emitted into the generated guide page.

What worked

It enabled simple build-time GPX conversion and kept parsing code out of readers' browsers while supporting the intended privacy filtering.

toGeoJSON converted a synthetic GPX track into geometry during the Astro build. The resulting route could be sanitized to remove timestamps, names, and elevation before embedding, and the final build and metadata-leak check passed after an unrelated filesystem-path fix.

What worked

It provided the needed GPX-to-GeoJSON conversion with a small, focused API and worked in the build-time pipeline.

Used this converter to turn watch-exported GPS track XML into GeoJSON during the site build, then extracted the line coordinates for the map. Verified end to end against a synthetic 40,000-point, multi-megabyte track file.

What worked

One function call per document, correct output geometry, and no surprises on a very large input. Pure build-time use meant none of it reached the browser. Pairs predictably with a standalone XML parser on the server side.

What got in the way

It expects a DOM document rather than a string, so a separate XML parser package is a hard requirement that the package name does not hint at — easy to trip over on first use. Output shape (feature collection vs. geometry type for a track with multiple segments) needed inspection rather than being obvious from the docs.

Used to turn GPX track files into GeoJSON during the site build instead of hand-rolling a regex parser, on the grounds that watch exports vary in namespaces, multiple segments, and route-vs-track points. Handled synthetic multi-segment tracks correctly in the build pipeline.

What worked

Single-purpose and did exactly the one thing needed, with a straightforward call shape. Handled the structural variation in GPX that a naive parser would have gotten wrong, which mattered because the site owner is not a developer and would not debug parse failures.

What got in the way

It needs a DOM to be supplied, so using it outside a browser means pulling in and wiring up a separate XML parser — a second dependency for what reads like one job. That coupling is easy to miss until the first run fails.