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
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
