Can someone point me to the section of documentation that covers 3D (x,y,z) representation of Earth's surface (topography)? I'm getting confused on what the spatial reference is. I'm familiar with ellipsoids, geoids, projections, etc. Trying to understand how z-0 is being characterized and handled. I assume this would be considered static data that might be tranformed from 3D to 2D for modeling.
3D Topography?
- Thread starter Joshua
- Start date
Thanks. Knowing that it is 2D alone helps. I assume tht elevation is somehow assigned to each grid point. How is this characterized and tracked? I did not think (or not think) WRF used a 3D topography, I simply don't know how elevation is treated in WRF. For example, is WRF using an ellipsoid (such as the one for WGS84), or can WRF use a geoid (such as using WGS84 and applying NAVD88)? If a user wished to include the height above ellipsoid (HAE) or orthometric height to improve the surface info for the grid, can this be done?
The variable "HGT", which is topography height, is included in wrfinput and wrfout files.
The gmted2010 global topographic data is used in WRF. More information can be found at
www.usgs.gov
The gmted2010 global topographic data is used in WRF. More information can be found at
GMTED2010 | U.S. Geological Survey
The USGS and the National Geospatial-Intelligence Agency (NGA) have collaborated on the development of a notably enhanced global elevation model called the Global Multi-resolution Terrain Elevation Data (GMTED2010), which has replaced GTOPO30 as the elevation dataset of choice for global and...
Again, thank you. Referencing that, I came across this within the documentation:
Accordingly, the height_ukmo.exe program may be used to compute a geopotential height field for these data sets. This program requires no command-line arguments, but reads the &metgrid namelist record to obtain the prefix of the intermediate files created by ungrib.exe; the intermediate files are expected to contain a SOILHGT field, from which the height_ukmo.exe program computes, with the aid of an auxiliary table, the 3-d geopotential height field. The computed height field is written to a new intermediate file with the prefix HGT, which should then be added to the fg_name namelist variable in the &metgrid namelist record before running metgrid.exe.
Is the GMTED2010 functioning as the geographic vertical datum that takes the WGS84 Ellispoid to a Geoid? Within the 2D spatial reference, is SOILHGT basically the orthometric height and the computed HGT the final, singular value used?
Accordingly, the height_ukmo.exe program may be used to compute a geopotential height field for these data sets. This program requires no command-line arguments, but reads the &metgrid namelist record to obtain the prefix of the intermediate files created by ungrib.exe; the intermediate files are expected to contain a SOILHGT field, from which the height_ukmo.exe program computes, with the aid of an auxiliary table, the 3-d geopotential height field. The computed height field is written to a new intermediate file with the prefix HGT, which should then be added to the fg_name namelist variable in the &metgrid namelist record before running metgrid.exe.
Is the GMTED2010 functioning as the geographic vertical datum that takes the WGS84 Ellispoid to a Geoid? Within the 2D spatial reference, is SOILHGT basically the orthometric height and the computed HGT the final, singular value used?
Okay, so, to (hopefully) correct myself any clarify in case anyone else comes across this...
I believe there is an x, y, and z component for each grid cell. The surface grid and the variable "HGT" together define the cell: extent in x and y on the sphere's surface, and relative topology height (centered within the cell). That gives you 'true' surface. I think. Basically a stepped, square terrain (think MineCraft) where each step in the x/y is parallel to the sphere surface (versus non-parallel/tilted rhombi).
Feel free to correct me, world.
I believe there is an x, y, and z component for each grid cell. The surface grid and the variable "HGT" together define the cell: extent in x and y on the sphere's surface, and relative topology height (centered within the cell). That gives you 'true' surface. I think. Basically a stepped, square terrain (think MineCraft) where each step in the x/y is parallel to the sphere surface (versus non-parallel/tilted rhombi).
Feel free to correct me, world.