rpms
11-29-2002, 01:27 PM
Hi!
My name is Ricardo,
I am trying to use DEM files and I can't obtain the correct .bgl file...
Can you send me an e-mail to discuss about it, please?
ricardo_rpms@yahoo.com
I thank you and remain.
Ricardo 11.29.02
Hi Joel,
As noted in the Terrain SDK, these values are obtained by dividing the DEM x &
Y dimension by the number of rows or columns in the dem. It tells the
resampler the distance between each source elevation point in degrees.
Since you are using DEMs with a dimension of 1 degree X and 1 degree Y, you
would take 1 / 1201 = 8.3263946711074104912572855953372e-4 and plug this value
into the CellXDimension and CellYDimension lines. The built-in Win9x
calculator works well for computing these values.
One thing to be aware of that is not overtly stated in the SDK is that you must
completely cover an LOD Quadrant with data or it will only show the default
data in the part of the quadrant not covered by the source DEM. This can be a
problem since the source DEMs all end at whole degrees and the LOD quadrant
system only has boundaries on the whole degrees for LODs 0 & 1. Hence, when
covering wide-area terrain with multiple INFs, you will have low-res gaps
between adjacent BGLs unless you make their boundaries conform to the LOD
Quadrant system instead of the source DEM Quadrant system.
This is a bit advanced for now, but something good to grasp as you move more
deeply into the process.
Hope this helps
Justin
FSGenesis (http://www.fsgenesis.com)
Well I've gotten started but still am having some difficulties. My work so
far:
In the Microsoft SDK for Terrain, they offer this link for 100 meter data:
http://edcwww.cr.usgs.gov/glis/hyper/guide/1_dgr_demfig/index1m.html
I downloaded the raw DEM data for Raleigh-East (clicking the Hatteras block
then the Raleigh block will bring up this information). I also downloaded
read_dem which is also suggested by the SDK for turning the raw USGS data into
a DEM binary format that the rest of the SDK can use.
When I converted the file, I got this data:
Output array will be 1201 rows by 1201 columns
DEM Header information for rawdem/raleigh-e:
Elevation array is 1201 rows by 1201 columns
TYPE A RECORD DATA
RALEIGH - E NC NI17-03E
DEM level code: 3
Elevation pattern: regular
Planimetric reference system: Geographic
Reference system zone: 0
Ground coordinate units: arc-seconds
Elevation units: meters
Number of polygon sides: 4
Elevation accuracy: Unknown
Rows of profiles in DEM: 1
Columns of profiles in DEM: 1201
Spatial resolution, easting (x): 3.00 arcsec
Spatial resolution, northing (y): 3.00 arcsec
Spatial resolution, elevation (z): 1.00 meters
Minimum elevation: 15.00 meters
Maximum elevation: 164.00 meters
CCW rotation from reference: 0.000000 radians
Projection parameters:
0.0000000000e+00 0.0000000000e+00 0.0000000000e+00
3.2718907655e-83 0.0000000000e+00 0.0000000000e+00
0.0000000000e+00 0.0000000000e+00 1.0053854000e-86
8.6936485242e-30 5.4951245400e-80 7.5964541966e-65
0.0000000000e+00 0.0000000000e+00 0.0000000000e+00
Projection coordinates at grid corners:
Northing Easting
Northwest (UL) 129600.00 -284400.00
Northeast (UR) 129600.00 -280800.00
Southwest (LL) 126000.00 -284400.00
Southeast (LR) 126000.00 -280800.00
The created file is about 2 megs in size. I created my INF file (raleighe.inf)
and it looks like this:
[Destination]
; LOD = {Auto, 0..n}
; LOD = Auto tells the resampler to pick the closest LOD to the
;source
;cell size. Specifying a number will force an LOD. This can
;be used for undersampling or oversampling.
LOD = Auto
DestDir = "output"
DestBaseFileName = "raleighe.out"
UseSourceDimensions = 1
[Source]
Type = ElevS16LSB
SourceDir = "input"
SourceFile = "raleigh-e.dem"
Lat = -288000.00
Lon = 129600.00
NumOfCellsPerLine = 1201
NumOfLines = 1201
CellXdimensionDeg = 3
CellYdimensionDeg = 3
ScaleinMeters = 1
My main problem is I can't seem to figure out what my CellX and CellY Dimension
Degrees should be. I don't think 3 is right. Does anybody have any idea? I've
tried looking at it from every angle and tried different values but the
resulting file doesn't look right (only 512k in size). Any ideas?
Thanks
Joel
Some addition's to Justin's comments:
Your lat/long coordinates don't look right at all. I suspect, your data is in
some sort of projection that has to be converted to WGS84! Dunno what went
wrong there... I've never worked with USGS data, but straight with WGS84 data,
so never had that problem...
One thing which is wrong in the SDK is how to calculate CellXdimensionDeg /
CellYdimensionDeg. They say divide by NumOfCellsPerLine / NumOfLines (which
would be 1/1201 in your case). However, your DEM is 1201 x 1201 POINTS. That
means the number of GRIDCELLS is 1201 - 1 = 1200, ie there are 1200 grid cells
in between 1201 points, if you get what you mean. The correct number is 1/1200!
The LOD Quadrant thingy that Justin was talking about can be checked very
easily:
Add the statement 'MakeBitmap = 1' to the 'source' and the 'destination'
section. Then after you run resample.exe, you should have a red and green
bitmap in your folder. The green bitmap shows you the file that has been
produced!
Cheers, Christian
My name is Ricardo,
I am trying to use DEM files and I can't obtain the correct .bgl file...
Can you send me an e-mail to discuss about it, please?
ricardo_rpms@yahoo.com
I thank you and remain.
Ricardo 11.29.02
Hi Joel,
As noted in the Terrain SDK, these values are obtained by dividing the DEM x &
Y dimension by the number of rows or columns in the dem. It tells the
resampler the distance between each source elevation point in degrees.
Since you are using DEMs with a dimension of 1 degree X and 1 degree Y, you
would take 1 / 1201 = 8.3263946711074104912572855953372e-4 and plug this value
into the CellXDimension and CellYDimension lines. The built-in Win9x
calculator works well for computing these values.
One thing to be aware of that is not overtly stated in the SDK is that you must
completely cover an LOD Quadrant with data or it will only show the default
data in the part of the quadrant not covered by the source DEM. This can be a
problem since the source DEMs all end at whole degrees and the LOD quadrant
system only has boundaries on the whole degrees for LODs 0 & 1. Hence, when
covering wide-area terrain with multiple INFs, you will have low-res gaps
between adjacent BGLs unless you make their boundaries conform to the LOD
Quadrant system instead of the source DEM Quadrant system.
This is a bit advanced for now, but something good to grasp as you move more
deeply into the process.
Hope this helps
Justin
FSGenesis (http://www.fsgenesis.com)
Well I've gotten started but still am having some difficulties. My work so
far:
In the Microsoft SDK for Terrain, they offer this link for 100 meter data:
http://edcwww.cr.usgs.gov/glis/hyper/guide/1_dgr_demfig/index1m.html
I downloaded the raw DEM data for Raleigh-East (clicking the Hatteras block
then the Raleigh block will bring up this information). I also downloaded
read_dem which is also suggested by the SDK for turning the raw USGS data into
a DEM binary format that the rest of the SDK can use.
When I converted the file, I got this data:
Output array will be 1201 rows by 1201 columns
DEM Header information for rawdem/raleigh-e:
Elevation array is 1201 rows by 1201 columns
TYPE A RECORD DATA
RALEIGH - E NC NI17-03E
DEM level code: 3
Elevation pattern: regular
Planimetric reference system: Geographic
Reference system zone: 0
Ground coordinate units: arc-seconds
Elevation units: meters
Number of polygon sides: 4
Elevation accuracy: Unknown
Rows of profiles in DEM: 1
Columns of profiles in DEM: 1201
Spatial resolution, easting (x): 3.00 arcsec
Spatial resolution, northing (y): 3.00 arcsec
Spatial resolution, elevation (z): 1.00 meters
Minimum elevation: 15.00 meters
Maximum elevation: 164.00 meters
CCW rotation from reference: 0.000000 radians
Projection parameters:
0.0000000000e+00 0.0000000000e+00 0.0000000000e+00
3.2718907655e-83 0.0000000000e+00 0.0000000000e+00
0.0000000000e+00 0.0000000000e+00 1.0053854000e-86
8.6936485242e-30 5.4951245400e-80 7.5964541966e-65
0.0000000000e+00 0.0000000000e+00 0.0000000000e+00
Projection coordinates at grid corners:
Northing Easting
Northwest (UL) 129600.00 -284400.00
Northeast (UR) 129600.00 -280800.00
Southwest (LL) 126000.00 -284400.00
Southeast (LR) 126000.00 -280800.00
The created file is about 2 megs in size. I created my INF file (raleighe.inf)
and it looks like this:
[Destination]
; LOD = {Auto, 0..n}
; LOD = Auto tells the resampler to pick the closest LOD to the
;source
;cell size. Specifying a number will force an LOD. This can
;be used for undersampling or oversampling.
LOD = Auto
DestDir = "output"
DestBaseFileName = "raleighe.out"
UseSourceDimensions = 1
[Source]
Type = ElevS16LSB
SourceDir = "input"
SourceFile = "raleigh-e.dem"
Lat = -288000.00
Lon = 129600.00
NumOfCellsPerLine = 1201
NumOfLines = 1201
CellXdimensionDeg = 3
CellYdimensionDeg = 3
ScaleinMeters = 1
My main problem is I can't seem to figure out what my CellX and CellY Dimension
Degrees should be. I don't think 3 is right. Does anybody have any idea? I've
tried looking at it from every angle and tried different values but the
resulting file doesn't look right (only 512k in size). Any ideas?
Thanks
Joel
Some addition's to Justin's comments:
Your lat/long coordinates don't look right at all. I suspect, your data is in
some sort of projection that has to be converted to WGS84! Dunno what went
wrong there... I've never worked with USGS data, but straight with WGS84 data,
so never had that problem...
One thing which is wrong in the SDK is how to calculate CellXdimensionDeg /
CellYdimensionDeg. They say divide by NumOfCellsPerLine / NumOfLines (which
would be 1/1201 in your case). However, your DEM is 1201 x 1201 POINTS. That
means the number of GRIDCELLS is 1201 - 1 = 1200, ie there are 1200 grid cells
in between 1201 points, if you get what you mean. The correct number is 1/1200!
The LOD Quadrant thingy that Justin was talking about can be checked very
easily:
Add the statement 'MakeBitmap = 1' to the 'source' and the 'destination'
section. Then after you run resample.exe, you should have a red and green
bitmap in your folder. The green bitmap shows you the file that has been
produced!
Cheers, Christian