USGS NED seamless data (last updated: 1 Sept, 2003)
"A processing system was designed to assemble a seamless dataset from multiple data sources, resolutions, and production methods. ...
The data model is logically seamless but uses an internal tile structure initially selected as a 1- by 1-degree area."
USGS NED Product Methodology
"To be a truly seamless dataset, the NED is assembled using a raster data model cast in a geographic coordinate system (horizontal
locations are referenced in decimal degrees of latitude and longitude). A consistent grid spacing of 1-arc-second (approximately 30 meters)
is used, except for Alaska, where lower resolution source data warrant the use of a 2-arc-second spacing. Elevation units are standardized
to decimal meters. ..."
"In its entirety, the NED comprises almost 1,400 1- by 1-degree tiles, with over 900 tiles covering the continental
United States, nearly 400 covering Alaska and Hawaii, and the remainder covering the island territories. ... The final steps in the production
process include paneling the DEMs to fill the 1- by 1-degree tile, ... Finally, a shaded-relief image of the tile is generated for inspection
by an analyst to verify successful processing,... "
The Imaging & Geospatial Information Society
"ulxmap - the x-axis map coordinate of the center of the upper-left pixel. ...
ulymap - the y-axis map coordinate of the center of the upper-left pixel."
ESRI ArcView GIS 3.2 Help->Specification of BIL/BIP/BSQ image format->the header file
The data is prepared in 1-degree tiles, although this fact is transparent to the user. Missing from these descriptions is the fact that
the elevation posts are offset from the 1-degree boundaries by 1/2 the data spacing. For example, if you request a block of 1-arcsec data with
the NW corner at N45 W45, the top/left elevation post will be located at N45-1/2 arcsec W45-1/2 arcsec. I assume this is related to the
growing use of graphics and mapping software to view the data.
We now have two interpretations of the elevation data values: PixelAsPoint and PixelAsArea. The red dots in the image above represent the
PixelAsPoint locations of the data. This is consistent with the USGS DEM specification, and is the location expected by the SDK. The squares in which they
are centered reflect the associated PixelAsArea interpretation. This grid is aligned with the 1-degree tiles mentioned above.
The red rectangle represents the boundaries of an area requested by coordinates. The SDDS server will fill the request by providing a "map" of the area
which includes the coordinates you requested, using the PixelAsArea interpretation. This means the gray shaded area is the actual dataset returned to you.
This is the only role your coordinates play in the process. The Northwest elevation post in the dataset is pulled out and magnified with key
Metadata provided with the *.bil/*.tif file provides a variety of information regarding the location of the data. The correct
coordinates of the Northwest red PixelAsPoint elevation value (2) are provided in the *.tfw or *.blw world files. Internal GeoTiff file headers report the
coordinates of the Northwest corner of the image (1), which is the NW corner of the PixelAsArea space. This will be offset to the North and West from the
PixelAsPoint coordinates by 1/2 the resolution of the data.
This is of limited practical significance if you are processing this data directly with the SDK, using the *.blw file info
in your *.inf file. (Although it has subtle implications if you are requesting data based on LOD quadrant requirements.)
If you are using some form if GIS/mapping software to preprocess the data, you need to understand how the software deals with these two sets of
coordinates. Not all mapping software handles this dual system consistently, or even correctly, adding to the complexity of the situation.
Theory: "Calculate->Map window corners" and "Analyze->Header"->SW corner geographical coordinates are not those of the elevation posts,
but of the cell containing the post value. They should not be used directly in the inf file.
Practice: Microdem seems to read the data and correctly calculate the SW corner of the map. It then computes the offsets
to the Northern and Eastern boundaries by multiplying the spacing of the data by nrows-1/ncols-1 respectively.
This approach gives neither the coordinate of the Northwest boundary of the map(1) nor that of the Northwest PointAsPixel (2). Instead we are
provided the location of the Southwest corner of the Northwest PointAsArea elevation(3). Probably of little interest to anyone. This algorithm is
also used to calculate all other locations reported in the application: calculated map window corners, status line coordinates, Edit cell locations,
... The magnitude of the error increases with distance from the SW corner; the location of the NW corner is offset by about 0.7 times the resolution of the data!
(The coordinates do seem to be correct if the NW corner of the area requested falls exactly on the corner of a PixelAsArea cell.)
1) Use Microdem to merge data and perform small repairs only - no subsetting(?). Ignore the coordinates reported by Microdem, especially while
they are being calculated incorrectly; use the source *.blw or *.tfw coordinates in the inf file. Because of the errors in the Microdem coordinates,
they will not match those in the mesh, which makes error checking more complicated.
This approach is sufficient for most people. I use the following alternatives so I can read the Microdem DEM header to calculate the NW corner
for use in creating the *.inf file automatically. If you use Microdem to create a subset of the data that involves the NW corner,
you will also have to use calculations based on the reported SW corner.
2) Microdem reports the correct coordinates for the SW corner of the map. The correct North/West coordinates can be
calculated from this location using the calculated "Map window corners" coordinates or the Microdem DEM file header information by including the appropriate offsets.
I have used this approach to quickly reposition my existing mesh data. Mesh and Microdem coordinates are no longer in sync here either.
3) Convert BIL data to the Microdem format before processing with Microdem. This approach means that Microdem never sees the alternative sets of
coordinates provided by the Metadata and works as expected. Map coordinates in Microdem will not be correct but the calculated "Map window corners"
and header SW corner values can be used without including the offset. This is the approach I am now using for all new SDDS data.
(BIL files are much smaller than Geotiff so the downloading goes much faster.)
Why bother with Microdem?
Given the shortcomings noted, should you use Microdem at all? My answer is a qualified "Yes", for several reasons:
* It enables you to visually inspect the data. The final step used by the USGS in the preparation of the data is a visual confirmation of the quality.
It should be a part of our own data preparation process as well.
* It converts the data to the WGS84 datum preferred by the SDK.
* You can incorporate data from many source formats, resolutions, datums, ... , merging and converting them to one standard format for the SDK.
* You can edit small errors, replace missing data using interpolation, adjust for elevations errors, ...
* You can create small missing value regions with the Edit function, deliberately creating holes in your bgl file (useful for a variety of reasons).
* It is free, and reasonably well supported.
Warning: Microdem's opening screen has some disclaimers concerning the use of NED (SDDS) data. While it does seem safe to merge the data, other
manipulations are not supported. Of particular concern is the ability to create subsets of the data, which results in extremely unreliable coordinates.
The author notes that subsetting is safe when using the latest releases (8 Aug, 2003 and later), but I have not confirmed this.
Manifold is a popular and powerful, low-cost GIS program, reportedly used in the development of another popular brand of terrain mesh. Limited
testing with the software defaults and Imported BIL data suggests that it does display the correct coordinates in the maps and status bar.
However, when the data is Exported in BIL format, which can be used directly with the SDK, the Northwest coordinates
reported in the new *.blw file are shifted northwest, reflecting those of the map area, not the coordinates provided in the source *.blw file.
If you later reload this exported version for further manipulation and Export it again, the data is again shifted to the northwest, adding to the
It may be possible to alter the default behavior (if one is aware of the problem). If not, the source data *.blw header information
should be used. If a subset of the data with a new northwest corner is created, more complex calculations will be required.
This is an unfortunate situation, as the SDDS data is a valuable resource for many of us. Microdem's developer is aware of the issue
regarding coordinates but has not yet acknowledged it as one that needs to be addressed in the future.