<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">
<p>Hello Cameron</p>
<p>Le 01/08/2019 à 04:32, Cameron Shorter a écrit :</p>
</div>
<blockquote type="cite"
cite="mid:CABqeU+i32PrydoB8Rnd=ZUkqJcfhb_8DNEc-AbW=dv4hLM5zCA@mail.gmail.com">
<p>
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
</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="moz-txt-link-freetext" href="https://www.iogp.org/bookstore/product/geospatial-integrity-of-geoscience-software-part-1-gigs-guidelines/">https://www.iogp.org/bookstore/product/geospatial-integrity-of-geoscience-software-part-1-gigs-guidelines/</a>
</pre>
</body>
</html>