<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Javier,</p>
<p>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)</p>
<p>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.</p>
<p>If we don't have direct contacts with producers, we can probably
just issue a change request or question through
<a class="moz-txt-link-freetext" href="https://epsg.org/dataset-change-requests.html">https://epsg.org/dataset-change-requests.html</a>. I assume IOGP must
be able to reach back to the original data submitter if needed.</p>
<p>Even</p>
<div class="moz-cite-prefix">Le 18/02/2024 à 11:39, Javier Jimenez
Shaw via PROJ a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CADRrdKvWzw1vMxLoJybGzD+va=mH3UKjX_vJXUOy7PJuky4J0A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>One example I already posted here was in Canada for <a
href="https://epsg.org/crs_5713/CGVD28-height.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://epsg.org/crs_5713/CGVD28-height.html</a>
We contacted them (thanks Even) and they will update EPSG and
ISO databases to cover Newfoundland. <a
href="https://lists.osgeo.org/pipermail/proj/2023-December/011203.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.osgeo.org/pipermail/proj/2023-December/011203.html</a></div>
<div><br>
</div>
<div>But I found more examples:<br>
</div>
<div><br>
</div>
<div>This example from Switzerland for <a
href="https://epsg.org/crs_5729/LHN95-height.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://epsg.org/crs_5729/LHN95-height.html</a>
is not as significan (just a few hundred meters, but it
surprising how they missed it in 3 of 4 sides)</div>
<div>You can see them in this mini-GIS link (Just click the
"squares" to fit to each "outlier" bounds)</div>
<div><br>
</div>
<div><a
href="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"
moz-do-not-send="true">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</a></div>
<div><br>
</div>
<div>Another example is Japan with <a
href="https://epsg.org/crs_6695/JGD2011-vertical-height.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://epsg.org/crs_6695/JGD2011-vertical-height.html</a>
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)<br>
</div>
<div><br>
</div>
<div>In Ireland they leave some islands out of <a
href="https://epsg.org/crs_5731/Malin-Head-height.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://epsg.org/crs_5731/Malin-Head-height.html</a>
in the west, like Munster, also covered by OGM15_Malin tiff
file.<br>
</div>
<div><br>
</div>
<div><b>The problem</b> is that PROJ is not using the geoid
model out of the area of use of the vertical CRS.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Would it make sense to be more flexible on the vertical
transformations? Just contacting the local agencies is enough?<br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Javier.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div>
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ...
.... ._ .__</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
PROJ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>