[PROJ] RFC4: last chance to comment before motion

[Howard Butler]

> On Jan 3, 2020, at 10:35 AM, Thomas Knudsen <knudsen.thomas at gmail.com> wrote:
> 
> 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.
> 

...

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

GDALBarn and the efforts of this RFC are attempts to explicitly fund invisible infrastructure work. By definition, infrastructure work effects everyone because all our software drives over these rails, bridges, and stations. We have taken care to organize the activities so it isn't a decade-long miasma of transition like Python 3, but there is still going to be a little transition pain. Most of that user-inflicted transition pain appears to be centered around the deficiencies of proj4 definitions and rectifying sins of the past in regard to those. Affected projects are going to have to take their medicine in regards to that, in exchange for now being able to communicate WKTv2 descriptions with more than a single software library. Even has also done a lot to try to soften its bitterness, but it is still there and a consequence of PROJ transitioning to a fully-featured geodetic transformation library.

> libtiff
> curl
> zlib

libtiff, curl, and zlib all have operational lifetimes that will be equivalent or longer than PROJ. PROJ is over 35 years old. Just about every attempt to retire PROJ has resulted in a fork that is out-of-date and stale in some way. The required additional support libraries of zlib and libtiff have equivalents or cross-compiled versions in alternative execution runtimes such as Javascript or Java. 

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

I disagree that PROJ was ever easy to contribute to. It has always been a specialists' library that required someone with significant math abilities, experience with preprocessor macro torture, and comfort with C conventions of the 1980s. The size of population that those skills was a lot less than your Rt constant for a lot of years. The work that you and Kristian put in for PROJ 5.0 to step away from those requirements is what has enabled Even's development to happen. In a sense, this is all your fault ;)

Your PROJ 5.0 efforts definitively changed the thesis statement of PROJ from a "a library of cartographic reprojection operations" to "a library of cartographic reprojection operations with a geodetic transformation engine". The follow-ons of WKTv2 support (aligning and leading with the standards of the community) and grids/CDN (getting ahead of a challenging support data issue) are both in support of the latter addition to PROJ's thesis statement. Geodetic transformation engines require the ability to communicate transformation operations and they require support data to apply models to data. Without either, they are broken. 

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

We can make it easier to contribute these kinds of things with documentation, examples, and workflow that help a contributor with passing familiarity with the library add their new methods in a modular way. We are missing this kind of bootstrapping documentation.

Howard