PRIMEM element in WKT shall be expressed in units of the enclosing GEOGCS

[desruisseaux]

Section 7.3.14 (page 21) of OGC 01-009 specification (​http://www.opengeospatial.org/standards/ct) said about the PRIMEM clause:

This defines the meridian used to take longitude measurements from. The units of the <longitude> must be inferred from the context. If the PRIMEM clause occurs inside a GEOGCS, then the longitude units will match those of the geographic coordinate system. If the PRIMEM clause occurs inside a GEOCCS, then the units will be in degrees.

(Remainder: GEOGCS = GeographicCRS and GEOCCS = GeocentricCRS)

However, the spatial_ref_sys.sql file on PostGIS trunk defines the PRIMEM longitudes in degrees inside GEOGCS clauses having UNIT["grad", 0.01570796326794897], while according the above specification it shall be in gradiants. This seems to affect mostly the French CRS prior to RGF93.

The spatial_ref_sys table can be fixed for the French CRS using the following SQL statement:

UPDATE spatial_ref_sys SET srtext = REPLACE(srtext,
    'PRIMEM["Paris",2.33722917,',
    'PRIMEM["Paris",2.5969213,')
  WHERE srtext LIKE
    '%PRIMEM["Paris",2.33722917,%UNIT["grad"%';

If the PostGIS WKT where generated from OGRSpatialReference class, maybe a fix for this class should be considered? With the current WKT, softwares expecting WKT-compliant definitions have an offset when building their CRS from an uncorrected spatial_ref_sys table (this happen in Geotoolkit.org).

[Even Rouault]

"Interesting" issue. Actually, FrankW seems to be fully aware of it, since I can see it is mentionned in ​http://home.gdal.org/projects/opengis/wktproblems.html .

In GDAL, the transformation from the UNIT of the GEOGCS to deegree is done in EPSGAngleStringToDD() in ogr/ogr_fromepsg.cpp . In data/prime_meridian.csv, the primem value is expressed in its units (8903,Paris,2.5969213), and then EPSGAngleStringToDD() transforms it to 2.33722917

The implications of changing that would also need a few changes in OGRSpatialReference::exportToProj4() (because proj4 also expects prime meridian to be in deegree I believe), and likely in morphToESRI()/morphFromESRI() too, because my understanding of the above quoted page, is that ESRI WKT follows the same convention as current GDAL.

Would be worth a small RFC if someone wants to change that to capture the implications (and I'm not volunteering ;-))

I'm wondering if advertizing UNIT["degree" might not be the safest change, although technically speeking the WKT would be different from the one that is theoretically expected from the EPSG definition.

In the meantime, I'm afraid that hacking GeoToolkit to do the appropriate hot replace might be the fastest way for you since they are not so many prime meridians...

[desruisseaux]

The ESRI interpretation of WKT format seems to have other departures regarding the OGC standard. An other issue - not documented on the wktproblems.html page - is that ESRI seems to ignore the order of AXIS elements (I'm not totally sure about that; just my feeling from a few naive experiments I did a while ago). An other minor departure is that ESRI uses the American spelling "meter" while OGC and GDAL use "metre". Oracle has more serious departures: Oracle inserts the Bursa-Wolf parameters straight into the DATUM element, without enclosing them in a TOWGS84 element. In addition, Oracle uses Coordinate Operation names instead than Operation Method names in PROJECTION elements.

For all those reasons, it seems that we don't really have a "universal" WKT format, but different flavors of WKT. In Geotoolkit.org, we are already applying the above-cited patch and our WKT parser/formatter is already designed to adapt to different WKT flavors, so I can adapt to whatever solution GDAL choose. However if GDAL chooses to keep the current behaviour, it would create a new "GDAL flavor" of WKT format: similar to the ESRI behaviour regarding the PRIMEM element, while similar to OGC behaviour regarding "metre" spelling (I don't know for AXIS order). In any case it would be nice to document the GDAL choice in some obvious place. I would appreciate for example a comment in the header of the PostGIS spatial_ref_sys.sql file with a link to the web page documenting the GDAL WKT syntax. Ideally I would like not a full description of GDAL WKT syntax, but rather something simple like "The GDAL WKT format is conform to the OGC WKT format (link here) except for the following departures: units of PRIMEM are always decimal degrees, (document other departures here).

[Even Rouault]

In 41748:

Update wktproblems.html to mention in particular that OGR uses degrees for PRIMEM longitude, and add more links to it (fixes #4524)