wiki:OsgTerrainData

Version 16 (modified by Torben Dannhauer, 13 years ago) (diff)

--

TracNav

Terrain Data (DEM / Textures)

to use osgVisual, you need a terrain model to visualize. This model can be generated on thy fly (e.g. via osgEarth) or preprocessed with ​VirtualPlanetBuilder.
This page gives an overview how to obtain digital elevation model (DEM) data and texture data to build such a database.

The following source data could be used:

  • Digital Elevation Data
  • Textures/Imagery/Orthophotos
    • Free global low resolution texture data : Bluemarble Next Generation (NASA)
    • Free local low/medium resolution texture data: Landsat (NASA)
    • Commercial global medium/high resolution texture data: Landsat (atlogis.com, ...)
    • Commercial high resolution national texture data: e.g. Germany (Geocontent), USA (USGS), ...

NASA-Data

SRTM data with 3 arcs are available for free at

Local high resolution DEM data with 1 arcs (mainly based on SRTM 1arcs)

Water Mask and Ocean Mask (500m/px) files:

Night Lights (1000m/px)

Tip: Because SRTM data is delivery in many small .zip or tar.gz files, download and unpack it automatically: 

wget -r ftp://xftp.jrc.it/pub/srtmV4/tiff/
for zipfile in *.zip;do unzip -o "$zipfile" -d unpacked; done

US texture data

Local High and global resolution Texture and DEM data

To use LANDSAT arial images, read ​https://zulu.ssc.nasa.gov/mesid/tutorial/LandsatTutorial-V1.html for introduction. LANDSAT datasets are deliverey with up to seven images, each representing a different sensor with different wavelength. Three of this files (sensors for RGB) must be combined for the raw "natural" image.

The image merging is possible with gdal_merge.py (available in FWTools): 

gdal_merge.py -o outfile.tif R_sensor.tif  G_sensor.tif B_sensor.tif

National high resolution data

National high resolution data is available from many companies. Germany: GeoContent

compress Data

To shift system load from HDD to CPU, compress all textures lossless with LZW. This will decrease rendering time a lot, because usually the HDD ist the bottleneck.

If you have texture data with void pixels, skip this step and cover the compression in the next script.

This is an example bash script to process the images: 

mkdir /home/user/your/path/to/imagery/compressed

cat compressFolder_LZW.sh 

#!/bin/bash
cd /home/user/your/path/to/imagery
for file in `dir -d *` ; do
echo "$file :"
/usr/bin/gdal_translate -of GTiff -co "COMPRESS=LZW" $file compressed/$file
done

Mark void Pixel as NODATA

If you have textures which are not completely filled with data, GDAL has to detect which part of the texture is void and which is regular texture data. Therefore you can save the NODATA placeholder into the file so the reader knows how to interpret this data. Usually nodata Pixels in textures are saved as black pixel (RBG=0,0,0). This works fine even without a valid NODATA entry, because VPB/GDAL checks for the black texture pixels, which are unlikely to be a valid texture part. The situation is different if you want to add overviews to reduce the compile time of your database: If the pixels are not marked as void pixel by setting the NODATA flag, the overview interpolation algorithm will include the black pixels into the calculation. This causes the valid pixels on the edge to the NODATA pixels to be interpolated with the black (the NODATA) pixels and they are darken. Because they are not completely black they won't be excluded by VPB/Gdal and your Hi-Res inlay to be surrounded with a thin black line.

If you zoom into the scene near enough to see a VPB-tile created from the original image and not from an overview the black border will disappear.

To avoid the described problem, you should ensure that all void data in your textures has a well defined value which you can set as NODATA value. This is an example script to set the NODATA value to black (0,0,0): 

cat compressNdefineNODATA.sh 

#!/bin/bash
cd /home/user/your/path/to/imagery
for file in `dir -d *` ; do
echo "$file :"
/usr/bin/gdal_translate -of GTiff -co "COMPRESS=LZW" -a_nodata 0 $file nodata/$file
done

create Overviews

To reduce system load to resize the terrain textures on the fly multiple times, you should consider to create overviews embedded into your imagery. This allows VPB to use the existing overview of the fitting dimensions instead of creating it every time from scratch. Additionally you can improve the image quality, because VPB uses as OpenGL default the nearest neighbour interpolation, which results in bad texture quality. You can choose between several interpolation algorithms like average, gauss or cubic interpolation.

Average interpolation has the advantage that is does not involve a 3x3 or 4x4 matrix, but only the adjacent pixels itself. So it does not lead to black edges on curved imagery edges with adjacent NODATA pixels. Gauss interpolation is only suitable on tiles without NOTDATA values, gut it smooths the image which leads to better results in images with sharp edges or high frequency content.

This is an example bash script to process the images: 

cat createAddons.sh 

#!/bin/bash
cd /home/user/your/path/to/imagery
for file in `dir -d *` ; do
echo "$file :"
/usr/bin/gdaladdo --config COMPRESS_OVERVIEW LZW -r average $file 2 4 8 16 32 64 128
done

Moon Data

To animate earth rising above moon horizon, it could be usefull to model the moon.

​http://lunar.arc.nasa.gov/dataviz/datamaps/index.html

Misc data

This website collected data relevant for earth rendering, which includes:

  • Reflectance Maps,
  • Cloud Layers,
  • Bump-maps

​http://planetpixelemporium.com/earth.html
​http://www.celestiamotherlode.net/catalog/earth.php