Public | Automated Build

Last pushed: 8 months ago
Short Description
A C++ library and associated command line tools designed to create terrain tiles for use in the Cesium JavaScript library.
Full Description

Cesium Terrain Builder

This is a C++ library and associated command line tools designed to create
terrain tiles for use with the Cesium JavaScript library.

Cesium can create interactive 3D globes (à la Google Earth) in your web browser
whereby imagery is draped over a model of the underlying terrain. Cesium
provides a number of
different sources for
the terrain data, one of which is height map data for use with the
JavaScript class.

Cesium Terrain Builder can be used to create the tilesets that sit behind a
terrain server used by CesiumTerrainProvider. Note that these tools do not
provide a way of serving up those tilesets to the browser: instead
Cesium Terrain Server is
designed to serve terrain tilesets. In particular the Docker
image is designed to simplify the visualisation of terrain tilesets.

Command Line Tools

The following tools are built on top of the C++ libctb library:


This creates gzipped terrain tiles from a GDAL raster representing a
Digital Elevation Model
(DEM), saving the resulting tiles to a directory. It calculates the maximum
zoom level concomitant with the native raster resolution and creates terrain
tiles for all zoom levels between that maximum and zoom level 0 where the
tile extents overlap the raster extents, resampling and subsetting the data as
necessary. E.g.

ctb-tile --output-dir ./terrain-tiles dem.tif

The input raster should contain data representing elevations relative to sea
level. NODATA (null) values are not currently dealt with: these should be
filled using interpolation in a data preprocessing step.

Note that in the case of multiband rasters, only the first band is used as the
input DEM.

As well as creating terrain tiles, the tool can also be used for generating
tiles in GDAL supported formats using the --output-format option. This
provides similar functionality to the script. Tiles can be
created in either Web Mercator or Global Geodetic projections using the
--profile option. e.g.

ctb-tile --output-format JPEG --profile mercator \
  --output-dir ./jpeg-tiles RGB-image.tif

An interesting variation on this is to specify --output-format VRT in order to
generate GDAL Virtual Rasters: these can be useful for debugging and are easily
modified programatically.

Usage: ctb-tile [options] GDAL_DATASOURCE


  -V, --version                 output program version
  -h, --help                    output help information
  -o, --output-dir <dir>        specify the output directory for the tiles (defaults to working directory)
  -f, --output-format <format>  specify the output format for the tiles. This is either `Terrain` (the default) or any format listed by `gdalinfo --formats`
  -p, --profile <profile>       specify the TMS profile for the tiles. This is either `geodetic` (the default) or `mercator`
  -c, --thread-count <count>    specify the number of threads to use for tile generation. On multicore machines this defaults to the number of CPUs
  -t, --tile-size <size>        specify the size of the tiles in pixels. This defaults to 65 for terrain tiles and 256 for other GDAL formats
  -s, --start-zoom <zoom>       specify the zoom level to start at. This should be greater than the end zoom level
  -e, --end-zoom <zoom>         specify the zoom level to end at. This should be less than the start zoom level and >= 0
  -r, --resampling-method <algorithm> specify the raster resampling algorithm.  One of: nearest; bilinear; cubic; cubicspline; lanczos; average; mode; max; min; med; q1; q3. Defaults to average.
  -n, --creation-option <option> specify a GDAL creation option for the output dataset in the form NAME=VALUE. Can be specified multiple times. Not valid for Terrain tiles.
  -z, --error-threshold <threshold> specify the error threshold in pixel units for transformation approximation. Larger values should mean faster transforms. Defaults to 0.125
  -m, --warp-memory <bytes>     The memory limit in bytes used for warp operations. Higher settings should be faster. Defaults to a conservative GDAL internal setting.
  -R, --resume                  Do not overwrite existing files
  -q, --quiet                   only output errors
  -v, --verbose                 be more noisy


  • For performance reasons it is recommended that the input raster be in the same
    spatial reference system as the output tile grid in order to bypass the need
    to reproject the data. For terrain data this is
    World Geodetic System
    (WGS 84). If the source data is in another spatial reference system, however,
    the tool will attempt to reproject the data but with an associated performance

  • For large rasters a tile based format (as opposed to scanline based) will
    drastically speed up processing. A block size that is similar to the tile
    output size (i.e. 65x65 for terrain tiles) should be chosen.

  • Adding overviews to the source dataset will speed up tile generation. The
    overview will be chosen whose resolution most closely matches that of the zoom
    level being rendered. Overviews will only be downsampled, never upsampled.
    As such, it is recommended to use rolutions corresponding to the
    Global Geodetic Profile
    in the Tile Mapping Service specification. See the
    gdaladdo tool for creating overviews.

  • DEM datasets composed of multiple files can be composited into a single GDAL
    Virtual Raster (VRT) dataset for use
    as input to ctb-tile and ctb-extents. See the
    gdalbuildvrt tool.

  • Setting
    GDAL runtime configuration
    options will also affect Cesium Terrain Builder. Specifically the
    environment variable should be set to a relatively high value, in conjunction
    with the warp memory, if required (see next recommendation).

  • If warping the source dataset then set the warp memory to a relatively high
    value. The correct value is system dependent but try starting your benchmarks
    from a value where the combined value of GDAL_CACHEMAX and the warp memory
    represents about 2/3 of your available RAM.

  • ctb-tile will resample data from the source dataset when generating
    tilesets for the various zoom levels. This can lead to performance issues and
    datatype overflows at lower zoom levels (e.g. level 0) when the source dataset
    is very large. To overcome this the tool can be used on the original dataset
    to only create the tile set at the highest zoom level (e.g. level 18) using
    the --start-zoom and --end-zoom options. Once this tileset is generated
    it can be turned into a GDAL Virtual Raster dataset for creating the next zoom
    level down (e.g. level 17). Repeating this process until the lowest zoom
    level is created means that the resampling is much more efficient (e.g. level
    0 would be created from a VRT representation of level 1). Because terrain
    tiles are not a format supported by VRT datasets you will need to perform this
    process in order to create tiles in a GDAL DEM format as an intermediate step.
    VRT representations of these intermediate tilesets can then be used to create
    the final terrain tile output.


