#3382 closed defect (fixed)
HFA files not compatible with Erdas ViewFinder
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | highest | Milestone: | 1.7.1 |
Component: | GDAL_Raster | Version: | 1.7.0 |
Severity: | critical | Keywords: | hfa |
Cc: | Even Rouault, ilucena, Kyle Shannon |
Description
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
Change History (6)
comment:1 by , 13 years ago
Cc: | added |
---|---|
Status: | new → assigned |
comment:2 by , 13 years ago
Milestone: | → 1.7.1 |
---|---|
Priority: | normal → high |
I believe the problem is caused by me, possibly during my esri merge. I will dig deeper and address this issue.
comment:3 by , 13 years ago
Priority: | high → highest |
---|---|
Severity: | normal → critical |
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.
comment:4 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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).
comment:5 by , 13 years ago
Cc: | added |
---|
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 :
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
by
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.