[PROJ] ct2 format and grid_transformation.sql

[Even Rouault]

On mercredi 16 septembre 2020 15:29:51 CEST Dalia Prizginiene - LMI wrote:
> The new grid ISN93_ISN2016.ct2 is created by us now (better version of
> ISN93_ISN2016.gsb grid). It looks like it is more easier to create ct2
> grids  than gsb grids. But I am wondering is it wise approach.
> 
> So like now I have this ISN93_ISN2016.ct2 grid, I can convert to GTG format,
> and in proj-data will be this new updated ISN93_ISN2016.tiff grid (also in
> grid_alternatives I will introduce GTiff file in the proj_grid_name column)
> , but real concern is about QGIS in datum transformation(from EPSG:3057 to
> EPSG:8086), like now I can see in QGIS the line 
> +proj=pipeline....+grids=ISN93_ISN2016.gsb (but if I introduce new GTiff
> name=ISN93_ISN2016.tiff, will proj line in  QGIS will change to
> +grids=ISN93_ISN2016.tiff  instead of ISN93_ISN2016.gsb?I do not think
> so.). As I know QGIS understands only NTv2 grids, so basically I need to
> have ISN93_ISN2016.gsb file instead of ct2. So for us to go to ct2 format
> is not worth doing that I guess, correct? Because with this ct2 format we
> can somehow bypass in PROJ and GDAL, but not in QGIS. With new package of
> proj >7, QGIS still will use NTv2 format for grids not GTiff. And if we
> want to have  QGIS users, who wants to use grids, we need to provide NTv2
> format for them.

>From a methodology point of view, if you change the content of the ISN93_ISN2016 grid, it 
might be wise to call it ISN93_ISN2016_v2, and register a new transformation at EPSG, that 
will supersede the existing one. This will make tracability a bit better.

Now, if you do that, you may decide either to register a NTv2 grid, or perhaps ask EPSG to 
create a new method for GTG grids. They're aware of the PROJ work on GTG. This shouldn't 
be a problem on their side.

And then you'll add a new record to grid_alternatives to map the EPSG grid name to the 
PROJ one (which may be identical if you register to EPSG the PROJ-data GTG grid)

QGIS doesn't know anything about the format of grids. This is pure black box for it, and it just 
presents to the user the name and link returned by PROJ. With PROJ 7 and PROJ-data, QGIS 
will indirectly use GTG grids through PROJ.

You may use .ct2 as an intermediate step if it is easier for you, but I'd discourage using it for 
publication.

Even

> 
> 
> 
> From: Even Rouault [mailto:even.rouault at spatialys.com]
> Sent: 16. september 2020 11:43
> To: proj at lists.osgeo.org
> Cc: Dalia Prizginiene - LMI <dalia.prizginiene at lmi.is>
> Subject: Re: [PROJ] ct2 format and grid_transformation.sql
> 
> 
> Dalia,
> 
> > I want to be clear on these things:
> > 
> > 
> > 
> > Am I right that ct2 format can not be described in grid_alternatives.sql/
> > 
> > grid_transformation.sql/ grid_transformation_custom.sql, because there is
> > 
> > no EPSG code for ct2 format (NTv2 format (EPSG:9615) and GTX format
> > 
> > (EPSG:9665))?
> > 
> > 
> > 
> > I can only transform ct2 format into GTG and use in proj piplines directly
> > 
> > and also in GDAL but not in transformations where EPSG code is involved,
> > 
> > correct?
> > 
> > 
> > 
> > As today all grids should be in GTG format, but in grid_alternatives.sql/
> > 
> > grid_transformation.sql/ grid_transformation_custom.sql the names of the
> > 
> > grid are with endings .gsb and .gtx, so that mean that where EPSG code is
> > 
> > involved GTG will be transformed back into .gsb or .gtx grid formats to
> > 
> > perform transformation in such an applicatios as QGIS and so on (where
> > proj
> > 
> > is in background and EPSG codes are involved in the transformation),
> > 
> > correct?
> 
> No, if the grid name in EPSG is .gsb or .gtx, and grid_alternatives map it
> to a GTiff file in the proj_grid_name column, then PROJ will use the GTG
> file. (for backward compatibility with older PROJ grid packages, if the GTG
> file is not found, but a .gtx or .gsb filename is present in the
> old_proj_grid_name column, it will be used)
> > From here, I can see that I can convert ct2 format into GTG, but ct2
> > format
> > 
> > grid can not be decribed in grid_alternatives.sql/
> > 
> > grid_transformation.sql/ grid_transformation_custom.sql and can not be
> > used
> > 
> > in transformation involving EPSG codes, correct?
> 
> if you wanted to use a .ct2 file in a custom record of
> "grid_transformation", you could likely abuse the use of the EPSG:9615
> method. I don't think PROJ would mind.
> 
> 
> 
> In PROJ < 7.0, it was possible to register a CTable2 alternative grid name,
> but this has now been removed per the "CONSTRAINT
> check_grid_alternatives_grid_fromat CHECK (proj_grid_format IN ('GTiff',
> 'GTX', 'NTv2'))," because I didn't see any more use of it. You could
> probably add 'CTable2' to that list, if you really wanted, although abusing
> 'NTv2' should be just fine)
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200916/ae0e8cef/attachment-0001.html>