lat lon lat lon lat lon

6 August 2021

Geospatial API designers have yet to settle on a standard for representing a series of points in a request URL.

Here’s how some APIs handle it.

Google Maps Elevation API

A locations query argument, with either a polyline prefixed by enc:

?locations=enc:<polyline>

or | delimited lat,lon pairs

?locations=<lat1>,<lon1>|<lat2>,<lon2>

OSRM

The final component of the URL, as either a polyline wrapped in polyline()

.../polyline(<polyline>)

or ; delimited lon,lat pairs

.../<lon1>,<lat1>|<lon2>,<lat2>

The Mapbox geocoding API uses a similar format.

Mapzen

A json query argument, that takes either a polyline in a encoded_polyline key

?json={"encoded_polyline": "<polyline>"}

or an array of points in a shape key:

?json={"shape":[{"lat":<lat1>,"lon":<lon1>},{"lat":<lat2>,"lon":<lon2>}]}

Graphhopper

Repeated point query arguments in lat,lon order

?point=<lat1>,<lon1>&point=<lat2>,<lon2>

HERE routing

Repeated via query arguments in lat,lon order

?via=<lat1>,<lon1>&via=<lat2>,<lon2>

Some notes

• Many APIs (like Open Topo Data) use one of the above formats. The Google Maps format has become fairly common among elevation APIs, likely because it came first.
• This post was inspired by Tom MacWright’s summary of the lat,lon vs lon,lat ordering inconsistency.