[geotk] IGNF registry

Martin Desruisseaux martin.desruisseaux at geomatys.fr
Tue May 8 11:54:12 EDT 2012


Hello Eric

Le 08/05/12 08:30, Eric HORLAIT a écrit :
> I did quite that with Gtools with the following code. The test is a 
> comparaion with cs2cs result. And It does not match!
> Do you think this will be the same thing with GToolKit?

I tested and Geotk produces the same result than Geotools. It took me a 
little while to investigate, and finally the problem appears to be in 
the WKT string. The IGN:LAMBE definition is (trimming the parts not 
relevant to this discussion):

PROJCS["Lambert II étendu", GEOGCS[..., PRIMEM["Paris", 2.337229167], 
UNIT["grad", 0.01570796326794897], 
...],PROJECTION["Lambert_Conformal_Conic_1SP"], ... 
PARAMETER["latitude_of_origin",46.8], ...]

The key element is UNIT["grad", ...]. According the WKT specification, 
this implies that the PRIMEM element and all PARAMETER elements having 
angular values shall be in gradiants. However many software are not 
compliant with this WKT clause, including Proj.4/GDAL and ESRI. The IGN 
definition string follows that path: the PRIMEM value is 2.337°, which 
is decimal degrees (the values in gradiants is 2.597), and the latitude 
of origin is in degrees too (46.8°, while the value in gradiants 
according the EPSG database is 52).

However Geotk tries to be strictly OGC compliant and interprets the 
2.337 and 46.8 angle values as gradiants, because of the UNIT["grad"] 
declaration. It was apparently not the intend of IGN. If you replace 
UNIT[\"grad\",0.01570796326794897] by 
UNIT[\"degree\",0.0174532925199433] in the WKT definition, you should 
get the same result than cs2cs.

Geotk tries to handle the "various WKT flavors" problem with a 
Convention enumeration:

     http://www.geotoolkit.org/apidocs/org/geotoolkit/io/wkt/Convention.html

The convention you are facing is the "ESRI" convention. Current Geotk 
implementation applies the conventions only at formatting time and, in 
the ESRI convention case, only to PRIMEM value. However given the issue 
you reported, I would bet that ESRI uses decimal degrees not only for 
PRIMEM, but also for all PARAMETER angular values. I will update the 
code in order to extend the ESRI case handling to PARAMETER elements as 
well, and to parsing too.

     Regards,

         Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geotoolkit/attachments/20120508/72b0eeaf/attachment.html


More information about the Geotoolkit mailing list