My Geocode

Guides

Build an elevation profile for a hiking or cycling route

· 3 min read · My Geocode · #elevation#routes#hiking#cycling

An elevation profile is just a list of points with a height attached to each one, plotted against distance along the route. The elevation endpoint gives you that height for as many points as you send it, in a single call.

Sending the route

Pass a series of latitude and longitude pairs with the points parameter, separated by pipes, with each pair separated by a comma.

GET /v1/elevation?points=45.8326,6.8652|45.8400,6.8700|45.8475,6.8750
{
  "status": "ok",
  "results": [
    {"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
    {"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210},
    {"lat": 45.8475, "lon": 6.8750, "elevation_m": 1390}
  ]
}

Turning results into a profile

Each item in results lines up with the point you sent at the same position. Pair elevation_m with the cumulative distance between consecutive points, which you calculate from the coordinates yourself, and you have the x and y values for a profile chart without any further lookups.

A shorter example using a bulk body

If you would rather send a structured array instead of the pipe-separated points parameter, POST a JSON array of coordinate objects to /v1/elevation the same way the other endpoints accept bulk bodies.

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

[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]

Either way, the cost is the same, one request per point, so pick whichever shape is easier to build from the data structure you already have, a query string built from an array or a JSON array built the same way.

Choosing point spacing

A route with a hundred GPS points every few meters does not need elevation at every single one to draw a readable profile. Sampling every twentieth or fiftieth point along a long route, or resampling to even distance intervals, keeps the chart smooth while cutting down on request count, since each point in the points parameter counts as one request.

A mistake worth avoiding

Treating elevation_m as accurate down to the centimeter is asking more of the data than an elevation profile needs. The value is precise enough to draw a smooth, readable profile and to compute a sensible total gain, but two points a meter apart on flat ground can return slightly different readings that mean nothing about the actual terrain. Build your chart and your gain calculations to tolerate that kind of small noise rather than treating every fluctuation as a real feature of the route.

An edge case over water or unmapped terrain

A point that falls over open water or in an area with little elevation data may return a low or flat value rather than an error. If your route includes a ferry crossing or a stretch through remote terrain, sanity check unusually flat stretches of your profile against the map itself rather than assuming the number always describes solid ground.

What it costs

A hundred-point profile is a hundred requests, well inside the 2,500 free requests a day included with every key or from a single address without one. A route-planning tool serving many users a day should still watch its quota headers, since elevation profiles for popular routes add up faster than single lookups.

Elevation data turns a flat map into something a hiker or cyclist can actually plan around. The full parameter list is on the elevation lookup docs page.

More in Guides