[PROJ] Extent of vertical CRSs

[Even Rouault]

Le 18/02/2024 à 16:51, Javier Jimenez Shaw a écrit :
> Thank you Even. I totally forgot about the transformation area of use. 
> It makes totally sense.
>
> In Japan was considering to change the extent of the PROJ 
> transformation from 3263 to 1129 (I have a branch ready to make a PR). 
> But then I remembered the case of the Spanish islands.
> In Spain, each island has its own vertical CRS, and its 
> transformation. For mainland and Balearic islands, the geoid model 
> file is the same, as you can see in the transformations below. However 
> the area of use of each specific transformation is only that island 
> (or mainland)
> https://epsg.org/transformation_9605/ETRS89-to-ETRS89-Alicante-height-1.html
> https://epsg.org/transformation_9609/ETRS89-to-ETRS89-Menorca-height-1.html
>
> (Back in time, maintaining a vertical reference between islands was, 
> let's say, "complicated". There was no way to connect the levelling 
> networks through the sea. That's why they needed a reference per island)
>
> For Japan I only find one vertical CRS. So I don't know if they want 
> to consider different CRSs for each island. They have tidal data for 
> Okinawa, for example.
> https://www.gsi.go.jp/kanshi/tide_data_21_e.html
> Unfortunately the GSI did not register the transformation, and it was 
> implemented as a PROJ transformation, so we do not know GSI intentions.
>
> In summary, I do not know if I should change the extent of the 
> transformation in Japan or not.
Perhaps you could ask user @tohka with whom we interacted in 
https://github.com/OSGeo/PROJ-data/issues/36 if he can coordinate with 
GSI to have them register the transformation to EPSG?
>
>
> As a fun fact, transforming only to the vertical returns something 
> different than to a compound.
> $ echo 26.328954 127.790975 0 | PROJ_NETWORK=ON cs2cs EPSG:6667 EPSG:6695
> 26.33 127.79 -31.98
> $ echo 26.328954 127.790975 0 | PROJ_NETWORK=ON cs2cs EPSG:6667 
> EPSG:6668+6695
> 26.33 127.79 0.00

The reason is that in the first case there's a direct match between 
EPSG:6667 and EPSG:6695 using the grid, and so only that transformation 
is listed, so it is actually attempted even outside its area of use, 
which is an amendment to my previous theory about the use of extents.... 
So transformation extents are used to determine which one should be used 
when there are alternatives. When there's a single choice, it is 
attempted without extent checks, at least in the generic proj_trans() 
logic. The transformation might fail at a lower stage due to the 
gridshift operation determining that the point is outside of the grid.

In the EPSG:6667 EPSG:6668+6695 case, the transformation is synthesized, 
and so a ballpark one not doing anything is also synthetized, the later 
with a world extent. As the point is outside of the advertized extent 
for the grid based transformation, the ballkpark one is used.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.