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 {{{}}} 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,closed,normal,,OGR_SF,unspecified,normal,fixed,,