[PROJ] Extent of vertical CRSs

[Even Rouault]

Hi Javier,

More exactly, PROJ only uses the extent of the source and target CRS, 
combined with the extent of the transformation, to *sort* potential 
transformations. To *use* transformations, PROJ doesn't rely on the CRS 
extent, just the transformation extent. The later comes directly from 
the database for a transformation with a direct match, or which is 
computed by intersecting the extent of each individual coordinate 
operations when synthesizing a concatenated operation. For example if 
you update proj.db with "update usage set extent_code = 1262 where 
object_table_name = 'grid_transformation' and object_auth_name='EPSG' 
and object_code='7959' which modifies the area of use of "ETRS89 to 
Malin Head height (2)" to be worldwide, then PROJ will try to use the 
uk_os_OSGM15_Malin.tif to use for any input coordinate (and will 
obviously fail if they fall outside of the TIFF grid extent)

PROJ only relies on the extents from the database to determine if it can 
use a coordinate operation, rather than checking the extent of the grid 
itself from the GeoTIFF/NTV2/etc. file. The main reason is for 
performance: if your grids are remote, then it would just kill 
performance if we had to open potentially tens of remote files. Another 
reason is that the actual extent of the grid might be larger than its 
intended area of use, because I believe sometimes models rely on some 
boundary conditions and grid creators have to put some values beyond the 
actual surveyed area, but such extensions probably have a much lower 
accuracy. That said... given that we only take into account the bounding 
box of the area of use, and not the polygonal shape, we may already use 
grid points that are outside the intended area of use.

If we don't have direct contacts with producers, we can probably just 
issue a change request or question through 
https://epsg.org/dataset-change-requests.html. I assume IOGP must be 
able to reach back to the original data submitter if needed.

Even

Le 18/02/2024 à 11:39, Javier Jimenez Shaw via PROJ a écrit :
> Hi
>
> Recently I found some vertical systems that do not cover properly the 
> entire area they "should" cover (a country usually) but that their 
> geoid models do.
>
> One example I already posted here was in Canada for 
> https://epsg.org/crs_5713/CGVD28-height.html We contacted them (thanks 
> Even) and they will update EPSG and ISO databases to cover 
> Newfoundland. 
> https://lists.osgeo.org/pipermail/proj/2023-December/011203.html
>
> But I found more examples:
>
> This example from Switzerland for 
> https://epsg.org/crs_5729/LHN95-height.html is not as significan (just 
> a few hundred meters, but it surprising how they missed it in 3 of 4 
> sides)
> You can see them in this mini-GIS link (Just click the "squares" to 
> fit to each "outlier" bounds)
>
> https://javier.jimenezshaw.com/mapas/?name=st&c=46.7511530,8.6243091&z=8&f=xtra1&b=osm&v=1&e=1&o=100&ed=1&m=&extra_name=swisstopo&extra_url=https%3A%2F%2Fwmts100.geo.admin.ch%2F1.0.0%2Fch.swisstopo.pixelkarte-farbe%2Fdefault%2Fcurrent%2F3857%2F%7Bz%7D%2F%7Bx%7D%2F%7By%7D.jpeg&d7=7mnpck,zgn5v,West,8,008000,3;0,snb&d7=7kse2q,1hopil,South,8,800080,3;f06,-hw&d7=7pjafh,1qgtba,East,8,ff00ff,3;-6k,-fzs&y7=7wncbk,zhfnk,Extent%20EPSG%3A1286,8,ff0000,3;-buixs,0;0,qyxpc;buixs,0&y7=7mo4q6,zheng,West,8,ffa500,3;-wle,bx;-9r7,-k1b;1u4,-2zb;rbd,-7m8;je8,ust&y7=7kspwk,1hmppz,South,8,000080,3;38c,-g9y;-20,2yab;-45l,-9rq;-adz,-2zb;-gm,-ijo;7pz,-lh6;5dl,-nn5&y7=7pj8of,1qgdhh,East,8,a68c2b,3;ka,ckf;198,387;-izq,lh;-ciw,-6n0;-6dc,-9lr&ga=0 
> <https://javier.jimenezshaw.com/mapas/?name=st&c=46.7511530,8.6243091&z=8&f=xtra1&b=osm&v=1&e=1&o=100&ed=1&m=&extra_name=swisstopo&extra_url=https%3A%2F%2Fwmts100.geo.admin.ch%2F1.0.0%2Fch.swisstopo.pixelkarte-farbe%2Fdefault%2Fcurrent%2F3857%2F%7Bz%7D%2F%7Bx%7D%2F%7By%7D.jpeg&d7=7mnpck,zgn5v,West,8,008000,3;0,snb&d7=7kse2q,1hopil,South,8,800080,3;f06,-hw&d7=7pjafh,1qgtba,East,8,ff00ff,3;-6k,-fzs&y7=7wncbk,zhfnk,Extent%20EPSG%3A1286,8,ff0000,3;-buixs,0;0,qyxpc;buixs,0&y7=7mo4q6,zheng,West,8,ffa500,3;-wle,bx;-9r7,-k1b;1u4,-2zb;rbd,-7m8;je8,ust&y7=7kspwk,1hmppz,South,8,000080,3;38c,-g9y;-20,2yab;-45l,-9rq;-adz,-2zb;-gm,-ijo;7pz,-lh6;5dl,-nn5&y7=7pj8of,1qgdhh,East,8,a68c2b,3;ka,ckf;198,387;-izq,lh;-ciw,-6n0;-6dc,-9lr&ga=0>
>
> Another example is Japan with 
> https://epsg.org/crs_6695/JGD2011-vertical-height.html that does not 
> include the island of Okinawa (among others), that is covered by the 
> geoid model in PROJ-data. (here the distance is big. I didn't know 
> that Japan reached 24 deg latitude)
>
> In Ireland they leave some islands out of 
> https://epsg.org/crs_5731/Malin-Head-height.html in the west, like 
> Munster, also covered by OGM15_Malin tiff file.
>
> *The problem* is that PROJ is not using the geoid model out of the 
> area of use of the vertical CRS.
>
> One option is to contact the agencies to correct their area of use in 
> EPSG (does anybody know how to contact Swiss, Japanese or Irish 
> agencies in this case?). I have seen many EPSG updates that are just 
> increasing 0.01 deg an extent.
>
> Would it make sense to be more flexible on the vertical 
> transformations? Just contacting the local agencies is enough?
>
> Cheers,
> Javier.
>
> PS I am surprised that some countries do not pay more attention to the 
> extent of their countries. I thought it was a geopolitical topic.
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
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/20240218/d8d2c356/attachment.htm>