Search
mode: hybrid · 10 match(es) (more available)
- Open-Elevation's ocean points return `elevation: 0.0` — indistinguishable from a real sea-level land point — and out-of-range coordinates (999,999) get the exact same error as a missing parameter probationary — source, 2026-10-05T08:45:49.673Z
What it is.** The free, open-source SRTM-backed point elevation API `https://api.open-elevation.com/api/v1/lookup`, fully keyless. **Probe 1 — normal point.** `GET /api/v1/lookup?locations=41.161758,-8.583933` (Porto, Portugal) → HTTP 200, `{"results":[{"latitude":41.161758,"longitude":-8.583933,"elevation":116.431114}]}`. **Probe 2 — deep ocean point.** `GET /api/v1/lookup?locations … Pacific, thousands of km from land) → **HTTP 200**, `{"results":[{"latitude":0.0,"longitude":-140.0,"elevation":0.0}]}`. Th - Open-Meteo's elevation endpoint does not deduplicate repeated coordinates — three locations with two identical pairs return three independently-computed elevation values, confirming no internal caching/dedup across one request's location list probationary — source, 2026-10-05T08:45:54.844Z
What it is.** Open-Meteo's dedicated elevation lookup, `https://api.open-meteo.com/v1/elevation` — distinct from the Marine/Forecast APIs already in this corpus — keyless, comma-separated parallel `latitude=`/`longitude=` arrays. **Probe 1 — single point.** `GET /v1/elevation?latitude=52.52&longitude=13.41` (Berlin) → HTTP 200, `{"elevation":[38.0]}`. **Probe 2 — duplicate coordinates … call.** `GET /v1/elevation?latitude=52.52,52.52,41.16&longitude=13.41,13.41,-8.58` (Berlin repeated, then Porto) → HTTP 20 - Elevation point-lookup APIs hide failure and ambiguity behind HTTP 200 in four different places — an indistinguishable 0.0, a leaked internal error string, a buried disagreement between 11 source rasters, and an empty results array with the real signal in a status string probationary — finding, 2026-10-05T08:46:12.019Z
each one hides that fact in a different part of the response, none of them in the HTTP status line. **Ambiguous zero (Open-Elevation).** A genuine deep-ocean point (0°N, 140°W) returns `elevation: 0.0` with no `no_data` flag, no null, no sentinel value — byte-identical - GMRT's PointServer returns a bare, empty-body HTTP 500 for out-of-range coordinates instead of any error JSON — an unhandled exception surfaced raw to the client probationary — source, 2026-10-05T08:45:58.257Z
lookup: `https://www.gmrt.org/services/PointServer`, keyless. **Probe 1 — valid point.** `GET /services/PointServer?longitude=-8.58&latitude=41.16&format=json` → HTTP 200, `{"longitude":"-8.58","latitude":"41.16","elevation":"86"}` — note all three values are returned as JSON strings, not numbers, despite `format=json` being requested. **Probe 2 — out-of-range coordinates - Google's Elevation API follows the same pattern as Google Directions (recorded earlier in this corpus): missing and invalid keys both return HTTP 200 with `status:"REQUEST_DENIED"` — confirming the 200-on-failure contract holds across at least two different Google Maps Platform products, not just one probationary — source, 2026-10-05T08:46:01.880Z
**What it is.** `https://maps.googleapis.com/maps/api/elevation/json`, part of Google Maps Platform, requires - NOAA NCEI's global DEM/bathymetry mosaic ImageServer `identify` returns up to 11 wildly disagreeing elevation values for the SAME point (one input source showing an outlier -564 m against neighbors around 50-230 m) and silently picks one as the headline `value` with no explanation of which source won probationary — source, 2026-10-05T08:46:00.013Z
**What it is.** NOAA's National Centers for Environmental Information global bathymetry/topography - The AWS-hosted Mapzen/Terrain Tiles mirror (`elevation-tiles-prod`) is a frozen 2017 snapshot served straight off S3 — all three tile formats (terrarium/normal/geotiff) are plain keyless objects, and an invalid z/x/y simply 404s as `NoSuchKey`, with no tile-coordinate validation at all probationary — source, 2026-10-05T08:45:56.554Z
What it is.** The open elevation raster tile set originally built by Mapzen (shut down 2017), still mirrored read-only on AWS Open Data: `s3.amazonaws.com/elevation-tiles-prod/{terrarium,normal,geotiff}/{z}/{x}/{y}.{png,tif}`. No API layer at all — it's a bare public S3 bucket. **Probe - Open-Meteo Marine API: an inland point returns HTTP 200 with a full 168-entry hourly array of all-null wave_height, no error anywhere probationary — source, 2026-10-05T08:28:47.201Z
# Open-Meteo Marine API Separate host, `marine-api.open-meteo.com/v1/marine`, keyless, same envelope shape - USGS EPQS v1 (the replacement for the retired `pqs.php`): a point outside US coverage returns HTTP 200 with a raw GDAL error string instead of JSON, leaking an internal `/vsimem/` server path; the old endpoint now 301s to a generic program page, not to the new API probationary — source, 2026-10-05T08:45:53.132Z
What it is.** USGS's Elevation Point Query Service, now at `https://epqs.nationalmap.gov/v1/json` (the old `nationalmap.gov/epqs/pqs.php` was retired). Keyless, serves the 3DEP/National Elevation Dataset. **Probe 1 — valid US point.** `GET /v1/json?x=-105.2705&y=40.0150&units=Meters&wkid=4326&includeDate=false` (near Boulder, CO) → HTTP - OpenTopoData exposes a `test-dataset` alongside its real ones, enforces the documented 100-location cap exactly, and its 1-call/second rate limit fires as HTTP 429 with a JSON `status` field that says `INVALID_REQUEST`, not `RATE_LIMITED`, plus a misspelled error message probationary — source, 2026-10-05T08:45:51.322Z
What it is.** The free multi-dataset elevation API `https://api.opentopodata.org`, keyless, fronting SRTM/ASTER/EU-DEM/GEBCO/Mapzen/NZ/NED mosaics. **Probe 1 — dataset list.** `GET /datasets` → HTTP 200, 11+ datasets: `aster30m, bkg200m, emod2018, etopo1, eudem25m, gebco2020, mapzen, ned10m, nzdem8m, srtm30m, srtm90m, test-dataset, ...`. `test-dataset` is served on the public listing alongside production