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

[Even Rouault]

Andrew,

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

The motivation part of the RFC addresses this. Not sure I have more to add. 
Server-less computing is probably the use case for which this new 
functionality will shine most. For a short term process, you probably don't 
want to start by downloading hundreds of megabytes of grids to reproject a 
handful of points whereas in practice you just needed 4 points in a grid.

I've just had a chat with Jürgen Fischer who has the burden to package QGIS. 
It appears that the Win32 QGIS standalone installer only bundles the main 
proj-datumgrid package, the proj-datumgrid-oceania package and one German 
grid. So no -europe, -north-america or -world. They are concerned by file 
size, because of a 2GB NSIS limit. So while in theory we live in an era of big 
unlimited data, we can still be stuck by old limitations :-)

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

Some retry strategy in case of temporary network/server failure will probably 
be needed. There is that in GDAL /vsicurl/

> Personally, I'd much rather have a
> failure/problem at installation-time than a run-time failure. 

The option to use "static" grids will remain. The use case with no network 
connectivity is a valid one.

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

That's very true !
1) if the feature is useless, and its maintainance becomes a problem, it can 
be decided to rip it off. See the proposal for removal of this obscure 
+catalog in the RFC.
2) if the feature is useful and not working properly, people will complain at 
first it is no longer working. But if they are really dependent on it, they 
will end up help maintaining it. If they don't, go back to 1.

PROJ has ~ 150 projection methods. Probably 10% only of them are used for 99% 
of the use cases. I'm pretty sure most of us (well, speaking about me at 
least) have no idea how to fix potential bugs in the exotic 90% ones. If 
people care about them, they'll read the papers, scratch their heads heavily 
and propose a PR.

PROJ was at the origin 100% about projection methods. Now the projection code 
is only one third of the total code base. So focus moves with time. No idea 
what it will be in 10 years.

Even

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