[PROJ] Call for review on RFC 4 text: Remote access to grids and GeoTIFF grids

[Nyall Dawson]

On Wed, 27 Nov 2019 at 01:49, Jeff McKenna
<jmckenna at gatewaygeomatics.com> wrote:

> Which brings me to the most important point that I believe is missing in
> the RFC, of notifying the user when a grid file is not leveraged.
> Currently there is no warning, no notice, when a grid is not installed.
> I side with Andrew Bell on his point that during installation I'd like
> to see more messages, notices, or something to install all grid files.
> Could there be a build option of "TEST_ALL_DATUMGRID_FILES" during PROJ
> compilation?

Doesn't responsibility for implementing this warning lie with the
client application? Every application will need to handle this
differently, e.g. in QGIS we implemented a giant warning alert when a
more accurate transformation is possible but can't be used due to
missing grid files (along with a gui based approach to allow users to
download and install these files). But obviously for mapserver this
would need to be handled quite differently (with a big warning in a
log file?). And an application like a R library would also need a
different approach to warning users of this situation too....

FWIW, the code in QGIS which handles this starts at
https://github.com/qgis/QGIS/blob/master/src/core/qgscoordinatetransform_p.cpp#L380

Nyall



>
> I thank Even, Howard, Kristian, all, for pushing PROJ forward.
>
> -jeff
>
>
>
> --
> Jeff McKenna
> MapServer Consulting and Training Services
> https://gatewaygeomatics.com/
>
>
>
> On 2019-11-26 9:54 AM, Andrew Bell wrote:
> > I wouldn't be true to form if I didn't express some skepticism in the
> > value of this change.
> >
> > I don't quite understand the environment in which one would care about
> > 700MB of data.  We live in an age where it's difficult to purchase a
> > storage device as small as 500GB, so minimizing an installation
> > footprint to avoid 700MB of data strikes me as a bit silly, especially
> > when PROJ has recently added a requirement for sqlite3.  If the issue is
> > one of packaging, it seems that there are other alternatives to a
> > "fancy" solution like this.  Could not the PROJ installation simply
> > download the files from some known source?  I'm sure there are other
> > options as well.  Dynamic fetching of data seems natural these days, but
> > it's non-trivial.  Failures can occur at many levels and these either
> > need handling in the source code or errors may be transferred to users
> > who may well scratch their heads about what's *not* working properly.
> > Personally, I'd much rather have a failure/problem at installation-time
> > than a run-time failure.  PROJ is, in my mind, a core library for many
> > users.  It should be as robust as possible.  To meet that goal requires
> > careful code.  Extra features require more code, which requires more
> > maintenance, review and necessarily increases the likelihood of bugs.
> > Current maintainers may have time and expertise to add this enhancement,
> > but it's not clear to me that it's in the long-term best interest of the
> > basic functionality of the library.
> >
> > On Mon, Nov 25, 2019 at 7:46 AM Even Rouault <even.rouault at spatialys.com
> > <mailto:even.rouault at spatialys.com>> wrote:
> >
> >     Hi,
> >
> >     As announced last week, you'll find a RFC describing two new
> >     capabilities,
> >     remote access to grids and a GeoTIFF-based format for grids, in
> >     https://github.com/OSGeo/PROJ/pull/1747
> >
> >     You can get an (almost correct) preview of it by going through
> >     https://github.com/rouault/PROJ/blob/rfc4_remote_and_geotiff_grid/docs/source/community/rfc/rfc-4.rst
> >     (some links will not work in this preview: expected given that this
> >     rendering doesn't go through Sphinx)
> >
> >     Even
> >
> >     --
> >     Spatialys - Geospatial professional services
> >     http://www.spatialys.com
> >     _______________________________________________
> >     PROJ mailing list
> >     PROJ at lists.osgeo.org <mailto:PROJ at lists.osgeo.org>
> >     https://lists.osgeo.org/mailman/listinfo/proj
> >
> >
> >
> > --
> > Andrew Bell
> > andrew.bell.ia at gmail.com <mailto:andrew.bell.ia at gmail.com>
> >
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj