[PROJ] Correcting metadata in GeoTIFF files

[Even Rouault]

Le 28/01/2022 à 13:08, Lesparre, Jochem a écrit :
>
> Hi Even,
>
> Thanks for the quick and clear reply. I now found the description for 
> this use case at proj.org, which explicitly mentions the naptrans grid 
> of the Netherlands as example (sorry for not RTFM). I have some 
> remaining questions, though:
>
>   * Why is this use case not more common? This [1] was the standard
>     way to get a transformation to a national compound CRS in PROJ4,
>     right?
>
Looking at the 'epsg' file that was delivered in PROJ < 6, there's no 
single entry having both +nadgrids and +geoidgrids in it. I'm not 
completely sure if the fact that the order of those operations was the 
one you expected was a design decision or just the result of a 50% 50% 
dice throw.

Hum but now I'm lost, if doing EPSG:4937 to "+proj=sterea 
+lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 
+y_0=463000 +ellps=bessel +nadgrids=rdtrans2018.gsb +units=m 
+geoidgrids=naptrans2018.gtx +vunits=m +no_defs"

- with recent PROJ, it  does ... +step +inv +proj=vgridshift 
+grids=naptrans2018.gtx +multiplier=1  +step +inv +proj=hgridshift 
+grids=nl_nsgi_rdtrans2018.tif , so vertical adjustment then horizontal

- but my understanding of the PROJ <6 code is that it does in the 
reverse order.

playing with cs2cs & cct, I can actually confirm this. There's a 
difference in vertical values of the order of a few millimeters, whereas 
if I modify the pipeline to do horizontal then vertical, I get the PROJ 
< 6 results with a sub-millimeter precision. Who is right, who is 
wrong:  I give up. At that point we probably just need to accept the 
discrepancy as nobody raised it. Bottom line: use cct instead of cs2cs 
to unambiguously control the order of operations.

Actually I found an older thread about that : 
https://lists.osgeo.org/pipermail/proj/2019-May/008526.html and it 
already gave me tons of headaches...

using the EPSG:7415 code gives the expected result (but I now see that 
it is because it uses the nlgeo2018 grid)

$ echo 53 6 0 | PROJ_NETWORK=ON PROJ_LIB=data bin/cs2cs -f "%.4f" 
EPSG:4937 EPSG:7415
196139.4316    557179.0261 -41.6949

whereas using the PROJ.4 string for EPSG:7415 results (in PROJ >= 6) in 
the reverse order for horizontal & vertical adjustments

$ echo 53 6 0 | PROJ_NETWORK=ON PROJ_LIB=data bin/cs2cs -f "%.4f" 
EPSG:4937 +to "+proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 
+k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel 
+nadgrids=rdtrans2018.gsb +units=m +geoidgrids=naptrans2018.gtx 
+vunits=m +no_defs +type=crs"
196139.4316    557179.0261 -41.6982

>   * Since the CRS of the GeoTIFF is the source-crs [2], does this mean
>     that other software will would show the grid values at the latlon
>     of the source-crs instead of at the latlon of the interpolation-crs?
>
On reflection, it might be better to have the GeoTIFF SRS be the 
interpolation CRS (like in the VERTICAL_TO_VERTICAL case, but in that 
case there's no other sane choice), an explicit source_crs_code=7931 and 
interpolation_crs_wkt=....    The 
https://proj.org/specifications/geodetictiffgrids.html page should be 
amended to document that, and the validation script too.  And perhaps 
the conversion script too if that's thought to be a not-so-rare use case.
>
>  *
>
>
> Additional question on names and aliases:
>
>   * For EPSG:4289, the EPSG registry uses the name “Amersfoort”.
>     However, we (the official authority of this CRS) never use this
>     name. Since the name “Amersfoort” has been in EPSG for a long
>     time, EPSG preferred not to correct this, but to add the official
>     name “RD Bessel” as an alias in the EPSG registry. Can I use the
>     official alias “RD Bessel” instead of the EPSG name “Amersfoort”
>     for the WKT strings and/or the description in the metadata of the
>     Geodetic TIFF Grids?
>
I guess that's OK, adding just a bit more confusion to an already super 
confusing topic

Note: I'm not sure if it is a formatting issue when writing the email, 
but the value of the interpolation_crs_wkt item is wrong as it lacks 
double quoting around strings.


-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220128/50bc6991/attachment.html>