Re: Early vs Late binding

Hi Martin,
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.

Warm regards, Cameron

On Thu, 1 Aug 2019 at 00:43, Martin Desruisseaux <
[email protected]> wrote:

> I would like to bring a little bit of additional context. This is not a
> request to modify the document, only a point of view from outside the PROJ
> community.
>
> While the Australian CRS are good examples of "static versus dynamic
> datum" and "early-binding versus late-binding implementations" problems,
> those problems existed long before. I mentioned in a previous post [1] the
> example of transformation from Martinique 1938 (EPSG:4625) to RGAF09
> (EPSG:5489), which can not be represented accurately in "early-binding"
> implementations like PROJ 4. Other examples exist in Chile and Japan.
> Improving the accuracy of those transformations involve two parts: the
> introduction of dynamic datum, and the use of "late-binding" technique in
> software. Dynamic datum is a recent addition in OGC/ISO standards, but the
> "late-binding" technique is known for a long time. It was explicitly
> recommended by OGP in 2011 [2] and enabled in OGC standards since 2001
> (admittedly in a way that coexisted with early-binding until 2007).
>
> So the need for "late-binding" approach was known for a long time. It is
> implemented in GeoTools (and later Apache SIS) for 15 years. What is recent
> is the publicity that this issue got thanks to PROJ 6 upgrade. But before
> this very welcome effort, I had trouble to convince peoples in FOSS4G or
> other events that PROJ 4 early-binding approach was an issue. Because PROJ
> is the most popular open-source referencing library, it tends to be
> considered as a de-facto standard and that if a referencing feature is not
> supported by PROJ, it probably means that this feature is not worthy.
>
> A consequence of PROJ position is that PROJ action (or inaction) impacts a
> community much larger than the PROJ ecosystem. For example ESRI were the
> first to implement WKT 2 in an open-source prototype [3] (I have been told
> that they now have their own referencing engine in replacement of PROJ). If
> I understood correctly, ESRI has WKT2-ready products for a few years but
> had hesitations to activate that feature because of its incompatibility
> with GDAL-based software. They were discussions in OGC meetings saying that
> even for a vendor as big as ESRI, moving to WKT 2 before PROJ is risky
> because they would probably get feedback from some users claiming that the
> new products are broken because QGIS can not read their files. In my
> understanding, unblocking that situation was part of the motivations for
> some gdalbarn sponsors.
>
> Today PROJ 6 may be the most advanced open-source referencing library
> (Apache SIS does not yet support dynamic datum). But it is unclear if the
> previous situation, where progress in referencing services have been
> impeded by PROJ 4 widespread position, could happen again in the future.
> Some techniques exist for reducing vendor-locking for applications that
> depend on a referencing library. WKT 2 will hopefully be a great help, but
> another technique could be a clear separation between API and
> implementation. Such separation is familiar to Java developers through Java
> interfaces, but seems more unfamiliar in C/C++ world were APIs seem more
> often defined by implementations. I understand that there is few incentive
> from a PROJ community point of view to enable more
> implementation-independence on API side, but I just wanted to point out
> that PROJ influence goes beyond the PROJ community and that it is possible
> to increase the chances to keep this influence more positive (compared to
> PROJ 4) in the future.
>
> Regards,
>     Martin
>
> [1] https://www.geomatys.com/en/2017/09/20/proj-4-versus-apache-sis-an-accuracy-comparison-2/
> [2] Geospatial Integrity of Geoscience Software (GIGS), Part 1, §3.4
> [3] https://github.com/Esri/ogc-crs-wkt-parser
>
> _______________________________________________
> PROJ mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/proj
>


-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

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