OGRSpatialReference:morphFromESRI() needs updating for Orthographic projection

[pds]

While using the HFA driver I came across a problem when warping from a GeoTiff? using Orthographic projection to HFA - the 'latitude_of_origin' and 'central_meridian' WKT projection parameters were getting munged to 'Latitude_Of_Center' and 'Longitude_Of_Center'.

Looking at the HFA driver this seemed to be traceable to its use of OGRSpatialReference:morphFromESRI() - presumably the Latitude_Of_Center and Longitude_Of_Center are ESRI string attribs that aren't being back-converted properly.

[pds]

Patch with proposed fix of Orthographic handling in WarpFromESRI and WarpToESRI

[etourigny]

Can you provide a test case with sample file?

[pds]

Sample ERDAS Imagine (HFA) file created by gdal

[pds]

Sample original tif testing file I warped from.

[pds]

Replying to etourigny:

Can you provide a test case with sample file?

Sure:- have attached a sample file in HFA format that can be used for testing. Note that the HFA format allows use of an ESRI file format internally: the patch is not supposed to change that, but the re-reading from that format into correct WKT.

How to re-create that file from the sample tif:

gdalwarp -t_srs '+proj=ortho +lat_0=-37 +lon_0=145 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs' -of HFA melb-small.tif melb-small-ortho.img

Then the simplest way to exercise the relevant code is to run 'gdalinfo' on the produced file (as reading in the projection for gdalinfo is the same code used by gdalwarp that originally raised the issue):

WKT of running 'gdalinfo' without applying proposed patch:

PROJCS["Orthographic",
    GEOGCS["GCS_WGS_1984",
        DATUM["WGS_1984",
            SPHEROID["WGS_1984",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Orthographic"],
    PARAMETER["Latitude_Of_Center",-37],
    PARAMETER["Longitude_Of_Center",145],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

WKT section returned via gdalinfo after applying patch to gdal

PROJCS["Orthographic",
    GEOGCS["GCS_WGS_1984",
        DATUM["WGS_1984",
            SPHEROID["WGS_84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Orthographic"],
    PARAMETER["latitude_of_origin",-37],
    PARAMETER["central_meridian",145],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

Where you can see the 'latitude_of_origin' and 'central_meridian' comply with the OGC WKT params in the 2nd case, but not the first ( http://www.remotesensing.org/geotiff/proj_list/orthographic.html)

Added note: my patch code updates both the morphFromESRI() but also morphToESRI() methods to apply this mapping. Thus I'm not sure how those ESRI parameters were getting in there initially:- possibly the HFA driver is using some other code than morphToESRI()?

[pds]

Replying to pds:

Added note: my patch code updates both the morphFromESRI() but also morphToESRI() methods to apply this mapping. Thus I'm not sure how those ESRI parameters were getting in there initially:- possibly the HFA driver is using some other code than morphToESRI()?

Regarding this, just did a bit more digging:

So the OGRSpatialReference::morphToESRI() function contains a call right at the end to do a general final remap of parameter names (line 1375):

RemapPNamesBasedOnProjCSAndPName( this, pszProjection, (char **)apszParamNameMapping);

And when I look at apszParamNameMapping, defined in source:trunk/gdal/ogr/ogr_srs_esri_names.h, it includes relevant entries for Orthographic:

"Orthographic", "central_meridian", "Longitude_Of_Center",
"Orthographic", "latitude_of_origin", "Latitude_Of_Center",

And after running this function, the values are as expected for ESRI.

But it appears there's no equivalent call in morphFromESRI() that I can see, which is why the Orthographic-specific remapping code would seem to be needed.

Qtn: this may have implications for pulling other projections back from ESRI as there are several entries in that apszParamNameMapping table, e.g. Gnomonic, New_Zealand_Map_Grid.

[pds]

In light of above comment, will upload a new patch that only modifies morphFromESRI() to adjust for Orthographic, since morphToESRI() works ok given the call to RemapPNamesBasedOnProjCSAndPName()

[pds]

Updated patch that only modifies morphFromESRI()

[rouault]

I thought I had left a comment the other day, but apparently not. I wanted to say that the propossed mapping is likely adequate, since it looks like it is also done in the 1.6-esri and 1.8-esri branches. Those were customer branches maintained by FrankW for ESRI : http://trac.osgeo.org/gdal/browser/sandbox/warmerdam/1.8-esri/gdal . The ideal would be some kind of convergence, but the amount of changes done by ESRI in ogr_srs_esri.cpp in those branches w.r.t the state of ogr_srs_esri.cpp is really scary, and in the form of a huge single commit. Would be great if they could contribute to trunk in a more constructive (=incremental) way. Just dreaming...

[pds]

Replying to rouault:

I thought I had left a comment the other day, but apparently not. I wanted to say that the propossed mapping is likely adequate, since it looks like it is also done in the 1.6-esri and 1.8-esri branches. Those were customer branches maintained by FrankW for ESRI : http://trac.osgeo.org/gdal/browser/sandbox/warmerdam/1.8-esri/gdal . The ideal would be some kind of convergence, but the amount of changes done by ESRI in ogr_srs_esri.cpp in those branches w.r.t the state of ogr_srs_esri.cpp is really scary, and in the form of a huge single commit. Would be great if they could contribute to trunk in a more constructive (=incremental) way. Just dreaming...

Thanks for the update - yes, sounds like a big update of esri mappings sounds ideal ...

but is this specific patch ok for adding to the trunk?

At the moment I'm having to re-apply it for each development build I want to test HFA projections with.

Anything else need to happen for it to be accepted - updated unit tests?

[rouault]

warpFromESRI-orthographic-patch-02.diff looks good to me. A new test for that in osr_esri would be good to ensure that this is not lost in an hypothetical future big update

[rouault]

r23320 /trunk/ (autotest/osr/osr_esri.py gdal/ogr/ogr_srs_esri.cpp): morphFromESRI(): add correct mapping of Longitude_Of_Center and Latitude_Of_Center to standard parameter names for Orthographic projection (#4249)

[pds]

Thanks for creating the test Etienne and committing this.

[etourigny]

well you should thank Even!