[PROJ] Correcting metadata in GeoTIFF files

[Even Rouault]

Le 31/01/2022 à 12:45, Lesparre, Jochem a écrit :
>
> I didn’t realise this, but it seems you are right. It looks like the 
> behaviour of PROJ has changed. Although I like the new order (first 
> vertical then horizontal) better, it is very confusing that this has 
> changed. I wonder if this was a bug, or an intended improvement?
>
I would say this was a case that wasn't taken at all into account during 
initial development since there was no test case in the existing 
regression test suite for it. And it is particularly difficult to model 
PROJ.4 string using +nadgrids and +geoidgrids into ISO-19111 CRS, which 
is the representation model used by the PROJ 6 coordinate transformation 
logic. So I use, or rather abuse/extend, the BoundCRS concept building a 
CompoundCRS of a BoundCRS of the horizontal CRS and a BoundCRS of the 
vertical CRS. But in the PROJ.4 syntax the "pivot" CRS was implicitly 
WGS84, so in those BoundCRS the targetCRS is WGS84. So when you 
transform to EPSG:4937, PROJ also does a WGS84 to ETRS89 transformation, 
which happens to be null luckily. And even if the target of the BoundCRS 
was known to be ETRS89, it is unclear when using such CompoundCRS of 
BoundCRS which order of operation should be applied, even more than the 
concept of interpolation CRS is also absent in the BoundCRS model. so 
all in all, there's little luck of reproducing the PROJ.4 behaviour with 
such CRS object. Or one should take into account the original PROJ.4 
string attached to the CRS and have a special transformation code path 
when detecting it. Given that this is legacy syntax, probably not worth 
the effort.

> So, if we accept the change of behaviour in PROJ >=6, we only need the 
> naptrans2008 and 2018 grids for PROJ <6 users. PROJ >=6 users can use 
> the nlgeo2008 and 2018 grids instead.
>
> > 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 
> <https://secure-web.cisco.com/16SSmij_qIqbZT7vkQpUgv3KX-6ecNxzEzEXIoOqSbC8wsdbTwfrbE_FHii5vpGRXpy7p7mDJPOV9wwZH5frOT8wENoH3KeWcaJNKsvOcWR102emBb5lTF8g_1Uy7RktJ2UUmj3z6nwbZkOZd3WQ6QeCVKSIRuOgLOe2qshPpMN0mjpyNmZCCOtzD-WFnTN9GJpjcLhgy0uPONd4jA9BqtfzV3_rO7ZZlnOt2NVivF9vXtsez9PnwTiLsFYEcz-qUn4KR6xmRX7nIWT4NeqSkOr2Nx-PEGX3Xx45MPDXKpKzAO5l7xVmeKxcee4UBtr2x8EfeJmv6rPQ8qjX_kOFdafhFPEwhG30LbhIKo8taaFs/https%3A%2F%2Fproj.org%2Fspecifications%2Fgeodetictiffgrids.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.
>
> That’s what I was thinking. However, you won’t need a 
> interpolation_crs_wkt=.... in that case, as it would be the same as 
> the GeoTIFF SRS, right?
>
Yes, that was really to make it clear that the GeoTIFF SRS was the 
interpolation CRS, but it could also just be something documented in the 
spec
>
> Since the naptrans2008 and 2018 grids of the Netherlands are the only 
> use case, and these are only needed for PROJ <6, then we might not 
> need GeoTIFFs for these grids, I think. Maybe, this option could be 
> removed entirely?
>
I personally wouldn't mind, but it might potential break users who rely 
on them explictly. Maybe Sebastiaan has some thoughts on that ?

-- 
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/20220131/d211420e/attachment.html>