[PROJ] Switch to proj-datumgrid-geotiff for PROJ 7 ?

[Nyall Dawson]

On Wed, 15 Jan 2020 at 05:28, Even Rouault <even.rouault at spatialys.com> wrote:
>
> > > It would probably be cleaner to avoid this patching and having
> > > grid_alternatives directly point to .tif files. This would also enable us
> > > to put https://github.com/osgeo/proj-datumgrid in a pure maintainance
> > > state and just make https://github.com/osgeo/proj-datumgrid-geotiff the
> > > new home for grids (currently the later has to be resynchronized with the
> > > former)
> > Possibly QGIS is a bit of an outlier in terms of Proj clients, but
> > this change **would** impact us. Not in a major way, but in the order
> > of 2-3 hours work to rectify (and even MORE proj version #ifdefs in
> > the code! Woohoo!). If the intention is to make this an api break
> > (given that it's v7), then that's fine, but if you're intending for
> > this change to be transparent to clients just be aware that it isn't!
>
> Maybe I've missed something or wasn't clear, but I don't see this is as an API
> break (as in C API). I can imagine some effect on test suites that would test
> that the PROJ pipeline from A to B would return a foo.gsb filename, and now
> that would be foo.tif, but not on the production code itself.
> The impact as I see it would be more on the packaging side (grab the proj-
> datumgrid-geotiff.zip )

It's not a c api break - but it still does change things for clients
which were previously coded to use downloads from
https://github.com/osgeo/proj-datumgrid and which have code which
handles .gsb files manually (such as installing them after downloading
the grid referenced by proj)

Nyall


>
> >> One potential issue with switching to GeoTIFF files is for people having
> >> pipeline strings using the current grid names in them. But similarly to
> what
> >> is currently done for remote access, for local access, if we fail to find a
> >> .gtx/.gsb file, we could just retry with the .tif extension.
>
> > This would be a necessity for QGIS, otherwise existing projects will
> > break and reproject differently upon loading in a build based on the
> > newer PROJ version. (I suspect R would also see this as a necessity to
> > avoid changing end user's existing results)
>
> Yes, that would be definitely something to do to make the transition smoother.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com