Re: Early vs Late binding

Thank you Martin.

I now understand the reason for PROJ 6!

Your example is worth a thousand words!

Ron
--
Ron Russell, from my Mobile Phone

On Thu, 1 Aug 2019, 08:01 Martin Desruisseaux, <
[email protected]> wrote:

> 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/
>
> _______________________________________________
> PROJ mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/proj
>

_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj