[PROJ] Problems with CGVD28 height

[Erixen Cruz]

You can edit your proj.db to have a more appropriate extent for the CRS so that it applies to points outside of it right now. I use sqlitebrowser to poke around proj.db. I would create a new extent with the enlarged rectangle, and then change CVGD28 to use that extent. You may have to make a copy of the vertical_crs, usage, and datum rows of the CRS as well. So like a whole new set of rows with EPSG:5713_ENLARGED.

Then just make sure your PROJ_DATA points to your modified proj.db and you can use EPSG:5713_ENLARGED instead. In the mean time, maybe let the appropriate government agency know that they have too small an extent published in EPSG so that it can be revised in next release.

Sincerely, Erixen
________________________________
From: PROJ <proj-bounces at lists.osgeo.org> on behalf of Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org>
Sent: Thursday, December 21, 2023 4:48:30 AM
To: proj <PROJ at lists.osgeo.org>
Subject: Re: [PROJ] Problems with CGVD28 height

Using the option "--bbox", if I have done correctly, I get this

PROJ_NETWORK=ON projinfo -s EPSG:4979 -t EPSG:32181+5713 -o proj --spatial-test intersects --bbox '-53.6,47.7,-53.5,47.8'
Candidate operations found: 2
-------------------------------------
Operation No. 1:

unknown id, Inverse of Transformation from CGVD28 height to WGS 84 (ballpark vertical transformation, without ellipsoid height to vertical height correction) + Inverse of NAD83 to WGS 84 (1) + MTM zone 1, unknown accuracy, North America - onshore and offshore: Canada - Alberta; British Columbia; Manitoba; New Brunswick; Newfoundland and Labrador; Northwest Territories; Nova Scotia; Nunavut; Ontario; Prince Edward Island; Quebec; Saskatchewan; Yukon. United States (USA) - Alabama; Alaska (mainland); Arizona; Arkansas; California; Colorado; Connecticut; Delaware; Florida; Georgia; Idaho; Illinois; Indiana; Iowa; Kansas; Kentucky; Louisiana; Maine; Maryland; Massachusetts; Michigan; Minnesota; Mississippi; Missouri; Montana; Nebraska; Nevada; New Hampshire; New Jersey; New Mexico; New York; North Carolina; North Dakota; Ohio; Oklahoma; Oregon; Pennsylvania; Rhode Island; South Carolina; South Dakota; Tennessee; Texas; Utah; Vermont; Virginia; Washington; West Virginia; Wisconsin; Wyoming., has ballpark transformation

PROJ string:
+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +proj=unitconvert +xy_in=deg +xy_out=rad
  +step +proj=tmerc +lat_0=0 +lon_0=-53 +k=0.9999 +x_0=304800 +y_0=0 +ellps=GRS80

I could imagine that the reason is that the bbox does not intersect with the area of use of CGVD28 heigh (despite of the geoid model file covers that point). Is there a way to workaround it?

Thanks

On Thu, 21 Dec 2023 at 10:27, Javier Jimenez Shaw <j1 at jimenezshaw.com<mailto:j1 at jimenezshaw.com>> wrote:
Hi

I'm trying to convert from WGS84 (or NAD83, I do not mind)  to "MTM zone 1 + CGVD28 height" in Canada.
I know that the area of use of "MTM zone 1" and "CGVD28 height" do not intersect. But they told me "Canadian agencies still require this datum [CGVD28] throughout all of Canada." Actually the geoid model grid file [ca_nrc_HT2_1997.tif: Canada, Natural Resources Canada, NAD83(CSRS)v2 (EPSG:8235) to CGVD28 height (EPSG:5713)] covers much more than the CRS area of use.

projinfo says something that makes sense to me:

PROJ_NETWORK=ON projinfo -s EPSG:4979 -t EPSG:32181+5713 -o proj --spatial-test intersects

Candidate operations found: 303
-------------------------------------
Operation No. 1:

unknown id, Inverse of NAD83 to WGS 84 (6) + NAD83 to NAD83(CSRS)v2 (1) + NAD83(CSRS)v2 to CGVD28 height (1) + Inverse of NAD83 to NAD83(CSRS)v2 (1) + MTM zone 1, 4.55 m, unknown domain of validity

PROJ string:
+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +proj=unitconvert +xy_in=deg +xy_out=rad
  +step +inv +proj=vgridshift +grids=ca_nrc_HT2_1997.tif +multiplier=1
  +step +inv +proj=hgridshift +grids=ca_nrc_NA83SCRS.tif
  +step +proj=tmerc +lat_0=0 +lon_0=-53 +k=0.9999 +x_0=304800 +y_0=0 +ellps=GRS80

But cs2cs is not doing any vertical transformation:

echo 47.741422 -53.613219 0 | PROJ_NETWORK=ON cs2cs EPSG:4979 EPSG:32181+5713 --3d
258814.79 5289330.04 0.00

Running with PROJ_DEBUG=3 it ends with
Using coordinate operation Inverse of Transformation from CGVD28 height to WGS 84 (ballpark vertical transformation, without ellipsoid height to vertical height correction) + Inverse of Ballpark geographic offset from NAD83 to WGS 84 + MTM zone 1
that makes sense with the no-change in elevation.


Why is that happening?

I do not care so much about the version of NAD83. I tried with some and I get the same result.
The same with the source CRS. I use WGS84, but can be any flavour of NAD83.

Thanks.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20231221/9c77add9/attachment-0001.htm>