DEM data is being read as meter instead of feet

[lavsubbu]

The DEM data is read as in meters instead of feet. I checked with the ​http://nationalmap.gov/standards/pdf/2DEM0198.PDF, type A format indicates that the bytes from 529 to 534 should be

0=radians 1=feet 2=meters 3=arc-seconds

instead of setting the second parameter read, which is a measure for the elevation co-ordinates...my file has ground planimetric co-ords defined in ft and elevation measure in meters. Is that a weird scenario or will this qualify for a bug.

[Even Rouault]

Sorry, I don't understand the report. What is the issue, with ground unit or vertical unit ? Reviewing the code, it handles the 1=feet case for both, and report meter in other situations. So it is not obvious there's a bug. Sharing the file would also help understanding.

[lavsubbu]

Thanks for the comment. Actually I have a dem file that I am opening with gdal library (GDALRasterband->GetProjectionRef). In that the unit type is set as meters, but when I open the same file in Globalmapper the unit is set in ft. While I trying to find why there is a mismatch, I scanned through the dem file I have ( sorry I am unable to upload it because of the size), it has ground unit specified in ft and vertical uni specified in meters and usgsdemdataset.cpp sets the unittype based on the vertical unit. I dont know if this is a special case. But it would help is some one else also looks at it.

Thanks.

[Even Rouault]

Sample file would be needed for examination.

[lavsubbu]

Is there a way to email it?

[Even Rouault]

If it's just a few hundred of kilobytes you could put it as an attachment here, otherwise you can email it to me at even.rouault at spatialys.com

[lavsubbu]

I found a smaller one. Please check that one. I was not able to build my exe to test it but Globalmapper opened this one in ft. I will send the other one to your email but they both have similar headers.

[Even Rouault]

With GlobalMappaper 13.1, it reports min alt = 268.3 m and max alt = 381.9 m, exactly like GDAL does. And it reports ft as horizontal units, like GDAL does. And the horizontal extent reported in terms of latitutde/longitude is also very close. So both software agree. It doesn't look there's a problem.

[lavsubbu]

Are you using gdalinfo to look at the files?

This is what I got from it. C:\gdal64\bin\gdal\apps>gdalinfo "Smoke Tree local elevation files (10m).dem" ERROR 6: EPSG PCS/GCS code 26946 not found in EPSG support files. Is this a val id EPSG coordinate system? Driver: USGSDEM/USGS Optional ASCII DEM (and CDED) Files: Smoke Tree local elevation files (10m).dem Size is 243, 259 Coordinate System is `' Origin = (6461656.918993701200000,2288357.185572000200000) Pixel Size = (31.347144000000000,-31.347144000000000) Metadata:

AREA_OR_POINT=Point

Corner Coordinates: Upper Left ( 6461656.919, 2288357.186) Lower Left ( 6461656.919, 2280238.275) Upper Right ( 6469274.275, 2288357.186) Lower Right ( 6469274.275, 2280238.275) Center ( 6465465.597, 2284297.730) Band 1 Block=243x259 Type=Float32, ColorInterp=Undefined

NoData Value=-32767 Unit Type: m

I am looking at that unit type as m.

[Even Rouault]

It seems you have an issue with the EPSG csv files not being found in your installation. You should define the GDAL_DATA envirnonmenet variable to point to them.

Anyway, yes, the vertical unit reported is meter, and GlobalMapper also report it as meter. So what is wrong ?

Here's what I get with a correctly setup GDAL :

$ gdalinfo -mm "Smoke Tree local elevation files (10m).dem" 
Driver: USGSDEM/USGS Optional ASCII DEM (and CDED)
Files: Smoke Tree local elevation files (10m).dem
Size is 243, 259
Coordinate System is:
PROJCS["NAD83 / California zone 6",
    GEOGCS["NAD83",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6269"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4269"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",33.88333333333333],
    PARAMETER["standard_parallel_2",32.78333333333333],
    PARAMETER["latitude_of_origin",32.16666666666666],
    PARAMETER["central_meridian",-116.25],
    PARAMETER["false_easting",6561666.666666667],
    PARAMETER["false_northing",1640416.666666667],
    UNIT["Foot",0.3048006096012192],
    AXIS["X",EAST],
    AXIS["Y",NORTH]]
Origin = (6461656.918993701227009,2288357.185572000220418)
Pixel Size = (31.347144000000000,-31.347144000000000)
Metadata:
  AREA_OR_POINT=Point
Corner Coordinates:
Upper Left  ( 6461656.919, 2288357.186) (116d34'47.10"W, 33d56'49.02"N)
Lower Left  ( 6461656.919, 2280238.275) (116d34'46.79"W, 33d55'28.71"N)
Upper Right ( 6469274.275, 2288357.186) (116d33'16.68"W, 33d56'49.25"N)
Lower Right ( 6469274.275, 2280238.275) (116d33'16.40"W, 33d55'28.94"N)
Center      ( 6465465.597, 2284297.730) (116d34' 1.74"W, 33d56' 8.98"N)
Band 1 Block=243x259 Type=Float32, ColorInterp=Undefined
    Computed Min/Max=268.300,381.900
  NoData Value=-32767
  Unit Type: m

[Even Rouault]

Things were OK with State Plane SRS, but not with UTM SRS.

trunk r28351, branches/1.11 r28352 "USGSDEM: take into account horizontal unit = ft in the UTM case (#5819)"