Using NED data for terrain mesh gives wrong elevation values

[Guest Kurt Maxwell Weber]

I downloaded 1/3 arcsecond NED data from the USGS SDDS to make terrain mesh for FS2004. The data was in BIL format, which is simply a flat 8-bit little-endian raster with no header information included with the data itself (it's in a separate file included in the archive). Since resample.exe requires 16-bit data, I wrote a simple program in MSVC++ that reads in the data from the BIL file one byte at a time into an __int8 (for those unfamiliar with Visual C++, that type is a Microsoft extension to the ANSI spec that is a signed integer type guaranteed to be eight bits wide), casts it to an __int16, and then writes it to an output file.I run resample.exe on the file my converter outputs and it doesn't complain. I open the resulting BGL in TMFviewer, and as I move the mouse over it I notice that, while most of the area is at around 120 meters elevation (which is consistent with the general actual elevation of the area), a large part of it--displayed in green in TMFviewer--is actually at an elevation of -128 meters.This is, quite simply, odd.I'm not sure where the problem is. resample.exe, according to the SDK docs, requires input data to be in 16-bit signed integers, either big- or little-endian. As the input data is little-endian, I am using "ElevS16LSB" in the .inf file.Since -128 is the lowest value that can be represented by a signed 8-bit integer, and 120 is near the highest value (127) that can be represented, I'm wondering if there may be some weirdness with my conversion from 8-bit signed integers to 16-bit signed integers.Any suggestions?

[beatle 0]

Are you sure the 8-bit input BIL data is in meters and that zero is really the zero point? Not much range in a signed 8-bit number to do elevation coding (except when the data can't be more than +/- 128 meters, which isn't a very big elevation delta), are you in fact sure the data is signed to start with? Couple of things they could be doing with the data, it could be offset by a negative value (say -64 = zero, which would give a range of -64 to +191) and it could be multiple meters per single value change (ie 5 meters per so you would need to multiply the input data by 5 when converting to 16-bit signed). Just some thoughts, never worked with that particular dataset myself.

[Holger 0]

Hi there,the NED data are 16-bit signed and the BIL format is in fact just the BSQ that resample.exe requires. See http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchand also http://seamless.usgs.gov/website/seamless/products/3arc.aspCheers, Holger

[Guest Kurt Maxwell Weber]

>Hi there,>>the NED data are 16-bitAre you sure?The .hdr file in the archive says the data is 8-bit (NBITS 8). Furthermore, the file size of the .BIL file is 29,170,801. According to the .hdr file, the data is in 5401 rows and 5401 columns--so, assuming one byte (8 bits) per cell, that results in a file size of 29,170,801 bytes. Were it 16-bit data, the file size would be twice that.

[Holger 0]

Hi there,that's odd. Here's what the hdr file of one of my NED BIL archives contains:BYTEORDER ILAYOUT BILNROWS 7200NCOLS 5625NBANDS 1NBITS 16BANDROWBYTES 11250TOTALROWBYTES 11250BANDGAPBYTES 0Cheers, Holger

[scott967 62]

I normally get Arc Grid ADF format, but I think Seamless will send you 8 bit BIL NED data if the elevations are <= 256m. You need something like Global Mapper to convert into 16 bit. I don't see any way to force Seamless to give you 16 bit data. The data I got as a test (SE Louisiana) is provided in unsigned 8 bit integer. I don't know what happens with <0 elevation.scott s..

[Guest Kurt Maxwell Weber]

>I normally get Arc Grid ADF format, but I think Seamless will>send you 8 bit BIL NED data if the elevations are <= 256m. >You need something like Global Mapper to convert into 16 bit. Well, I wrote my own 8-bit to 16-bit converter...it's rather trivial to do.But you say the BIL data is UNSIGNED? That would make a lot of difference, but all the documentation I've found says it is signed.

[scott967 62]

Well, I grabbed a couple chunks of data and if 8 bit it is unsigned, and if 16 bit it is signed. I even found a problem with Global Mapper, which assumed it was signed and created below sea level altitudes.I grabbed some data around 34.88 -87.76 (NW ala) at random with elevation between 143 and 223 m and verified that it was just unsigned int data. Global Mapper thought it was from -113 to -33 m :(scott s..

[Guest Kurt Maxwell Weber]

Well, I rewrote my converter to assume the input data was unsigned and now no problems at all--in TMFviewer, the elevations are all around what I know to be the general elevation for that area, and no below-sea-level elevations, so it look sgood.Thanks!