GPX Files Explained: Distance, Elevation and Converting to GeoJSON

A GPX file is just XML listing GPS track points — latitude, longitude, elevation, time — and from that you can compute a route’s distance (sum the haversine gaps between points) and elevation gain (sum the ups). But two things trip people up: converting to GeoJSON flips the coordinate order, and a GPX track quietly reveals exactly where you live. Here’s how it all works, done in your browser with the GPX Analyzer, GPX→GeoJSON and GeoJSON→GPX tools.

What’s inside a GPX file

Open one in a text editor and you’ll see plain XML:

<trkpt lat="51.5090" lon="-0.1000">
  <ele>25</ele>
  <time>2024-05-01T07:08:00Z</time>
</trkpt>

A track is an ordered list of these <trkpt> points; a waypoint (<wpt>) is a standalone marked location. Each point carries a latitude and longitude, usually an elevation in metres, and often a timestamp. That’s the whole format — which is why every GPS app can read every other app’s export.

The full document has a little more scaffolding. A <gpx> root element wraps everything and declares a version (1.1 is the current schema) and the software that created it. Inside, a track (<trk>) can be split into one or more segments (<trkseg>) — a new segment usually marks a gap where GPS signal dropped, so tools should not draw a straight line across it. Two other element types round out the format:

Element	XML tag	What it represents
Track point	<trkpt>	One recorded position along a continuous path
Track segment	<trkseg>	A contiguous run of track points (a new one signals a signal gap)
Waypoint	<wpt>	A single named point of interest, independent of any track
Route	<rte> / <rtept>	A planned turn-by-turn path, not a recorded one

The distinction between a track (where you actually went, logged automatically) and a route (where you plan to go, often just a handful of turn points) matters when you convert: a dense track becomes a detailed line, while a sparse route becomes a coarse one. Coordinates are always in the WGS 84 datum — the same reference frame GPS itself uses — so no reprojection is needed when moving to GeoJSON, which also assumes WGS 84.

How distance and elevation are computed

Distance is the sum of the straight-line (great-circle) distance between each consecutive pair of points, using the haversine formula on the Earth’s radius. No single point has a “distance”; the route length emerges from adding thousands of tiny hops.

Elevation gain sums only the upward changes between consecutive points (and loss sums the downward ones). So a rolling route can have hundreds of metres of gain even if start and finish are at the same height.

Speed and pace need the timestamps: divide total distance by the time from the first to the last point. Moving speed goes further and drops the paused segments — the stretches where consecutive points barely change over several seconds — so it reads faster than the raw start-to-finish average.

A worked example

Say three consecutive points read 25 m, 31 m, and 28 m of elevation. The gain is the sum of the positive steps only: 31 − 25 = +6 m, then 28 − 31 = −3 m (ignored for gain, counted as loss). So this tiny stretch contributes 6 m of gain and 3 m of loss, even though the net change is just +3 m. Now repeat that over 4,000 logged points on a rolling route and you can accumulate several hundred metres of gain on a loop that starts and ends at the same altitude. That is exactly why “elevation gain” is almost always much larger than the difference between your highest and lowest points.

Distance works the same way by accumulation. Two points a few metres apart contribute a few metres to the total; there is no single “distance” attached to any one point. The haversine formula treats each hop as an arc on a sphere of roughly 6,371 km radius (Earth’s mean radius), which is accurate to well under a metre at the scale of consecutive GPS samples.

→

Route stats distance · elevation ↑↓ moving time · speed · pace (speed/pace need timestamps) Converting to GeoJSON flips the coordinate order GPX: lat="51.5" lon="-0.1" → GeoJSON: [-0.1, 51.5] lat, lon → [lon, lat] · forget the swap and every point lands in the wrong place

Accuracy caveats (why your numbers won’t perfectly match Strava)

• Distance depends on point density. Sparse logging “cuts corners,” reading a bit short. Different apps also smooth GPS jitter differently.
• Elevation is the noisy one. GPS altitude is imprecise; each platform filters it before summing, so elevation gain legitimately varies between tools. Barometric altimeters beat GPS here.

The GPX Analyzer sums the raw points without smoothing, so treat its numbers as a faithful reading of your file, not a claim that every app should agree to the metre.

The GeoJSON coordinate trap

If you take one thing away: GPX writes latitude then longitude; GeoJSON (RFC 7946) requires [longitude, latitude] — the opposite order. Copy the numbers across without swapping and every point plots in the wrong place, frequently the wrong hemisphere. It’s the single most common GPX↔GeoJSON bug.

The reason the two formats disagree is historical. GPX inherited the “latitude, longitude” ordering people say out loud (“fifty-one north, zero west”). GeoJSON, standardised as RFC 7946 in 2016, deliberately fixed coordinates as [x, y] — and on a map x is longitude (east-west) and y is latitude (north-south). Both are internally consistent; they just disagree, and the numbers look identical, so a copy-paste error is silent until you see your London ride plotted somewhere off the coast of Africa.

Once converted, a track becomes a GeoJSON LineString and each waypoint a Point, all wrapped in a FeatureCollection:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "LineString",
        "coordinates": [[-0.1000, 51.5090], [-0.1002, 51.5094]]
      },
      "properties": {}
    }
  ]
}

Note the [lon, lat] pairs. GeoJSON has no dedicated slot for elevation the way GPX does, but the spec allows an optional third number in each coordinate — [lon, lat, elevation] — so a good converter can preserve altitude there rather than dropping it.

Convert cleanly in both directions — GPX→GeoJSON for web maps (Mapbox, Leaflet, Turf.js, PostGIS) and GeoJSON→GPX to load a web-designed route onto a Garmin or phone — and the swap is handled for you.

Which format for which job

Task	Use GPX	Use GeoJSON
Load a route onto a Garmin, Wahoo or phone app	Yes	No
Draw a track on a Leaflet or Mapbox web map	No	Yes
Analyse geometry with Turf.js or store in PostGIS	No	Yes
Share a recorded ride with another athlete	Yes	Rarely
Keep per-point timestamps and heart-rate extensions	Yes	Limited

In short: GPX is the lingua franca of devices, GeoJSON is the lingua franca of web maps and spatial tooling. Converting between them is routine — the only real hazard is the coordinate order.

Why GPX privacy matters

A GPX track is not anonymous data: its first and last points are, very often, your home. Uploading your rides to a random “GPX viewer” hands a stranger your address, your routine, and where you’ll predictably be at 7am. That’s why every LazyTools GPX tool reads the file in your browser and never uploads it — the analysis and conversions happen on your device and work offline.

The bottom line

A GPX file is a list of GPS points; distance is the summed haversine gaps, elevation gain is the summed ups, and speed/pace come from the timestamps. Converting to GeoJSON means swapping to [lon, lat] order. And because that list of points maps your life, do it privately — with the GPX Analyzer and the GPX↔GeoJSON converters that keep your track on your own machine.