<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello Chris</p>
    <p>Le 08/01/15 19:13, Chris Crook a écrit :<br>
    </p>
    <blockquote
cite="mid:666FB8D75E95AE42965A0E76A5E5337E14DE0520B5@prdlsmmsg01.ad.linz.govt.nz"
      type="cite">
      <pre wrap="">While I can see that "late binding" is an alternative to a pivot coordinate system, it seems to invite issues with non-uniqueness, depending on how it is implemented.  Are you able to point me to any references on this please?

</pre>
    </blockquote>
    <p align="justify">The "<i>Early binding</i>" versus "<i>Late
        binding</i>" approaches are briefly discussed in the <i>Geospatial
        Integrity of Geoscience Software</i> (GIGS) tests:</p>
    <blockquote>
      <p><a class="moz-txt-link-freetext" href="http://www.iogp.org/geomatics#2521115-gigs">http://www.iogp.org/geomatics#2521115-gigs</a> part 1 section 3.4<br>
      </p>
    </blockquote>
    <p align="justify">As mentioned in the above paper, the late-binding
      approach is a way to resolve (not invite) the non-uniqueness
      problem. Indeed, my experience in comparing Proj.4 (which in my
      understanding uses early-binding) with a software implementing the
      late-binding approach shows slightly different results. Below are
      some 2-3 years old screenshots I did for GeoAPI (I did not
      verified if the numbers would be the same today):<br>
    </p>
    <p><b>Coordinate transformations using Proj.4 (through JNI) 3 years
        ago:</b><br>
    </p>
    <p><img src="cid:part1.03070208.04050207@geomatys.fr" alt=""><br>
    </p>
    <p><b>Same coordinate transformations using late-binding approach:</b><br>
    </p>
    <p><img src="cid:part2.02030309.02090306@geomatys.fr" alt=""></p>
    <p align="justify">The transformation results are slightly different
      because there is at least 3 different ways to perform a datum
      shift between NTF and WGS84: <i>Geocentric translation</i>, <i>Molodensky</i>
      and <i>Abridged Molodensky</i>. If my memory serves me right,
      Proj.4 uses <i>Geocentric translation</i>, which is indeed the
      most accurate transformation method among those 3. But it is not
      the method mandated by the French mapping agency (IGN), which (if
      I remember correctly) rather specify that we shall use a <i>Molodensky</i>
      method. For interoperability with the maps produced by
      authorities, sometime we have to use the same transformation
      method that they use, regardless if their method is the most
      accurate or not.<br>
    </p>
    <p align="justify">Note that I verified that forcing the above
      late-binding implementation to the same transformation method than
      Proj.4 produced the same results.<br>
    </p>
    <p align="justify">The EPSG database contains a table that specify
      which transformation methods (not only the parameters) to use for
      various (<i>sourceCRS</i>, <i>targetCRS</i>) pairs. The method
      from NTF to WGS84 may not be the same than the method from NTF to
      another CRS. When using that EPSG table, there is no ambiguity. So
      I think we could summarize the difference between <i>early-binding</i>
      and <i>late-binding</i> approaches by saying that the
      late-binding approach uses that table, while the early-binding
      approach ignores it. Of course the table can not contain all
      possible (<i>sourceCRS</i>, <i>targetCRS</i>) pairs, so we have
      to fallback on an early-binding approach if we can not find an
      entry for our particular pair of CRS (or sometime on a mixed
      approach, trying to find another pair of CRS which exist in the
      database).<br>
    </p>
    <p>    Regards,<br>
    </p>
    <p>        Martin<br>
    </p>
    <p><br>
    </p>
  </body>
</html>