Opened 16 years ago

Closed 16 years ago

#2183 closed defect (fixed)

error reading IDL/ENVI created GeoTIFFs

Reported by: chash Owned by: warmerdam
Priority: normal Milestone: 1.5.1
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: geotiff ENVI mars jp2kak
Cc:

Description

I get the following message from gdal_translate (FWTools-2.0.4) when reading GeoTIFFs created with IDL/ENVI.

TIFFFetchNormalTag: Warning, ASCII value for tag "GeoASCIIParams" does not end in null byte.

The input file (GTiff) is a Mars global map. The resulting output (JP2KAK) when inspected with gdalinfo defaults to WGS84. This may or may not be related to the above error message.

gdalinfo and listgeo show the correct radius for the input GTiff:

SPHEROID["unnamed",3396000,0]],

On the output JP2, gdalinfo shows:

SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],

Sample original TIFF attached.

Command line for gdal_translate: gdal_translate -of JP2KAK -co "QUALITY=50" ~/T1865_MRRIF_70N185_0256_1.tif ~/T1865_MRRIF_70N185_0256_1.jp2

Attachments (1)

T1865_MRRIF_70N185_0256_1.tif (730.9 KB ) - added by chash 16 years ago.

Download all attachments as: .zip

Change History (4)

by chash, 16 years ago

comment:1 by warmerdam, 16 years ago

Component: defaultGDAL_Raster
Keywords: jp2kak added
Status: newassigned

I have confirmed that the spheroid is lost in a translation to JPEG2000 using the JP2KAK driver. This is unrelated to the warning about a missing null at the end of the ascii parameters. I'll dig into the spheroid issue...

comment:2 by warmerdam, 16 years ago

A listgeo of the input file shows:

   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GeographicTypeGeoKey (Short,1): Undefined
      GeogCitationGeoKey (Ascii,11): "CRISM MRDR"
      GeogLinearUnitsGeoKey (Short,1): Linear_Meter
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      GeogSemiMajorAxisGeoKey (Double,1): 3396000          
      GeogSemiMinorAxisGeoKey (Double,1): 3396000          
      ProjectedCSTypeGeoKey (Short,1): User-Defined
      ProjectionGeoKey (Short,1): User-Defined
      ProjCoordTransGeoKey (Short,1): CT_Equirectangular
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      ProjFalseEastingGeoKey (Double,1): 0                
      ProjFalseNorthingGeoKey (Double,1): 0                
      ProjCenterLongGeoKey (Double,1): 0                
      ProjCenterLatGeoKey (Double,1): 67.5000001       
      End_Of_Keys.

It turns out the problem is because GeographicTypeGeoKey is 0 (shown as Undefined in the report). This is treated by GDAL as a valid EPSG code and embedded in the WKT as an authority value. Note the anomolous AUTHORITY["EPSG","0"]. This gets picked up in preference to the actual spheroid parameters when writing to jpeg2000 (or geotiff which is the same for this purpose) and we end up with a file with an unlookupable GCS code which causes treatment as WGS84.

PROJCS["unnamed",
    GEOGCS["CRISM MRDR",
        DATUM["unknown",
            SPHEROID["unnamed",3396000,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","0"]],
    PROJECTION["Equirectangular"],
    PARAMETER["latitude_of_origin",67.5000001],
    PARAMETER["central_meridian",0],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]

As an initial improvement, I'm modifying libgeotiff to discard GCS values less than 1 which resolves the problem in this case. But I would also like to add some sanity checking in GDAL itself to deal with such situations.

Index: geo_normalize.c
===================================================================
RCS file: /cvs/maptools/cvsroot/geotiff/libgeotiff/geo_normalize.c,v
retrieving revision 1.51
diff -r1.51 geo_normalize.c
2099a2100,2101
>     if( psDefn->GCS < 1 || psDefn->GCS >= KvUserDefined )
>         psDefn->GCS = KvUserDefined;

comment:3 by warmerdam, 16 years ago

Milestone: 1.5.1
Resolution: fixed
Status: assignedclosed

I have applied a similar check at the GDAL level in trunk (r13641) and 1.5 branch (r13642).

Note: See TracTickets for help on using tickets.