After learning more about terrain design, I realized that the terracing effect I see seems to be caused by
reprojecting and not resampling. The TIF files I load into QGIS from USGS 1/3 arc-second data look good until they are reprojected to WGS84 format. Perhaps this is why I haven't noticed much difference when adding "fractionbits" into the INF file.
Before projection:
View attachment 63670
After reprojection:
View attachment 63671
The metadata for this file:
Code:
<geodetic>
<horizdn>North American Datum of 1983</horizdn>
<ellips>Geodetic Reference System 80</ellips>
<semiaxis>6378137.000000</semiaxis>
<denflat>298.2572221</denflat>
</geodetic>
</horizsys>
<vertdef>
<altsys>
<altdatum>North American Vertical Datum of 1988</altdatum>
<altres>1.000000</altres>
<altunits>meters</altunits>
<altenc>Implicit coordinate</altenc>
</altsys>
</vertdef>
Is it possible to use reprojecting commands in my OSGeo4W interface instead of QGIS, like I use to create photoreal scenery? I'm hoping there is a way to fix this issue before I officially release the scenery to the public as freeware -- it's good enough for me, but not if I'm publishing it. I just wish I had looked into this further before I was almost done compiling 10m scenery for the entire conterminous United States.
Hi Chris:
Sorry, apparently I must have missed this thread when it began in the first week of July (I was probably traveling then).
AFAIK, it is more likely that the terracing effect you see is caused by
resampling and not re-projecting.
IIUC, the question is what output Bit Depth GeoTIFFs are you generating from QGIS when you process the above DEM source data ?
Another question is whether Metadata for
each CONUS USGS DEM source file is individually inspected / known before configuring multi-source SDK Resample
*.INF files ?
The goal of using Scaled Elevation Values via SDK Resample
*.INF FractionBits parameter values is to force Resample to derive sub-Meter units from Integer Meters.
[
EDITED]
https://www.prepar3d.com/SDKv4/sdk/world/terrain/terrain_overview.html#Destination Parameters
See:
Using Scaled Elevation Values
[
END_EDIT]
To do this one must submit the source GeoTIFF DEMs to SDK Resample in
32-Bit Floating Point format.
The file cited in your latter example immediately above is
already in that format:
ftp://rockyftp.cr.usgs.gov/vdelivery/Datasets/Staged/NED/13/TIFF/
n36w102/
ftp://rockyftp.cr.usgs.gov/vdelivery/Datasets/Staged/NED/13/TIFF/n36w102/
USGS_13_n36w102.tif
...shows this Metadata in Global Mapper:
FILENAME=[path]\USGS_13_n36w102.tif
DESCRIPTION=USGS_13_n36w102.tif
UPPER LEFT X=-102.0005092601
UPPER LEFT Y=36.0005092600
LOWER RIGHT X=-100.9994907405
LOWER RIGHT Y=34.9994907404
WEST LONGITUDE=102° 00' 01.8333" W
NORTH LATITUDE=36° 00' 01.8333" N
EAST LONGITUDE=100° 59' 58.1667" W
SOUTH LATITUDE=34° 59' 58.1667" N
UL CORNER LONGITUDE=102° 00' 01.8333" W
UL CORNER LATITUDE=36° 00' 01.8333" N
UR CORNER LONGITUDE=100° 59' 58.1667" W
UR CORNER LATITUDE=36° 00' 01.8333" N
LR CORNER LONGITUDE=100° 59' 58.1667" W
LR CORNER LATITUDE=34° 59' 58.1667" N
LL CORNER LONGITUDE=102° 00' 01.8333" W
LL CORNER LATITUDE=34° 59' 58.1667" N
PROJ_DESC=Geographic (Latitude/Longitude) /
NAD83 / arc degrees
PROJ_DATUM=
NAD83
PROJ_UNITS=arc degrees
EPSG_CODE=
EPSG:4269
COVERED AREA=10098 sq km
LOAD TIME=5.66 s
FILE_CREATION_TIME=10/15/2020 10:14:57 AM
FILE_MODIFIED_TIME=10/15/2020 10:17:54 AM
GDAL_NO_DATA_VALUE=-9999
NUM COLUMNS=10812
NUM ROWS=10812
NUM BANDS=1
PIXEL WIDTH=0.0000926 arc degrees
PIXEL HEIGHT=0.0000926 arc degrees
MIN ELEVATION=779.931 m
MAX ELEVATION=1153.354 m
ELEVATION UNITS=METERS
BIT DEPTH=32
SAMPLE TYPE=32-bit Floating Point
GEOG_CITATION=NAD83
PHOTOMETRIC=Greyscale (Min is Black)
BIT_DEPTH=32
SAMPLE_FORMAT=
Floating Point
TILE_WIDTH=256
TILE_HEIGHT=256
COMPRESSION=LZW
PIXEL_SCALE=( 0.00009259259269, 0.00009259259269, 1.0 )
TIEPOINTS=( 0.00, 0.00, 0.00 ) --> ( -102.0005555564, 36.0005555563, 0.0000000000 )
MODEL_TYPE=Geographic lat-long system
RASTER_TYPE=
Pixel is Area
OVERVIEW 1=Pixel Size: 5406 x 5406
OVERVIEW 2=Pixel Size: 2703 x 2703
OVERVIEW 3=Pixel Size: 1352 x 1352
OVERVIEW 4=Pixel Size: 676 x 676
OVERVIEW 5=Pixel Size: 338 x 338
GeoTIFF::GeographicTypeGeoKey=
4269
GeoTIFF::GeogToWGS84GeoKey={ 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 }
GeoTIFF::GeogAngularUnitsGeoKey=9102
...and is therefore is already in the required
32-bit Floating Point format.
The SDK Resample
*.INF FractionBits parameter value actually required to be used will vary with the maximum peak height in Meters AMSL of data points in a local DEM.
Certainly the range of total peak height in Meters AMSL of data points in Missouri was OK with a SDK Resample
*.INF FractionBits parameter value of "3".
But, higher Metric elevation points
may require larger SDK Resample
*.INF FractionBits parameter values with/without a SDK Resample
*.INF BaseValue parameter values.
[
EDITED]
FYI: After re-projection to
EPSG:4326 GIS format required by SDK Resample, and exporting a "
Elevation Grid Format" GeoTIFF file, Global Mapper shows this Metadata:
<
NOTE: I am not familiar with an equivalent work-flow in OSGeo4W / QGIS via GDAL command line switch parameters, but I suspect there is an 'obscure' way to output 32-Bit DEM GeoTIFFs.
>
Perhaps Frank Warmerdam
et al might have explained that in this recent GDAL documentation:
https://gdal.org/gdal.pdf
[
END_EDIT]
FILENAME=[path]\
USGS_13_n36w102_EPSG_4326.tif
DESCRIPTION=USGS_13_n36w102_EPSG_4326.tif
UPPER LEFT X=-102.0005092601
UPPER LEFT Y=36.0005092600
LOWER RIGHT X=-100.9994907405
LOWER RIGHT Y=34.9994907404
WEST LONGITUDE=102° 00' 01.8333" W
NORTH LATITUDE=36° 00' 01.8333" N
EAST LONGITUDE=100° 59' 58.1667" W
SOUTH LATITUDE=34° 59' 58.1667" N
UL CORNER LONGITUDE=102° 00' 01.8333" W
UL CORNER LATITUDE=36° 00' 01.8333" N
UR CORNER LONGITUDE=100° 59' 58.1667" W
UR CORNER LATITUDE=36° 00' 01.8333" N
LR CORNER LONGITUDE=100° 59' 58.1667" W
LR CORNER LATITUDE=34° 59' 58.1667" N
LL CORNER LONGITUDE=102° 00' 01.8333" W
LL CORNER LATITUDE=34° 59' 58.1667" N
PROJ_DESC=Geographic (Latitude/Longitude) /
WGS84 / arc degrees
PROJ_DATUM=WGS84
PROJ_UNITS=arc degrees
EPSG_CODE=EPSG:4326
COVERED AREA=10098 sq km
FILE_CREATION_TIME=10/15/2020 10:42:29 AM
FILE_MODIFIED_TIME=10/15/2020 10:42:56 AM
GDAL_NO_DATA_VALUE=-32767
NUM COLUMNS=10812
NUM ROWS=10812
NUM BANDS=1
PIXEL WIDTH=0.0000926 arc degrees
PIXEL HEIGHT=0.0000926 arc degrees
MIN ELEVATION=779.931 m
MAX ELEVATION=1153.354 m
ELEVATION UNITS=METERS
BIT DEPTH=32
SAMPLE TYPE=32-bit Floating Point
GT_CITATION=
GCS_WGS_1984
PHOTOMETRIC=Greyscale (Min is Black)
BIT_DEPTH=32
SAMPLE_FORMAT=Floating Point
ROWS_PER_STRIP=1
COMPRESSION=None
PIXEL_SCALE=( 0.00009259259269, 0.00009259259269, 1.0 )
TIEPOINTS=( 0.00, 0.00, 0.00 ) --> ( -102.0005092601, 36.0005092600, 0.0000000000 )
MODEL_TYPE=Geographic lat-long system
RASTER_TYPE=
Pixel is Point
GeoTIFF::GeographicTypeGeoKey=
4326
GeoTIFF::GeogSemiMajorAxisGeoKey=6378137
GeoTIFF::GeogSemiMinorAxisGeoKey=6356752.3
GeoTIFF::GeogEllipsoidGeoKey=7030
GeoTIFF::GeogAngularUnitsGeoKey=9102
[
EDITED]
BTW: As you already may know, when configuring a SDK Resample
*.INF, one must also specify one of these parameter values for the submitted source file Raster data:
*
Pixel is Area ; (SDK Resample
*.INF, parameter value:
PixelIsPoint=0
...
or:
* Pixel is Point ; (SDK Resample
*.INF, parameter value:
PixelIsPoint=1
https://www.prepar3d.com/SDKv4/sdk/world/terrain/terrain_overview.html#Source Parameters
[END_EDIT]
...or Geo-Referencing will be incorrect in processed output files (...like it apparently was in some default FS2Kx terrain BGLs
).
That may not impact terracing, but incorrect parameter values for maximum Metric Altitudes in a local DEM- or using
non- 32-Bit source data- can result in terraced terrain mesh.
GaryGB