Re: Call for review on RFC 4 text: Remote access to grids and GeoTIFF grids

I do like that it will still default to using local grid files, unless 
the environment variable is set (PROJ_NETWORK=ON).

I would like this RFC to include effort to improve the documentation on 
which grids should be installed (it is very confusing how 
'proj-datumgrid-latest' differs from world, europe, oceania, 
northamerica, I always assume, like many others I bet, that -latest 
includes europe+oceania+northamerica+world).  As a packager for Windows 
users for MS4W, I struggle to verify if I have installed all of the 
proper grids.  I do notice that in March 2018 I "added all datumgrid 
files" for MS4W users (which increased the download size of course, 
which honestly is worth it because most users have no idea that these 
grid files exist and their importance).

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?

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 <[email protected] 
> <mailto:[email protected]>> 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
>     [email protected] <mailto:[email protected]>
>     https://lists.osgeo.org/mailman/listinfo/proj
> 
> 
> 
> -- 
> Andrew Bell
> [email protected] <mailto:[email protected]>
> 

_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj