HFA files not compatible with Erdas ViewFinder

[warmerdam]

Frank,

I generated those sample files by translating directly from Geotiff sample files provided by Intermap, to HFA reducing the image to 5% to fit on e-mail.

02/03/2010  01:36 PM           110,477 n00w075e1ori.img
02/03/2010  01:35 PM           109,259 n00w075e1ori_16.img
02/03/2010  01:36 PM           418,514 n37w113a1ori.img
02/03/2010  01:35 PM           417,521 n37w113a1ori_16.img
02/03/2010  01:36 PM           418,540 n53e015c4ori.img
02/03/2010  01:35 PM           417,574 n53e015c4ori_16.img

The files with suffix "_16.img" were generated by gdal-1.6. The others were generated with GDAL 1.7.

I downloaded and installed Erdas ViewFinder and I noticed that the files generated with 1.7 does not open on that software or ArcExplorer for that matter. The ones generated by 1.6 work just fine.

It looks like some changes on the HFA driver created a bug. I was going crazy thinking that the problem was with GeoRaster but those test are just Geotiff to HFA and we can clearly see the problem. It looks like an WKT issue:

Files: n00w075e1ori_16.img
Size is 281, 281
Coordinate System is:
PROJCS["UTM Zone 18, Northern Hemisphere",
    GEOGCS["WGS_1984",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.2572235630016],
            TOWGS84[0,0,0,0,0,0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-75],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1],
    AUTHORITY["EPSG","32618"]]

Files: n00w075e1ori.img
Size is 281, 281
Coordinate System is:
PROJCS["WGS_1984_UTM_Zone_18N",
    GEOGCS["GCS_WGS_1984",
        DATUM["WGS_1984",
            SPHEROID["WGS_1984",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-75],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

I can see some changes made by you and Even:

http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/hfa?order=date&desc=1

Do you know of any change that might has caused that issue?

Regards,

Ivan

[warmerdam]

Even writes;

I've reviewed quickly my changesets in HFA code between 1.6 and 1.7 and I don't believe that any of them could affect how HFA files are written (except a forward port of u2 compression from 1.6-esri branch, but it is 99.9% likely unrelated with your issue).

If the issue is really related to difference in SRS writing, one good candidate changeset would be http://trac.osgeo.org/gdal/changeset/15995 (actually it looks like it is the first changeset changing HFA driver after 1.6.0 release)

When dumping the 1.6 and 1.7 outputs with the hfatest utility in gdal/frmts/hfa, I see that difference :

1.7.0 :

    Map_Info(Eprj_MapInfo) @ 108503 + 117 @ 108631
    + proName = `WGS_1984_UTM_Zone_18N'

1.6.0 :

    Map_Info(Eprj_MapInfo) @ 107285 + 117 @ 107413
    + proName = `WGS 84 / UTM zone 18N'

Another possibly significant difference is that in 1.7.0 a PE String is written.

The difference between the above 2 proName values is due to the morphToESRI() call in WritePeStringIfNeeded(). But the failure might be also be due to the presence of the PE string itself.

You could try to comment peStrStored = WritePeStringIfNeeded(&oSRS, hHFA); at line 1844 in hfadataset.cpp and see what happens.

If this works, in order to better isolate the issue , you can try to reenable line 1884 and test 1), 2) and 1) + 2)

1) to determine if the difference in proName string is signifcant, replace the lines 2392-2393

poSRS->morphToESRI();
poSRS->exportToWkt( &pszPEString );

by

OGRSpatialReference* poSRSCloned = poSRS->Clone();
poSRSCloned ->morphToESRI();
poSRSCloned ->exportToWkt( &pszPEString );
delete poSRSCloned;

2) to determine if the presence of the PE String is significant, comment out HFASetPEString( hHFA, pszPEString ); at line 2394

Whatever the results are, I think only Frank will be in position to confirm if this is a bug in GDAL or in the other viewers.

[warmerdam]

I believe the problem is caused by me, possibly during my esri merge. I will dig deeper and address this issue.

[warmerdam]

For some reason, files now are produced with empty layer names like:

root(root) @ 106877 + 0 @ 0

  IMGFormatInfo(ImgFormatInfo831) @ 107005 + 4 @ 107133
  + spaceUsedForRasterData = 102400

  (Eimg_Layer) @ 107137 + 20 @ 107265
  + width = 281
  + height = 281
  + layerType = athematic
  + pixelType = u8
  + blockWidth = 64
  + blockHeight = 64

while they used to be named Layer_1, etc like:

root(root) @ 106877 + 0 @ 0

  IMGFormatInfo(ImgFormatInfo831) @ 107005 + 4 @ 107133
  + spaceUsedForRasterData = 102400

  Layer_1(Eimg_Layer) @ 107137 + 20 @ 107265
  + width = 281
  + height = 281
  + layerType = athematic
  + pixelType = u8
  + blockWidth = 64
  + blockHeight = 64

Erdas ViewFinder is reporting error messages like "FileLayerNamesGet failed for...". While GDAL is apparently not sensitive to this problem, it is not at all surprising that it would break other apps. A *very* serious bug.

[warmerdam]

The problem appears to be that HFACreateCopy is copying band descriptions without first checking if they are non empty and HFASetBandName() does not ignore empty names. The change was introduced in 1.7/trunk in r16425 (seemly as an aside to other changes) and was not backported into 1.6-esri or elsewhere as far as I can see.

I have corrected this in trunk (r18728) and 1.7 branch (r18729).

[warmerdam]

The same problem slipped into 1.6-esri as part of r18627 and was fixed (r19192).