img files (HFA) are created with simplified prj strings

[ccjklppp]

when creating img files (HFA driver), the files are created with simplified prj strings (i.e. a prj with no authority codes). for example: img file created by gdalwarp with epsg 4326, contains the following prj (read by gdalinfo):

GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]]

On the contrary, when I use erdas imagine to create an img file (from the same source), the output contains the following prj (read by gdalinfo):

GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]

[Even Rouault]

Could you attach a file generated by ERDAS Imagine that is reported with AUTHORITY["EPSG","4326"] by gdalinfo ?

[ccjklppp]

I added 3 files for example (input, ouputs - erdas,gdal)

[Even Rouault]

trunk r29763, branches/2.0 r29764 "HFA: when reading projection, preserve EPSG code if AutoIdentifyEPSG() identified the SRS, even if a PE string is present (#6079)"

[ccjklppp]

It seems that the repair that was performed fixed only some coordinate systems such as Wgs84, Wgs72... The prj written for other coordinate systems such as Ed1950 (EPSG: 4230) is still as before the change (without EPSG code in the output header)

[Even Rouault]

Replying to ccjklppp:

It seems that the repair that was performed fixed only some coordinate systems such as Wgs84, Wgs72... The prj written for other coordinate systems such as Ed1950 (EPSG: 4230) is still as before the change (without EPSG code in the output header)

Yes, this is a limitation of the Imagine coordinate system format. It doesn't store EPSG codes. So only a few codes can be retrieved back the AutoIdentifyEPSG() method. A much more involved method would be needed to identify the EPSG code from the definitions of the EPSG database. I'm removing the target milestone as, personaly, I'm not planning to tackle that without appropriate funding. If you are interested, you can contact me at contact@…

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.