[PROJ] Early vs Late binding

[Martin Desruisseaux]

Hello Cameron

Le 01/08/2019 à 04:32, Cameron Shorter a écrit :

> 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).
>
> 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.
>
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".

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".

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.

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=/f/(A) where
the /f/ function has been determined by least  squares method. Then we
can express transformation from B to C as C=/g/(B) where the /g/
function has been determined by least squares method too. Finally the
transformation from A to C could be represented by C = /g/(/f/(A)). That
would be identical to a C = /h/(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, /g/(/f/(A)) is not
identical to /h/(A) because the errors were not minimized in the same way.

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.

So in summary:

  * "Early binding" ≈ hub transformation technique.
  * "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.
  * 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).

The solution proposed by ISO 19111 (in my understanding) is:

  * Forget about hub (WGS84 or other), unless the simplicity of
    early-binding is considered more important than accuracy.
  * 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 getCoordinateReferenceSystem()
    method in Geometry objects (for instance) needs to be replaced by a
    getCoordinateMetadata() method.

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).

Regards,

    Martin

[1] https://www.iogp.org/bookstore/product/geospatial-integrity-of-geoscience-software-part-1-gigs-guidelines/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190801/df83b084/attachment-0001.html>