This provides various information on a terrain tile, mainly useful for
debugging purposes.

Usage: ctb-info [options] TERRAIN_FILE


  -V, --version                 output program version
  -h, --help                    output help information
  -e, --show-heights            show the height information as an ASCII raster
  -c, --no-child                hide information about child tiles
  -t, --no-type                 hide information about the tile type (i.e. water/land)


This exports a terrain tile to GeoTiff
format for use in GIS software. Terrain tiles do not contain information
defining their tile location, so this must be specified through the command

Note that the tool does not normalise the terrain data to sea level but
displays it exactly as it is found in the terrain data.

Usage: ctb-export -i TERRAIN_FILE -z ZOOM_LEVEL -x TILE_X -y TILE_Y -o OUTPUT_FILE


  -V, --version                 output program version
  -h, --help                    output help information
  -i, --input-filename <filename> the terrain tile file to convert
  -z, --zoom-level <int>        the zoom level represented by the tile
  -x, --tile-x <int>            the tile x coordinate
  -y, --tile-y <int>            the tile y coordinate
  -o, --output-filename <filename> the output file to create


Sometimes it is useful to see the extent of coverage of terrain tilesets that
would be produced from a raster. This tool does this by outputting each zoom
level as a GeoJSON file containing the tile extents for
that particular zoom level.

Usage: ctb-extents GDAL_DATASET


  -V, --version                 output program version
  -h, --help                    output help information
  -o, --output-dir <dir>        specify the output directory for the geojson files (defaults to working directory)
  -p, --profile <profile>       specify the TMS profile for the tiles. This is either `geodetic` (the default) or `mercator`
  -t, --tile-size <size>        specify the size of the tiles in pixels. This defaults to 65 for terrain tiles and 256 for other GDAL formats
  -s, --start-zoom <zoom>       specify the zoom level to start at. This should be greater than the end zoom level
  -e, --end-zoom <zoom>         specify the zoom level to end at. This should be less than the start zoom level and >= 0


libctb is a library implemented in standard C++11. It is capable of creating
terrain tiles according to the
heightmap-1.0 terrain format. It
does not provide a way of serving up or storing the resulting tiles: this is
application specific. Instead its aim is simply to take a
GDAL supported raster format representing a Digital
Terrain Model (DTM) and convert this to terrain tiles.

See the source code for the tools provided with the library
(e.g. ctb-tile) for examples on how the library is used to achieve


Doxygen based documentation is available for the C++
code: run the doxygen command in the doc/ directory and point your browser
at doc/html/index.html.


Although the software has been used to create a substantial number of terrain
tile sets currently in production use, it should be considered beta quality
software: it needs broader testing, a comprehensive test harness and the API is
liable to change.

