GDAL returns incorrect unit type from ENVI header

[rbanfield]

GDAL is not grabbing the correct units from an ENVI header file. I am not sure if it is limited to this data format alone.

I am attaching 2 files, a sample header file, and the corresponding output from gdalinfo.

[rbanfield]

ENVI Header file

[rbanfield]

Output from GDALInfo

[warmerdam]

The ENVI coordinate system handling was largely rewritten since 1.4.x and should be much more robust. Would you be able to try a nightly source snapshot from subversion or perhaps the latest FWTools binaries and see if they work reasonably?

[warmerdam]

I see the units are Km in the file, but this isn't handled by the driver in trunk either. So no need to check yourself.

I'll aim to resolve this by 1.5.0 release. I have some docs from the ENVI folks which will hopefully have a list of units.

[warmerdam]

I have committed a major update from Bruce Payne (ITTVIS) which includes better linear units support. However, it still produces wrong results for the indicated file because SetUTM() sets the false easting and north in meters, but the linear units of km on the coordinate system cause these offsets to be treated as kilometers.

This can be worked around by using SetLinearUnitsAndUpdateParameters?() instead of SetLinearUnits?(), but it is not clear if this is appropriate. It will be appropriate if false easting and north values from the .hdr file are always in meters regardless of the linear units. Otherwise we may need to special case UTM.

Waiting for feedback frm Bruce.

[warmerdam]

Bruce Payne wrote:
> Frank,
>    After a little more research into this, any projection parameters for
> custom (and standard) projections are always in meters.   There are
> quite a few projection types that use false easting and false northing,
> but I don't see a lot of other linear parameters in our projection
> definitions.  Generally these are angular, which will always be in
> degrees.  So I think that the change you are proposing should be not
> only safe, but required.  
> 
> To sum up: the tie points and pixel sizes are stored in the specified
> linear units, but those units do not apply to parameters used to specify
> the projection.

Applied change as r12323 in trunk.

[warmerdam]

To the best of my knowledge r12323 fixed this issue. Let me know if anyone knows otherwise.