EPSG:3785 WKT keyword ordering is wrong.

[warmerdam]

An EPSG lookup on EPSG:3785 produces the following pretty WKT:

PROJCS["Popular Visualisation CRS / Mercator (deprecated)",
    GEOGCS["Popular Visualisation CRS",
        DATUM["Popular_Visualisation_Datum",
            SPHEROID["Popular Visualisation Sphere",6378137,0,
                AUTHORITY["EPSG","7059"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6055"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4055"]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    PROJECTION["Mercator_1SP"],
    PARAMETER["central_meridian",0],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +
x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs"],
    AUTHORITY["EPSG","3785"],
    AXIS["X",EAST],
    AXIS["Y",NORTH]]

The problem, as pointed out by Martin Daly, is that the ordering does not adhere to the OGC WKT grammar (not counting the illegal EXTENSION node). In particular, I believe the UNITS should come after the projection parameters. This WKT was the result of a normal OGRSpatialReference::importFromEPSG().

importFromEPSG() should attempt to return legally ordered WKT keywords.

This impacts software that uses WKT dictionaries from epsg_tr.py (like PostGIS).

[warmerdam]

I'll fix this. It should just be a matter of calling FixupOrdering() at the proper place.

[warmerdam]

Fixed importFromEPSGA() in trunk (r22819) and 1.8 (r22820) to always call FixupOrder() at the end of the method. Of course there are other code paths that can result in invalid ordering when building coordinate systems, but this takes care of a large family that we really hope will be standards compliant.

[etourigny]

this fixed caused a minor regression described in #4345

found a bug in importFromEPSG(), if the target code is not found this statements resets eErr, therefore the calling function does not know it was not found, and an empty SRS is used. 
eErr = FixupOrdering();

using 1.8 svn, the defect can be shown with the following command:

./testepsg  EPSG:43264444
ERROR 6: EPSG PCS/GCS code 43264444 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
Validate Fails.
WKT[EPSG:43264444] =


Simplified WKT[EPSG:43264444] =


Old Style WKT[EPSG:43264444] = 
ESRI'ified WKT[EPSG:43264444] = 

ERROR 6: No translation an empty SRS to PROJ.4 format is known.
PROJ.4 rendering of [EPSG:43264444] = 
)))

fixed in 1.8(r23422) and trunk (r23396)

[Even Rouault]

Milestone 1.8.2 deleted