Cesium Terrain Builder
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
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++
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
ctb-tile --output-dir ./terrain-tiles dem.tif
The input raster should contain data representing elevations relative to sea
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
gdal2tiles.py 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
Usage: ctb-tile [options] GDAL_DATASOURCE Options: -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 penalty.
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
gdaladdotool for creating overviews.
Setting GDAL runtime configuration options will also affect Cesium Terrain Builder. Specifically the
GDAL_CACHEMAXenvironment 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_CACHEMAXand the warp memory represents about 2/3 of your available RAM.
ctb-tilewill 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
--end-zoomoptions. 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 Options: -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 options.
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 Options: -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 Options: -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
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
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.
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.
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.
Ensure your system meets the requirements above.
Download and unpack the source.
In the root package directory, assuming you are on a UNIX system, type
mkdir build && cd build && cmake .. && make install.
On a UNIX system you may need to run
ldconfigto update the shared library cache.
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
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_INCLUDE_DIR directives e.g.
cmake -DGDAL_LIBRARY_DIR=/home/user/install/lib \ -DGDAL_LIBRARY=/home/user/install/lib/libgdal.so \ -DGDAL_INCLUDE_DIR=/home/user/install/include \ ..
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 analysis.
Better coordination between threads in
ctb-tileto enable graceful exits if there is a fatal error or other interrupt.
Add support for the new quantized-mesh-1.0 terrain format.
ctb-tilecommand 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
Encapsulate the multithreading tile generation functionality currently implemented in
ctb-tilewithin the library to make it more widely available.
One of the
ctb-tilerecommendations 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-tiletool. An implementation could create a read-only GDAL
TiledDatasetdriver (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
NODATAvalues. This could be done using either
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.
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 email@example.com