My Geocode

Guides

Add elevation data to a GPX route file

· 3 min read · My Geocode · #elevation#gpx#routes#data-enrichment

A GPX file recorded from a phone or a basic GPS device often has elevation values that are missing entirely or noticeably inaccurate, since consumer GPS altitude readings are usually far less reliable than the latitude and longitude they record.

Extracting the points

Parse the GPX file's track points, pulling out just the latitude and longitude for each one, and discard the existing elevation values you plan to replace.

<trkpt lat="45.8326" lon="6.8652"><ele>1050</ele></trkpt>

Looking up correct elevation

Send the extracted coordinates to /v1/elevation, either through the points parameter for a smaller file or a bulk POST array for a larger one.

POST /v1/elevation
Content-Type: application/json

[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]
{
  "status": "ok",
  "results": [
    {"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
    {"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210}
  ]
}

A second example: checking a single trailhead

Not every use needs a full track processed. Before publishing a hike description, a single call confirms the elevation at the trailhead itself.

GET /v1/elevation?lat=45.8326&lon=6.8652

This returns the same result shape with one entry, useful for spot-checking a starting or ending elevation figure quoted in trail notes without needing to touch the full GPX file.

Writing the values back

Results come back in the same order as the coordinates you sent, so write elevation_m back into each track point's ele tag by matching position, replacing the original recorded value with the looked-up one.

<trkpt lat="45.8326" lon="6.8652"><ele>1035</ele></trkpt>

A common mistake to avoid

Do not mix the points query parameter format and a bulk POST body across a single job without being consistent about how you match results back to track points. The points parameter and the JSON array both return results in the order given, but pulling coordinates for one point via a query parameter and the rest via a bulk POST, then merging the two response sets by assumption rather than by explicit coordinate matching, is an easy way to introduce an off-by-one error into the written-back file.

Deciding how many points to enrich

A GPX file can have thousands of track points recorded at short intervals. Enriching every single one is one request per point, which adds up on a long recorded track. Downsampling to a coarser interval before the elevation lookup, then interpolating between the looked-up values for points in between, is a reasonable way to cut down request count while still producing an accurate looking profile.

An edge case: coastal and low-lying points

A track that dips along a coastline or through a low-lying delta can legitimately return an elevation_m value at or near zero, or occasionally a small negative number for land below sea level. Neither is an error. Treat a value near zero as a plausible real reading for that terrain rather than filtering it out as a bad data point.

What it costs

Each enriched point is one request. A modest hiking track with a few hundred points, sampled down from a much larger raw recording, stays well within the 2,500 free requests a day included with every key.

Cleaning up elevation data this way turns a shaky phone-recorded track into something worth sharing or analyzing. The elevation lookup docs describe both the points parameter and the bulk request format.

More in Guides