Set projection to an existing HFA dataset as a PE string

[gaopeng]

HFA driver can't set projection as a PE string (ProjectionX) for the following two cases:

• An IMG dataset with an existing ProjectionX string (Update)
• An IMG dataset without a ProjectionX string (Add)

[warmerdam]

In order to try and reproduce the problem with adding a ProjectionX to a file without one I have constructed an ungeoreferenced input .img file (attached as safe_plain.img), and run the following script:

#!/usr/bin/env python

from osgeo import gdal
import os

tricky_wkt = 'PROJCS["Everest_Modified_1969_RSO_Malaya_Meters",GEOGCS["GCS_Everest_Modified_1969",DATUM["D_Everest_Modified_1969",SPHEROID["Everest_Modified_1969",6377295.664,300.8017]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Rectified_Skew_Orthomorphic_Natural_Origin"],PARAMETER["False_Easting",804670.24],PARAMETER["False_Northing",0.0],PARAMETER["Scale_Factor",0.99984],PARAMETER["Azimuth",-36.97420943711801],PARAMETER["Longitude_Of_Center",102.25],PARAMETER["Latitude_Of_Center",4.0],PARAMETER["XY_Plane_Rotation",-36.86989764584402],UNIT["Meter",1.0]]'

os.system('cp safe_plain.img plain.img')

ds = gdal.Open('plain.img',gdal.GA_Update)

ds.SetProjection( tricky_wkt )

ds = None

This produced the output file (attached as plain.img) which seems to have a valid readable ProjectionX definition. Could you provide some additional detail for me to reproduce the "Add" case?

[warmerdam]

safe_plain.img - the raw .img file

[warmerdam]

plain.img - after adding the ProjectionX.

[gaopeng]

Frank,

I am sending you two test images, degs.img, and projectionx.img. When setting to Mercator, HFA simply returns on degs.img. For projectionx.img, it passed HFASetPEString() but crashed. I think degs.img was created by ERDAS (RDO). The projectionx.img is created using GDAL.

degs.img returns here:

GByte *pabyData = poProX->MakeData( 700 + strlen(pszPEString) ); if( !pabyData )

return CE_None;

projectionx.img crashes

msvcr90d.dll!memcpy(unsigned char * dst=0x0012be8c, unsigned char * src=0xd9395bcd, unsigned long count=4) Line 322 Asm

gdal16d.dll!HFAField::SetInstValue(const char * pszField=0x0c16c040, int nIndexValue=0, unsigned char * pabyData=0xd9395bcd, unsigned int nDataOffset=3453179084, int nDataSize=842150553, char chReqType='d', void * pValue=0x0012bf30) Line 411 + 0xf bytes C++

gdal16d.dll!HFAType::SetInstValue(const char * pszFieldPath=0x0c16c030, unsigned char * pabyData=0x0b6b8df8, unsigned int nDataOffset=362231, int nDataSize=110, char chReqType='d', void * pValue=0x0012bf30) Line 258 C++ gdal16d.dll!HFAEntry::SetFieldValue(const char * pszFieldPath=0x0c16c030, char chReqType='d', void * pValue=0x0012bf30) Line 721 C++ gdal16d.dll!HFAEntry::SetDoubleField(const char * pszFieldPath=0x0c16c030, double dfValue=0.00000000000000000) Line 753 C++ gdal16d.dll!HFASetMapInfo(hfainfo * hHFA=0x169628b8, const Eprj_MapInfo * poMapInfo=0x0012c0a0) Line 1084 C++ gdal16d.dll!HFADataset::WriteProjection() Line 2003 + 0x19 bytes C++ gdal16d.dll!HFADataset::FlushCache() Line 1456 C++ gdal16d.dll!HFADataset::~HFADataset() Line 1415 C++

[warmerdam]

I discovered that when updating an .img file with a preexisting MapInfo structure, the updated mapinf structure was being corrupted. I have applied r15940 in trunk which seems to correct this. It also re-enables update-in-place of ProjectX entries.

I'll now test with the newly provided files. I'll migrate the changes back to 1.6 once I'm comfortable all aspects are addressed.

[warmerdam]

I have confirmed that adding a ProjectionX block to degs.img fails because the type Eprj_MapProjection842 is not defined in the file type dictionary.

This will require a bit of work...

[warmerdam]

Changes in trunk (r15942) add the ability to extend the dictionary in an existing file with new definitions. This appears to correct handling of writing a ProjectionX entry to a file that previous lacked the Eprj_MapProjection842 definition.

With these changes I seem to be able to update both provided files with a ProjectionX requiring definition. I have migrated both sets of changes back into 1.6 (r15943).

I'm closing this ticket, but please reopen if this does not appear to resolve all problems.