Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#4178 closed defect (fixed)

EPSG:3785 WKT keyword ordering is wrong.

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone:
Component: OGR_SRS Version: unspecified
Severity: normal Keywords: WKT ordering
Cc: mpd

Description

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).

Change History (4)

comment:1 Changed 6 years ago by warmerdam

Status: newassigned

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

comment:2 Changed 6 years ago by warmerdam

Milestone: 1.8.2
Resolution: fixed
Status: assignedclosed

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.

comment:3 Changed 6 years ago by 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)

comment:4 Changed 4 years ago by Even Rouault

Milestone: 1.8.2

Milestone 1.8.2 deleted

Note: See TracTickets for help on using tickets.