<div dir="ltr"><div>Thank you Even. I totally forgot about the transformation area of use. It makes totally sense.</div><div><br></div><div>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.</div><div>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)<br></div><div><a href="https://epsg.org/transformation_9605/ETRS89-to-ETRS89-Alicante-height-1.html">https://epsg.org/transformation_9605/ETRS89-to-ETRS89-Alicante-height-1.html</a></div><div><a href="https://epsg.org/transformation_9609/ETRS89-to-ETRS89-Menorca-height-1.html">https://epsg.org/transformation_9609/ETRS89-to-ETRS89-Menorca-height-1.html</a></div><div><br></div><div><div>(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)<br></div><div><br></div></div><div>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.<br></div><div><a href="https://www.gsi.go.jp/kanshi/tide_data_21_e.html">https://www.gsi.go.jp/kanshi/tide_data_21_e.html</a></div><div>Unfortunately the GSI did not register the transformation, and it was implemented as a PROJ transformation, so we do not know GSI intentions.</div><div><br></div><div>In summary, I do not know if I should change the extent of the transformation in Japan or not.<br></div><div><br></div><br><div>As a fun fact, transforming only to the vertical returns something different than to a compound.<br></div><div>$ echo 26.328954 127.790975 0 | PROJ_NETWORK=ON cs2cs EPSG:6667 EPSG:6695<br>26.33 127.79 -31.98<br>$ echo 26.328954 127.790975 0 | PROJ_NETWORK=ON cs2cs EPSG:6667 EPSG:6668+6695<br>26.33 127.79 0.00</div><div><br></div><div>Best regards,</div><div>Javier<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 18 Feb 2024 at 14:54, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<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 href="https://epsg.org/dataset-change-requests.html" target="_blank">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>Le 18/02/2024 à 11:39, Javier Jimenez
Shaw via PROJ a écrit :<br>
</div>
<blockquote type="cite">
<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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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">
<div dir="ltr">
<div>.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ...
.... ._ .__</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
PROJ mailing list
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote></div>