ESRI Morphing Broken for Equidistant Cylindrical

[warmerdam]

Giving the SRS:

PROJCS["World_Equidistant_Cylindrical",
    GEOGCS["GCS_WGS_1984",
      DATUM["D_WGS_1984",
        SPHEROID["WGS_1984",6378137,298.257223563]],
      PRIMEM["Greenwich",0],
      UNIT["Degree",0.017453292519943295]],
    PROJECTION["Equidistant_Cylindrical"],
    PARAMETER["False_Easting",0],
    PARAMETER["False_Northing",0],
    PARAMETER["Central_Meridian",0],
    PARAMETER["Standard_Parallel_1",60],
    UNIT["Meter",1]]

a morphFromESRI(), followed by a morphToESRI() results in:

PROJCS["World_Equidistant_Cylindrical",
    GEOGCS["GCS_WGS_1984",
        DATUM["D_WGS_1984",
            SPHEROID["WGS_1984",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Equidistant_Cylindrical"],
    PARAMETER["False_Easting",0],
    PARAMETER["False_Northing",0],
    PARAMETER["Central_Meridian",0],
    PARAMETER["latitude_of_origin",60],
    UNIT["Meter",1]]

It appears that morphFromESRI() is inappropriately applying a switch of standard_parallel_1 to latitude_of_origin when the parameter should be left unaltered in this logic:

 /* -------------------------------------------------------------------- */
/*      Remap Equidistant_Cylindrical parameter. It is same as          */
/*      Stereographic                                                   */
/* -------------------------------------------------------------------- */
    if( pszProjection != NULL && EQUAL(pszProjection,"Equidistant_Cylindrical") )
        GetRoot()->applyRemapper( 
            "PARAMETER", 
            (char **)apszPolarStereographicMapping + 0, 
            (char **)apszPolarStereographicMapping + 1, 2 );

which appears to have been added as part of r15992 (the big merge of Xiuguang Zhou updates).

Note that SetEquirectangular2() - the expended OGR Equirectangular definition includes standard_parallel_1 (essentially latitude of true scale) and latitude_of_origin as discussed in ​http://www.remotesensing.org/geotiff/proj_list/equirectangular.html.

The problem may also exist in the 1.6-esri branch.

[warmerdam]

I have made the correction I think is appropriate in trunk (r17272) and added a test (r17273).

I'm leaving this ticket open for Xiuguang to review the change, and to consider applying it in 1.6-esri.

[warmerdam]

I have applied a variation on this patch in 1.6-esri branch (r17324) as provided by Xiuguang. I believe it also attempts to avoid problems with Plate_Carree projections.

I have applied the Plate_Carree portion in trunk too (r17326).