Whole number lon/lat causes Elevation Point service failure

openelevationservice
1

Thank you for these amazing free and open source services!

I have a strange but reproducible error. When using integer values for either lon or lat, or whole number float values (e.g. 38.0), then Elevation Point service returns status OK with but with no data, only a JSON description of a 500 error in the body.

Failed example: https://api.openrouteservice.org/elevation/point?api_key=XXX&geometry=13.349762,38

header: 200 OK
body: {“code”:500,“message”:“Server error”}

Incrementing the whole number value to a strict float value (e.g. 38.1) then produces the expected behavior

Successful example: https://api.openrouteservice.org/elevation/point?api_key=XXX&geometry=13.349762,38.11295

header: 200 OK
body: {“attribution”:“service by ORS | data by SRTM”,“geometry”:{“coordinates”:[13.349762,38.11295,38],“type”:“Point”},“timestamp”:1730885011,“version”:“0.2.1”}

Pure speculation - could be related to raster tile boundaries?

2

The same failure presentation occurs for these specific locations too:

  1. 151.319979, -33.597285
  2. 147.242259, -43.3218

Both are close to shorelines (north of Sydney and south of Hobart, Australia) but within SRTM coverage/tiles AFAICT

3

Hey,

we are currently investigating this - note, though, that SRTM data is not available for points in the oceans, which might be a reason for this failing.

Best regards