[PROJ] Correcting metadata in GeoTIFF files

[Even Rouault]

Le 26/01/2022 à 20:54, Lesparre, Jochem a écrit :
>
> Hi Even,
>
> Thanks again for your quick reply, but I think you misunderstood the 
> problem I tried to describe in my last email. I’ll try to explain our 
> problem a bit more comprehensive:
>
> We distribute two grid files for the quasi-geoid of the Netherlands: 
> NLGEO2018 and NAPTRANS2018. Both expect ETRS89 (EPSG:4937) ellipsoidal 
> height as input and give the same NAP national levelling system height 
> (EPSG:5709) as output. However, the latlon coordinates of NLGEO2018 
> are in ETRS89 and the latlon coordinates of NAPTRANS2018 are in the 
> national triangulation system “Amersfoort” (EPSG:4289). We prefer the 
> use of the NLGEO2018. We supply NAPTRANS2018 only because this is the 
> type of VDatum grid file that was needed for 3D transformation with 
> PROJ4 (see [1] in my previous email).
>
ok got it
>
> Creating a Geodetic TIFF Grid file for NLGEO2018 is straight-forward 
> [A]. However, I can’t create a Geodetic TIFF Grid file for NAPTRANS2018.
>

> If I use GEOGRAPHIC_TO_VERTICALthe --interpolation-crsis ignored [B].
>
Yes, this is indeed ignored. That type is modeled from the EPSG 
corresponding transformation method "Geographic3D to 
GravityRelatedHeight", and it doesn't accept an interpolation CRS. Your 
best option is to use gdal_translate -mo interpolation_crs_wkt=.... to 
add it


> If I use VERTICAL_TO_VERTICAL, I get AssertionErrordue to the use of a 
> 3D instead of a vertical --source-crs[C].
>
Using VERTICAL_TO_VERTICAL is definitely not appropriate for your use case.


-- 
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/20220126/67c13693/attachment.html>