<div dir="ltr">In general, I think the RFC is awesome, suggesting a design that will greatly<br>improve the interoperability (and ubiquity) of geodetic transformations.<br><br>I do, however, worry that we are rapidly entering a complexity level where the<br>code base becomes write-only, or at least alarmingly dependent on a single<br>developer, although a highly competent one, but so much more worrying.<br><br>As we all know geo-programming competence is measured in the proposed SI unit<br>“rouault” - abbreviated Rt. Currently the Rt cannot be expressed based on known<br>physical constants (although this is a matter of active research by leading<br>standards laboratories), so it is tentatively defined by the sample specimen<br>curated by the company Spatialys, and exposed to the world for calibration,<br>through Github.<br><br>Experiments have shown that the combined mass of geo-programming competence in<br>the known universe is less than 2 Rt - and although analysis is ongoing, it is<br>not even known whether geo-programming competence is conserved under state changes.<br><br>Hence, there are good reasons to fear that PROJ, an essential piece of geodetic<br>infrastructure, in a future where Spatialys has lost interest, will have to be<br>maintained by lesser spirits, lacking the mental power to grasp the multifaceted<br>monolith of PROJ source.<br><br>I never fully succeeded in my attempts to restructure the PROJ architecture,<br>before the WKT2 etc. efforts funded through <a href="https://gdalbarn.com/">https://gdalbarn.com/</a> suddenly<br>doubled the size of the source code, introduced SQLite as a direct dependency,<br>and largely rendered my plans obsolete.<br><br>The switch to C++ as primary development language has, however, potentially<br>simplified much of that work, and I still think it will be a good idea to<br>redo the overall architecture of the code base in order to make it maintainable<br>for a group of mental midgets, individually weighing less than 0.01 Rt, rather<br>than the solitary 1.0 Rt mental giant currently doing such remarkable work.<br><br>I am fully aware that obtaining funding for such “invisible” work is very hard,<br>and I am not at all volunteering to do it myself. I do, however, think it is<br>worth giving it a few thoughts directly in the RFC - e.g. by including an<br>explicit list of additional dependencies introduced. If I read the RFC<br>correctly, these include:<br><br>libtiff<br>curl<br>zlib<br><br>But please elaborate on this - and perhaps add a few remarks about potential<br>internal interfaces (i.e. considering the grid handling and grid shift<br>functionality as a kind of server with a minimal interface, which in<br>principle - long term - could reside on a remote machine). Any comment of this<br>kind in the RFC will ease the road forward for architectural restructuring for<br>improved long term (decades, centuries) maintainability.<br><br>One thing I especially worry about is the potential loss of mind share:<br>Up until version 5.0, PROJ depended on the C standard library only, and<br>hence was quite easy to build and contribute to.<br><br>With the increasing build complexity, I fear that less new material (projections<br>and other new operations) will be contributed to PROJ, unless we make it easier<br>to integrate external code seamlessly with the library - a thing that is not<br>easily done with the current static tables of operations.<br><br>The current low level architecture, however, mostly mimics in C the de facto<br>workings of C++ inheritance and virtual functions, so a C++ redo of some low<br>level stuff will potentially simplify a lot of the basic stuff.<br>This is way beyond the scope of this RFC, but please try not to complicate this<br>kind of work unnecessarily.<br><br>Apart from these, possibly unfounded, concerns, I find the RFC tasteful<br>and well balanced.<br><br>I especially enjoy the fact that you dismiss the use of HDF5 (which I consider<br>a horrible reinvention of zip files) and NTv2 (which I consider a horrible, and<br>limited, reinvention of TIFF files).<br><br>When TIFF is what is needed (despite all its arcane monstrosities),<br>TIFF is what we should use. Lets get rid of unnecessary specialized<br>file formats, if TIFF can support all our needs.<br><br>/thomas<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tor. 2. jan. 2020 kl. 14.47 skrev Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
PROJ 6.3 being out, it is time to consider the next steps :-)<br>
<br>
RFC4<br>
<a href="https://github.com/rouault/PROJ/blob/rfc4_remote_and_geotiff_grid/docs/source/community/rfc/rfc-4.rst" rel="noreferrer" target="_blank">https://github.com/rouault/PROJ/blob/rfc4_remote_and_geotiff_grid/docs/source/community/rfc/rfc-4.rst</a><br>
is hopefully now in its final state. Number of changes have been added to it since<br>
the initial version to synchronize it with the implementation, but nothing dramatically different.<br>
You can the diff at <a href="https://github.com/rouault/PROJ/compare/5bbfc07..2b16de3" rel="noreferrer" target="_blank">https://github.com/rouault/PROJ/compare/5bbfc07..2b16de3</a><br>
<br>
It is now backed by a working implementation available at<br>
<a href="https://github.com/OSGeo/PROJ/pull/1817" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ/pull/1817</a><br>
<br>
The CDN, storing grids converted to GeoTIFF, is now available at <a href="https://cdn.proj.org/" rel="noreferrer" target="_blank">https://cdn.proj.org/</a><br>
<br>
As an example, the following will now work (using the OSTN15_NTv2_OSGBtoETRS.tif grid):<br>
<br>
$ echo 60 2 | PROJ_NETWORK=ON cs2cs -d 8 OSGB36 ETRS89<br>
59.99957003     1.99763761 0.00000000<br>
<br>
On next invocations, the parts of the grid that are needed and have already been<br>
queried will be retrieved from the cache (at ~/.local/share/proj/cache.db on Linux)<br>
<br>
For now, the RFC4 implementation works with a grid_alternatives database table still<br>
pointing at the NTv2 & GTX files of <a href="https://github.com/osgeo/proj-datumgrid" rel="noreferrer" target="_blank">https://github.com/osgeo/proj-datumgrid</a> and it will<br>
automagically try to fetch the correspond .tif files from the CDN when they are not locally<br>
available.<br>
<br>
In a next step, we'll also need to decide how/when we switch to<br>
<a href="https://github.com/osgeo/proj-datumgrid-geotiff" rel="noreferrer" target="_blank">https://github.com/osgeo/proj-datumgrid-geotiff</a> (which is the master of <a href="http://cdn.proj.org" rel="noreferrer" target="_blank">cdn.proj.org</a>) and<br>
if we provide a single or multiple packages of it (current total size of files is 486 MB),<br>
and/or a utility to retrieve as a post installation stage grids of interest from a given<br>
bounding box / producer / country from the CDN.<br>
I was initially thinking to a python utility, but there could have<br>
issues with Python dependencies, so perhaps a binary using the new curl dependency would be<br>
easier to deploy & use. This can be for follow-up discussions.<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<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>