Re: Reviews requested: On GDA2020, PROJ 6 and QGIS

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