<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello Eric<br>
    <br>
    Le 08/05/12 08:30, Eric HORLAIT a écrit :
    <blockquote cite="mid:CBCDDA04.4F248%25ehorlait@tutor.fr"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div>
        <div>
          <div style="font-size: medium; font-weight: normal;
            font-family: Helvetica; "><font
              face="Calibri,Verdana,Helvetica,Arial"><span
                style="font-size: 11pt; ">I did quite that with Gtools
                with the following code. The test is a comparaion with
                cs2cs result. And It does not match!</span></font></div>
          <div>
          </div>
        </div>
      </div>
      <div style="font-size: medium; font-weight: normal; font-family:
        Helvetica; "><font face="Calibri,Verdana,Helvetica,Arial"><span
            style="font-size: 11pt; ">Do you think this will be the same
            thing with GToolKit?</span></font></div>
    </blockquote>
    <br>
    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):<br>
    <br>
    PROJCS["Lambert II étendu", GEOGCS[..., PRIMEM["Paris",
    2.337229167], UNIT["grad", 0.01570796326794897],
    ...],PROJECTION["Lambert_Conformal_Conic_1SP"], ...
    PARAMETER["latitude_of_origin",46.8], ...]<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    Geotk tries to handle the "various WKT flavors" problem with a
    Convention enumeration:<br>
    <br>
       
    <a class="moz-txt-link-freetext" href="http://www.geotoolkit.org/apidocs/org/geotoolkit/io/wkt/Convention.html">http://www.geotoolkit.org/apidocs/org/geotoolkit/io/wkt/Convention.html</a><br>
    <br>
    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.<br>
    <br>
        Regards,<br>
    <br>
            Martin<br>
    <br>
  </body>
</html>