How to Convert GPS Data (KML & GPX) to GeoJSON for Web Mapping
If you're building a web mapping application with libraries like Mapbox, Leaflet, or Google Maps, you will almost certainly encounter GeoJSON. It is the absolute standard format for representing geographic data structures (Points, LineStrings, Polygons) in JavaScript.
However, a problem arises when clients or external hardware provide tracking data in legacy formats. Let's look at why this happens and how to convert them quickly.
The Challenge: GPX and KML
- GPX (GPS Exchange Format): This is an XML schema heavily used by GPS devices, fitness trackers (like Garmin or Strava), and geocaching software to describe waypoints, tracks, and routes.
- KML (Keyhole Markup Language): This XML notation is famously used by Google Earth and Google Maps to express geographic annotation and visualization.
Both of these are XML-based formats. Parsing XML on the frontend in a modern React or Vue application is notoriously slow, complex, and prone to cross-browser quirks. GeoJSON, on the other hand, is native JSON, meaning you can instantly parse it with JSON.parse() or import it directly as a JavaScript module.
The Solution: Conversion to GeoJSON
By converting your GPS tracks into GeoJSON before you deploy them or load them into your mapping library, you save significant parsing overhead and ensure cross-platform compatibility.
While you could write Python scripts using the gdal library or install heavy CLI tools, sometimes you just need to convert a few files instantly without touching a terminal.
How to Convert Your Data Instantly
At DuckConvert, we built an in-browser processing engine that parses complex XML schemas and exports native, structured JSON arrays completely locally.
Because our converters run inside your browser, you never have to upload sensitive client location data or personal fitness tracks to a remote server. Everything is parsed on your local CPU.
If you're dealing with standard tables of coordinates, we also support tabular data transformation:
Keep your data secure, streamline your web maps, and build faster applications today!
GeoJSON has rules that GPS files routinely break
RFC 7946 is stricter than the loose "JSON with coordinates in it" people often assume, and a converted file can be technically invalid in ways that only surface once a particular library refuses it.
Coordinates must be in WGS 84, the datum GPS itself uses, so data straight off a device is already correct. Data that has passed through a national grid, British National Grid or a State Plane system, has not been, and needs reprojecting rather than converting. Coordinates that land a few hundred metres from where they should be are almost always a datum problem, not a precision one.
Polygons have a winding rule: exterior rings counter-clockwise, interior rings clockwise. A polygon drawn the other way round is still parsed by most libraries, but some renderers will fill the entire world except your shape, which is a memorable way to discover the rule exists.
Geometries should not cross the antimeridian. A line running from Japan to Alaska written as a single segment is interpreted by many tools as going the long way around the globe, drawing a stripe across the entire map. The specification asks you to split such a geometry at 180 degrees into two pieces.
Coordinate precision is where the file size is
This is the highest-value thing to know about GPS data on the web. A GPS logger recording every second writes coordinates with far more decimal places than anything can use, commonly thirteen or fourteen.
The seventh decimal place of a degree is about a centimetre. The sixth is about ten centimetres, the fifth about a metre, and the fourth about eleven metres. Consumer GPS is accurate to a handful of metres at best, so every digit past the sixth is recording noise with great conviction.
Rounding a track to six decimal places typically halves the file with no visible change whatsoever, and five is usually plenty for anything displayed at city zoom. On a route with 40,000 points, that is the difference between a map that loads instantly and one that stalls the main thread while parsing.
Simplify before you render, not after
Precision is only half of it. The other half is how many points there are at all. A three-hour ride logged at one point per second is over 10,000 coordinates, and at the zoom levels most maps are actually viewed at, the vast majority contribute nothing you could see.
The Ramer-Douglas-Peucker algorithm is the standard fix: it drops points that fall within a chosen tolerance of the line their neighbours already describe. Set the tolerance to roughly the distance a single screen pixel represents at your maximum zoom and you can commonly discard 90% of the points with no visible difference to the rendered line.
Keep the full-resolution file if you plan to compute distance, elevation gain or pace from it, because simplification changes all three. Serve the simplified one to the map. Those are different jobs and there is no reason the same file has to do both.