<div dir="ltr"><div>Hi Martin,</div><div>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). </div><div><br></div><div>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.</div><div><br></div><div>Warm regards, Cameron</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 1 Aug 2019 at 00:43, Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.com">martin.desruisseaux@geomatys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Regards,<br>
</p>
Martin<br>
<pre>[1] <a class="gmail-m_5611201533771671894moz-txt-link-freetext" href="https://www.geomatys.com/en/2017/09/20/proj-4-versus-apache-sis-an-accuracy-comparison-2/" target="_blank">https://www.geomatys.com/en/2017/09/20/proj-4-versus-apache-sis-an-accuracy-comparison-2/</a>
[2] Geospatial Integrity of Geoscience Software (GIGS), Part 1, §3.4
[3] <a class="gmail-m_5611201533771671894moz-txt-link-freetext" href="https://github.com/Esri/ogc-crs-wkt-parser" target="_blank">https://github.com/Esri/ogc-crs-wkt-parser</a>
</pre>
</div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><span style="font-size:12.8px">Cameron Shorter</span><br></div><div>Technology Demystifier</div><div>Open Technologies and Geospatial Consultant</div><div><br></div><div>M +61 (0) 419 142 254</div><div><br></div></div><div><br><br></div></div></div></div></div></div></div></div></div></div>