[PROJ] RFC4: last chance to comment before motion

[Even Rouault]

Thomas,

> 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.

Looking back at the history of PROJ, pretty much the same could be said for 
the long time one-man shows of Jerry Evenden and then Frank Warmerdam :-) And 
we're still hacking into it.

To be honest, the monstruous part I contributed is what I documented in
https://proj.org/operations/operations_computation.html . This *is* 
complicated logic (but most of it is due to the reality of geodetic concept 
and database modelling). No idea how I'd rewrite that in a simpler way while 
keeping the same level of functionality... The rest of the gdalbarn stuff 
should be mostly straightforward for anyone familiar with the underlying 
standards (OGC abstract topic 2/ISO19111 & WKT CRS) and with some knowledge of 
C++.

> I read the RFC correctly, these include:
> 
> libtiff
> curl
> zlib

Yes. But zlib only as an indirect dependency of libtiff.

> 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.

I believe this RFC is already long enough to add details about internal 
interfaces into it. But I'd welcome reviews of the pull requests sitting at
https://github.com/OSGeo/PROJ/pulls to potentially improve the code, and add 
comments where reviewers feel it is needed. That's the best way actually for 
other contributors to get familiar with the added code and avoid my write-only 
type of contributions :-)

> With the increasing build complexity, I fear that less new material
> (projections
> and other new operations) will be contributed to PROJ

I've an action item to write a build howto. Most of the material is actually 
in https://github.com/OSGeo/PROJ/issues/1776#issuecomment-570060704

> 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.

The existing architecture of how operations are integrated is completely 
unrelated to this RFC, so I didn't "complicate" that part at least :-). That 
said, "even if it is in C", it isn't that bad & complicated. Personnaly, I 
wouldn't revisite the way the > 100 operations are implemented just for the 
sake of a C++-ification. But rather for a good reason, like perhaps 
propagating accuracy information along a pipeline, or having operations 
dynamically document their parameters, or be GPGPU / SIMD friendly, etc...

> 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.

The RFC doesn't drop support for the existing file formats (except the old, 
historic and completely broken CTable(1) format. CTable2 is still there). 
There are a lot of NTv2 grids in the wild, it is the de-facto standard used 
currently by most producers of horizontal shift grids, so removing support for 
it is going to take time. And that would be just about removing about 200 
lines of code, so there's no pressing need to do so. We might consider that 
when >90% of producers of geodetic adjustment datasets use TIFF :-)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com