[PROJ] RFC4: last chance to comment before motion

[Thomas Knudsen]

In general, I think the RFC is awesome, suggesting a design that will
greatly
improve the interoperability (and ubiquity) of geodetic transformations.

I do, however, worry that we are rapidly entering a complexity level where
the
code base becomes write-only, or at least alarmingly dependent on a single
developer, although a highly competent one, but so much more worrying.

As we all know geo-programming competence is measured in the proposed SI
unit
“rouault” - abbreviated Rt. Currently the Rt cannot be expressed based on
known
physical constants (although this is a matter of active research by leading
standards laboratories), so it is tentatively defined by the sample specimen
curated by the company Spatialys, and exposed to the world for calibration,
through Github.

Experiments have shown that the combined mass of geo-programming competence
in
the known universe is less than 2 Rt - and although analysis is ongoing, it
is
not even known whether geo-programming competence is conserved under state
changes.

Hence, there are good reasons to fear that PROJ, an essential piece of
geodetic
infrastructure, in a future where Spatialys has lost interest, will have to
be
maintained by lesser spirits, lacking the mental power to grasp the
multifaceted
monolith of PROJ source.

I never fully succeeded in my attempts to restructure the PROJ architecture,
before the WKT2 etc. efforts funded through https://gdalbarn.com/ suddenly
doubled the size of the source code, introduced SQLite as a direct
dependency,
and largely rendered my plans obsolete.

The switch to C++ as primary development language has, however, potentially
simplified much of that work, and I still think it will be a good idea to
redo the overall architecture of the code base in order to make it
maintainable
for a group of mental midgets, individually weighing less than 0.01 Rt,
rather
than the solitary 1.0 Rt mental giant currently doing such remarkable work.

I am fully aware that obtaining funding for such “invisible” work is very
hard,
and I am not at all volunteering to do it myself. I do, however, think it is
worth giving it a few thoughts directly in the RFC - e.g. by including an
explicit list of additional dependencies introduced. If I read the RFC
correctly, these include:

libtiff
curl
zlib

But please elaborate on this - and perhaps add a few remarks about potential
internal interfaces (i.e. considering the grid handling and grid shift
functionality as a kind of server with a minimal interface, which in
principle - long term - could reside on a remote machine). Any comment of
this
kind in the RFC will ease the road forward for architectural restructuring
for
improved long term (decades, centuries) maintainability.

One thing I especially worry about is the potential loss of mind share:
Up until version 5.0, PROJ depended on the C standard library only, and
hence was quite easy to build and contribute to.

With the increasing build complexity, I fear that less new material
(projections
and other new operations) will be contributed to PROJ, unless we make it
easier
to integrate external code seamlessly with the library - a thing that is not
easily done with the current static tables of operations.

The current low level architecture, however, mostly mimics in C the de facto
workings of C++ inheritance and virtual functions, so a C++ redo of some low
level stuff will potentially simplify a lot of the basic stuff.
This is way beyond the scope of this RFC, but please try not to complicate
this
kind of work unnecessarily.

Apart from these, possibly unfounded, concerns, I find the RFC tasteful
and well balanced.

I especially enjoy the fact that you dismiss the use of HDF5 (which I
consider
a horrible reinvention of zip files) and NTv2 (which I consider a horrible,
and
limited, reinvention of TIFF files).

When TIFF is what is needed (despite all its arcane monstrosities),
TIFF is what we should use. Lets get rid of unnecessary specialized
file formats, if TIFF can support all our needs.

/thomas


Den tor. 2. jan. 2020 kl. 14.47 skrev Even Rouault <
even.rouault at spatialys.com>:

> Hi,
>
> PROJ 6.3 being out, it is time to consider the next steps :-)
>
> RFC4
>
> https://github.com/rouault/PROJ/blob/rfc4_remote_and_geotiff_grid/docs/source/community/rfc/rfc-4.rst
> is hopefully now in its final state. Number of changes have been added to
> it since
> the initial version to synchronize it with the implementation, but nothing
> dramatically different.
> You can the diff at
> https://github.com/rouault/PROJ/compare/5bbfc07..2b16de3
>
> It is now backed by a working implementation available at
> https://github.com/OSGeo/PROJ/pull/1817
>
> The CDN, storing grids converted to GeoTIFF, is now available at
> https://cdn.proj.org/
>
> As an example, the following will now work (using the
> OSTN15_NTv2_OSGBtoETRS.tif grid):
>
> $ echo 60 2 | PROJ_NETWORK=ON cs2cs -d 8 OSGB36 ETRS89
> 59.99957003     1.99763761 0.00000000
>
> On next invocations, the parts of the grid that are needed and have
> already been
> queried will be retrieved from the cache (at ~/.local/share/proj/cache.db
> on Linux)
>
> For now, the RFC4 implementation works with a grid_alternatives database
> table still
> pointing at the NTv2 & GTX files of
> https://github.com/osgeo/proj-datumgrid and it will
> automagically try to fetch the correspond .tif files from the CDN when
> they are not locally
> available.
>
> In a next step, we'll also need to decide how/when we switch to
> https://github.com/osgeo/proj-datumgrid-geotiff (which is the master of
> cdn.proj.org) and
> if we provide a single or multiple packages of it (current total size of
> files is 486 MB),
> and/or a utility to retrieve as a post installation stage grids of
> interest from a given
> bounding box / producer / country from the CDN.
> I was initially thinking to a python utility, but there could have
> issues with Python dependencies, so perhaps a binary using the new curl
> dependency would be
> easier to deploy & use. This can be for follow-up discussions.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200103/157c80ef/attachment.html>