Elevation API ATLAS Elevation 4 Outputdataabstraction

Andi Lamprecht ·2026-05-11· 3 min read· Accepted

ADR-0055 · Author: Sybil Melton · Date: 2025-02-07 · Products: platform
Originally ADR-0061 ELEVATION_API_ATLAS_ELEVATION_4_OutputDataAbstraction (v3) · Source on Confluence ↗

Output Data Structure

Context

Elevation data covers specific geographical area and is distributed through multiple GeoTiff files.
This ADR describes the default data structure used as an output for the tile serving endpoints.

Decision

The Tile

Elevation data is split into the tiles, which can be requested with tile index.

A tile is a geospatial data abstraction with following characteristics:

Tile encapsulates raw data for the area defined by tile boundaries
Data within a tile mapped to a grid of equally sized cells for the projection the tile was created.
Each data cell within the tile is called a pixel
Each pixel represents an elevation reading for the corresponding pixel area
A tile is element of a grid, created according to an algorithm specific to tile projection.
A tile cutting algorithm is defined by OGC Tile Matrix Set (TMS) [1]
A tile has a fixed size which is constant among the TMS. (eg. 256x256 )
To contain the array of pixels the tile must have rectangular shape relative to the projection it was created.

Due to a fixed-sized tile assumption this data structure sets a limit on the output size, no matter how dense is the raw data that the tile covers. The consumer choose to increase the zoom level to generate the tile with higher data resolution.

The location of a tile on the map is defined by the tile index (XYZ). Through that the boundary box for the tile can be computed - top, left bottom and right coordinate values acc. to the projection in which tile was made. The Tile’s fixed size allows a reader to get the tile step by computing bounding box delta (top-bottom or left-right) and divide it by tile resolution. The step can be used to get the projected coordinates for any pixel within the tile.

An example tile is presented below:

Invalid Image Path

Tile Pyramid

Invalid Image Path

Tile indexing

A tiles are indexed with XYZ schema, where X and Y defines a position of a tile within the grid related to selected zoom level (Z).

Invalid Image Path

A web maps commonly use the tiles in XYZ index system, cut in WebMercator projection [2][6]

Tile Cutting

Elevation API supports the tiles generated according to two TMS

WebMercatorQuad [3]

This TMS describes a tile cutting algorithm for Tiles generated in EPSG:3857 spatial reference system (Web Mercador projection).

It splits the the earth into 4 tiles, and then for every subsequent zoom level each tile is cut into another 4 tiles.

Invalid Image Path

WGS1984Quad [4]

This TMS describes a tile cutting algorithm for Tiles generated in EPSG:4326 spatial reference system (latitude/longitude based World Geodetic System, used in GPS)

It splits the earth into 2 tiles, and then for every for every subsequent zoom level each tile is cut into another 4 tiles.

Invalid Image Path

Alternatives considered

Serving geotiffs instead of tiles

This would require from the consumer of the output to implement geotiff parsing and reprojecting logics. Moreover the geotiffs can be too big to be served as an output.

Serving raw data for custom area

This could be considered, however the high resolution scans data density can rapidly increase the output size. Tiles guarantees a output size limit for single request , and leaves the level of details choice to the consumer.

Use different indexing strategy (geohash, quadkey)

It is possible to index the tiles differently however the XYZ schema is the schema expected by most 3rd party libraries, that why elevation API aligned to it.

Elevation API ATLAS Elevation 4 Outputdataabstraction

Output Data Structure

Context

Decision

The Tile

Tile Pyramid

Tile indexing

Tile Cutting

Alternatives considered

Links