The software has primarily been developed and deployed on a Linux OS, and this
is the only officially supported platform. However, it has been reported as
compiling and running on:

  • Windows using Visual Studio 2010 and 2013 (see
    this issue).

  • Mac OS X Mavericks using clang (see
    this issue).

Porting it to other systems should be relatively painless as the library
dependencies have been ported to numerous systems and the code itself is
standard C++11.


Runtime requirements

Ensure GDAL >= 2.0.0 is installed. At the time of
writing this is not a stable release so you may need to use a nightly build or
to build the source directly from version control. Specifically, you will need
a version of trunk that has added the min,max,med,q1 and q3 resampling
algorithms. In the subversion repository this is commit 28717 and on the GitHub
mirror this is 0a90a34.

Build requirements

In addition to ensuring the GDAL library is installed, you will need the GDAL
source development header files. You will also need
CMake to be available.


From Source

  1. Ensure your system meets the requirements above.

  2. Download and
    unpack the source.

  3. In the root package directory, assuming you are on a UNIX system, type
    mkdir build && cd build && cmake .. && make install.

  4. On a UNIX system you may need to run ldconfig to update the shared library

Alternatively in step 3 above you can create a debug build by running cmake -DCMAKE_BUILD_TYPE=Debug ... You can also install to a different location by
specifying the CMAKE_INSTALL_PREFIX directive e.g. cmake -DCMAKE_INSTALL_PREFIX=/tmp/terrain ...

Note that if you have GDAL installed in a custom location (e.g under
/home/user/install) it will likely not be found by running cmake ... In this
case you will need to provide the GDAL_LIBRARY_DIR, GDAL_LIBRARY and
GDAL_INCLUDE_DIR directives e.g.

cmake -DGDAL_LIBRARY_DIR=/home/user/install/lib \
      -DGDAL_LIBRARY=/home/user/install/lib/ \
      -DGDAL_INCLUDE_DIR=/home/user/install/include \

Using Docker

is a Docker image that bundles the CTB tools and
simplifies their deployment. Follow the link for usage information.

The only requirement to getting up and running with Cesium Terrain Builder is
having docker available on your system: all software dependencies, build and
installation issues are encapsulated in the image.

In addition, the
Docker image provides a way of visualising the tilesets created by

Limitations and TODO

  • Create a comprehensive test harness (possibly using
    Bandit, including code coverage and valgrind

  • Better coordination between threads in ctb-tile to enable graceful exits if
    there is a fatal error or other interrupt.

  • Add support for the new
    quantized-mesh-1.0 terrain format.

  • The ctb-tile command currently only outputs files to a directory and
    as such is subjected to filesystem limits (e.g. inode limits): it should be
    able to output tiles in a format that overcomes these limits and which is
    still portable and accessible. SQLite would appear
    to be a strong contender.

  • Provide hooks into the GDAL error handling mechanism to more gracefully
    intercept GDAL errors.

  • Expose tilers using a standard container api (map and/or vector).

  • Enable more options to be passed to the VRT warper by parameterising
    GDALWarpOptions::papszWarpOptions and GDALCreateGenImgProjTransformer2 in

  • Encapsulate the multithreading tile generation functionality currently
    implemented in ctb-tile within the library to make it more widely

  • One of the ctb-tile recommendations above illustrates a process for
    efficiently creating tilesets at lower zoom levels by resampling an already
    generated tileset at the next highest zoom level. This could be built
    directly into the ctb-tile tool. An implementation could create a
    read-only GDAL TiledDataset driver (or use a VRT, if it efficiently supports
    the large number of tile files) which accesses the already generated tileset;
    this dataset could then be used as an input to the tiler.

  • Add support for interpolating out NODATA values. This could be done using
    either GDALFillNodata() or GDALGridCreate().

  • Adding support for creating water masks to tiles could be useful: at the
    moment all tiles are flagged as being of type 'land' (see
    this issue).

Issues and Contributing

Please report bugs or issues using the
GitHub issue tracker.

Code and documentation contributions are very welcome, either as GitHub pull
requests or patches. If you cannot do this but would still like to improve the
software, particularly overcoming the limitations listed above, then please
consider funding further development.


The Apache License, Version 2.0.


Software development funded by the
Maritime Archaeology Trust and the
European Regional Development Fund through the
Interreg IVA 2 Seas Programme.

Software developed by GeoData through the
University of Southampton Open Source Geospatial Laboratory.

Thanks to everyone in the community who has contributed to the code base.


Homme Zwaagstra

Docker Pull Command
Source Repository