<div dir="auto">Thank you Martin.<div dir="auto"><br></div><div dir="auto">I now understand the reason for PROJ 6!</div><div dir="auto"><br></div><div dir="auto">Your example is worth a thousand words!<br><br>Ron<br><div data-smartmail="gmail_signature" dir="auto">--<br>Ron Russell, from my Mobile Phone</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 1 Aug 2019, 08:01 Martin Desruisseaux, <<a href="mailto:martin.desruisseaux@geomatys.com">martin.desruisseaux@geomatys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_7534401347485744367moz-cite-prefix">
      <p>Hello Cameron</p>
      <p>Le 01/08/2019 à 04:32, Cameron Shorter a écrit :</p>
    </div>
    <blockquote type="cite">
      <p>
        
      </p>
      <div dir="ltr">
        <p>I'm hoping to expand upon descriptions of potential solutions
          to our GDA2020/GDA94/WGS84 Web Mercator map misalignment
          problem, (possibly extended to discuss a time-dependent
          reference frame).<br>
        </p>
        <div>
          <p>I'm confused about the meaning of: "early-binding versus
            late-binding implementations". Is it relevant to problems
            relevant to WGS84 map-misalignment or a time-dependent
            reference frame? If so, I'm hoping you might be able to help
            explain how it might need to be described in suggested
            solutions.</p>
        </div>
      </div>
    </blockquote>
    <p align="justify">Yes, "early-binding" versus "late-binding" are
      relevant to map-misalignment problem. But you can avoid them if
      desired by using Roger's "hub transformation technique" terms
      instead, which may be more intuitive. I used "early/late-binding"
      terms because they are defined by IOGP (the same organization than
      the one publishing the EPSG geodetic dataset) in Geospatial
      Integrity of Geoscience Software (GIGS), Part 1, §3.4 (report
      430-1, September 2011) [1]. But I see "hub transformation
      technique" as synonymous to "early-binding implementation".
    </p>
    <p align="justify">In hub transformation technique, a universal hub
      is selected (usually WGS84, but not necessarily) and all CRS
      contain transformation parameters to that hub (the "TOWGS84"
      element in WKT 1). The term "early-binding" is used because those
      transformation parameters are bind to the CRS early, right at CRS
      definition time. By contrast, when the hub transformation
      technique is NOT used, there is no transformation parameter bind
      to the CRS definition (no "TOWGS84" element, which does not exist
      anymore in WKT 2). The software is then forced to search for
      transformation parameters at transformation definition time (when
      source CRS, target CRS, epoch and area of interest are known)
      instead than CRS definition time, which is "late-binding".<br>
    </p>
    <p align="justify">The hub transformation technique (early binding)
      seems appealing because it is simpler. But it assumes that
      transformation from CRS A to CRS B can always be represented by
      transformation from CRS A to the hub (WGS84), followed by
      transformation from the hub to CRS B. Intuitively is seems an
      approach that should work. But actually this reasoning assumes
      that transformations from/to the hub are exact. As soon as we take
      in account that transformations from/to the hub are approximate,
      the assumption that "A to B" is equivalent to "A to hub to B" stop
      being true.<br>
    </p>
    <p align="justify">We can compare the problem with linear regression
      (this little experiment can be done in an Excel spreadsheet). Let
      say we have one-dimensional coordinates in three CRS: A, B and C.
      Let say we can establish linear correlations between A, B and C
      with some residual errors. We could express transformation from A
      to B as B=<i>f</i>(A) where the <i>f</i> function has been
      determined by least  squares method. Then we can express
      transformation from B to C as C=<i>g</i>(B) where the <i>g</i>
      function has been determined by least squares method too. Finally
      the transformation from A to C could be represented by C = <i>g</i>(<i>f</i>(A)).
      That would be identical to a C = <i>h</i>(A) function computed
      directly from A and C data (ignoring completely B) if all those
      functions were exact. But because they are computed by least
      squares method, <i>g</i>(<i>f</i>(A)) is not identical to <i>h</i>(A)
      because the errors were not minimized in the same way.</p>
    <p align="justify">ISO 19111 distinguishes "conversions" and
      "transformations". One way to see them would be to said that
      conversions are exact (ignoring rounding errors) while
      transformations have errors related to the physical world. The hub
      technique can works for a chain of conversions (including map
      projections), but does not work for a chain of transformations.
      This is unrelated to the choice of WGS84 as a hub. Even if we try
      to define a new universal hub, as long as transformations from/to
      that hub can not be exact, the hub transformation technique will
      continue to cause misalignments.<br>
    </p>
    <p>So in summary:</p>
    <ul>
      <li>"Early binding" ≈ hub transformation technique.</li>
      <li>"Late binding" ≈ hub transformation technique NOT used,
        replaced by a more complex technique consisting in searching
        parameters in the EPSG database after the transformation context
        (source, target, epoch, area of interest) is known.</li>
      <li>The problem of hub transformation technique is independent of
        WGS84. It is caused by the fact that transformations to/from the
        hub are approximate. Any other hub we could invent in
        replacement of WGS84 will have the same problem, unless we can
        invent a hub for which transformations are exact (I think that
        if such hub existed, we would have already heard about it).</li>
    </ul>
    <p>The solution proposed by ISO 19111 (in my understanding) is:</p>
    <ul>
      <li>Forget about hub (WGS84 or other), unless the simplicity of
        early-binding is considered more important than accuracy.</li>
      <li>Associating a CRS to a coordinate set (geometry or raster) is
        no longer sufficient. A {CRS, epoch} tuple must be associated.
        ISO 19111 calls this tuple "Coordinate metadata". From a
        programmatic API point of view, this means that <tt>getCoordinateReferenceSystem()</tt>
        method in <tt>Geometry</tt> objects (for instance) needs to be
        replaced by a <tt>getCoordinateMetadata()</tt> method.</li>
    </ul>
    <p align="justify">Said otherwise, the solution to misalignment
      problem involves two parts: dynamic datum and late-binding
      implementation. Dynamic datum is enabled by replacing association
      to CRS by association to {CRS, epoch} tuple in all client
      applications (geometries, rasters, etc.). Late-binding is about
      knowing the context in which the transformation will be applied,
      and is more an implementation issue (largely solved in PROJ 6).<br>
    </p>
    <p>Regards,</p>
    <p>    Martin<br>
    </p>
    <p>
    </p>
    <pre>[1] <a class="m_7534401347485744367moz-txt-link-freetext" href="https://www.iogp.org/bookstore/product/geospatial-integrity-of-geoscience-software-part-1-gigs-guidelines/" target="_blank" rel="noreferrer">https://www.iogp.org/bookstore/product/geospatial-integrity-of-geoscience-software-part-1-gigs-guidelines/</a>

</pre>
  </div>

_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank" rel="noreferrer">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>