where the first field is the value of the x-coordinate, the second field the y-coordinate and the last field the z-coordinate. xyz2rsurface will stop at the first line which does not fit this format. You may want to check (e.g. using the --verbose option) that the number of points processed matches what you expect. Note that the database does not enforce any other convention.

Example: building a global terrain topography database using the ETOPO2 dataset

The ETOPO2 dataset contains topographic information for the entire surface of the Earth (both above and below sea level) at a nominal resolution of two arc-minutes (~4 km).

We need to convert this binary file to a text file. We also want to use the database together with a cartographic projection defined using the Map module. By definition this means that our x-, y- and z-coordinates need to be the east-positive longitude, north-positive latitude and elevation in metres. We can easily get these coordinates in a text format suitable for input into xyz2rsurface using the following C code:

Just copy and paste this code into a file called e.g. etopo2xyz.c and compile using

% cc etopo2xyz.c -o etopo2xyz

The following command will then read the binary ETOPO2 file, convert it to the appropriate text format and generate the final terrain database

% etopo2xyz < ETOPO2v2c_i2_LSB.bin | xyz2rsurface etopo2

If everything went well you should end up (~ one hour and ~58 millions points later) with four large files

% ls etopo2*
etopo2 etopo2.Data etopo2.DataPD etopo2.DirPD

which together define the terrain database.

Note also that when using several databases simultaneously within GfsRefineTerrain, you need to choose consistent conventions for all the databases (for example a common geodetic system e.g. WGS84). The terrain databases do not know anything about projection systems and it is up to you to enforce your preferred conventions.

Optimising the database layout

The procedure above produces a functional database but it is not optimal because the points are inserted following horizontal/vertical coordinates lines. This leads to bounding boxes of the R*-tree which have aspect ratios far from one. A simple way of improving the database is to insert the points randomly rather than along coordinate lines. This can be done easily using the "-r" option.

You will notice that this takes longer but also that the database size is significantly reduced and that the aspect ratios of bounding boxes is much improved (always less than two). This leads to important performance improvements when using the database.

You may also note that temporary files are created by the sort unix command as part of this process.