diff --git a/doc/osgdem.html b/doc/osgdem.html index 5f2c094a1..7c46b4998 100644 --- a/doc/osgdem.html +++ b/doc/osgdem.html @@ -37,22 +37,22 @@ terrain databases

Quick step by step guide:

-Follows are a the steps required to get osgTerrain/osgdem compiling and -an example of how to use it to process imagery and dem's to gernerate a +What follows are the steps required to get osgTerrain/osgdem compiling and +an example of how to use it to process imagery and DEM's to generate a paged databases.

1) Download, compile & install GDAL.
 
2) Get the latest OSG in CVS.

-3) For unix Make users, make a copy of Make/dependencies and change the +3) For UNIX 'make' users, make a copy of Make/dependencies and change the GDAL_INSTALL entry to:

set GDAL_INSTALL = true

-    Then tell the build to use you custom +    Then tell the build to use your custom dependencies by setting the environmental variable OSG_DEPENDENCIES to the absolute path to your file i.e.:

@@ -60,12 +60,12 @@ the absolute path to your file i.e.:
OSG_DEPENDENCIES=/home/billgates/my_osg_dependencies
 
-4) Rebuild the OSG & install (if you havn't already used
+4) Rebuild the OSG & install (if you haven't already).
 
-5) Oh make sure you have a couple Gb of spare disk space,  because -you going need it :-)
+5) Oh, make sure you have a couple of GB of spare disk space,  because +you're going to need it :-)
 
-6) Download some data, for this example I'm using the PegoutSound data +6) Download some data, for this example I'm using the Puget Sound data at:
 
                 Download Texture Map: 16384 × 16384 PNG: 268MB  

-7) To avoid aliasing artifcates when accessing data I use GDAL utilitiy programs to generate overviews (basically mip maps stored in the -.tif) +.tiff format) via:
 

@@ -101,7 +101,7 @@ gdaladdo -r average ps_texture_16k.tif
8) Now its time to run the osgdem example to generate your PagedLOD database, the more levels you generate the longer it will take -(exponentially so), osgdem is just a front end to osgTerrain::DataSet +(exponentially so). 'osgdem' is just a front end to osgTerrain::DataSet where all the hard work happens. Here's what to run :

osgdem @@ -117,7 +117,7 @@ where all the hard work happens. Here's what to run :
           -v 0.1 \
           --o pegout.ive
+-o puget.ive

Then go away for lunch, afternoon and tea, as generating this much data @@ -129,18 +129,18 @@ The command line options used above are:
 
The first part the --xx and --yy is specifying the size of the pixels in meters, since these png/tif don't have any geospatial data of their -own, if you have geospetialised files then you won't need this.
+own, if you have geospatialised files then you won't need this.

The second part -t <filename> is the option for specificing the -texture maps to use, you can use as many as you wish, +texture maps to use, you can use as many times as you wish, osgTerrain::DataSet will moziac them into a single database.  

-The third part -d is the option for specificying the digital elevation +The third part -d is the option for specifying the digital elevation maps to use, as with the textures you can use as many as you like.
 
-The -l option specificies the maximum number of levels to generate, if +The -l option specificies the maximum number of levels to generate. If you use a large number then the database generation will stop once the -max resolution of you source data is matched by the outputed database. +max resolution of your source data is matched by the resulting database. The database generation will decend further where there is high res source data, decend less where there is lower res data.
@@ -148,15 +148,15 @@ data, decend less where there is lower res data.
The -v option specifies the scaling factor which the height is multiplied by.

-And finally the -o <filename> is the output format to generat the +And finally the -o <filename> is the output format to generate the databases in. This will be the name of the topmost file in the one you should load. It can be a .ive or a .osg. The .ive is faster and has embedded files. 

-9) Time to play, simply load the database in your app (make sure it -support the osgDB::DatabasePager see osgsimplepager -example for detaiils). The standard osgviewer works just fine so +9) Time to play. Simply load the database in your app (make sure it +supports the osgDB::DatabasePager - see osgsimplepager +example for details). The standard osgviewer works just fine so, here goes:
 
   osgviewer output.ive
@@ -170,13 +170,13 @@ loading tiles that are still being written by osgdem, but it doesn't crash here under Linux, so you might be lucky too.

-11) If you imagery and dem's have geospatial coords associated with -them then the -xx, --yy and -v options will not be required making the +11) If your imagery and DEMs have geospatial coords associated with +them then the -xx, --yy and -v options will not be required, making it much simplier to specify - you just need to specifiy options such as -t imge.tif and -d terran.dt0 -without any need to set to coordinate system.
+without any need to set the coordinate system.

-12) osgdem can automatically handle moziacing of sets of files, these +12) osgdem can automatically handle mosaicing of sets of files. These can be specified via a sequence of -t <filename> and -d <filename> pairs on the commandline, or via