id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
4524,PRIMEM element in WKT shall be expressed in units of the enclosing GEOGCS,desruisseaux,warmerdam,"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).
",defect,new,normal,,OGR_SF,unspecified,normal,,,