[PROJ] Extent of vertical CRSs
Javier Jimenez Shaw
j1 at jimenezshaw.com
Sun Feb 18 07:51:10 PST 2024
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.
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
Best regards,
Javier
On Sun, 18 Feb 2024 at 14:54, Even Rouault <even.rouault at spatialys.com>
wrote:
> 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
>
> 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 listPROJ at lists.osgeo.orghttps://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/bb6c8f37/attachment.htm>
More information about the PROJ
mailing list