Re: "Trustworthiness" of vertical transformations

Nyall,

> I've seen a lot of activity on the PROJ repo lately relating to
> vertical datum transformations. Coming from zero knowledge about the
> world of vertical transformations... if I setup a simple
> transformation between two proj CRS objects created using auth/id
> codes, and transform a 3d point using proj_trans_generic... how
> "trustworthy" is the resultant z value?

If those are just projected CRS or geographic 2D CRS, the resultant z value 
will be unchanged. To have some "hope" that you get a change in z value, you 
must work with either a CompoundCRS or a Geographic 3D CRS.

> 
> I've seen some examples (e.g in
> https://github.com/OSGeo/PROJ/issues/1743) which use a
> "EPSG:26911+5703" type construct, 

This is a special syntax inherited from GDAL to build a compound CRS from a 
horizontal CRS (geographic or vertical) + a vertical CRS.
Otherwise the EPSG dataset includes a few coded compound CRS: 	
https://github.com/OSGeo/PROJ/blob/master/data/sql/compound_crs.sql
So you can use EPSG:3901 to get "KKJ / Finland Uniform Coordinate System + N60 
height" directly, instead of EPSG:2393+5717
There's also a more official one coming from a OGC white paper, that you can 
see on https://proj.org/apps/projinfo.html :
urn:ogc:def:crs,crs:EPSG::2393,crs:EPSG::5717

> which leads me to believe that the
> world of vertical transformations is not so straightforward!

Indeed it is not. It is what has required the most tunings the last weeks/
months in PROJ. Computing those transformations is also expensive timewise 
speaking, because there are both horizontal and vertical transformations to 
consider (and as described in https://github.com/OSGeo/PROJ/issues/1743 , if 
there's no registered transformation between the vertical CRS and the source 
or target geographic 3D CRS, then PROJ researches all the vertical CRS to 
whatever_geographic_3D_CRS is registered, and then computes the horizontal 
transformation between those whatever_geographic_3D_CRS and the source and 
target CRS (*)). Timings of several hundred of milliseconds in 
createOperations() are not uncommon, so you need to make sure to keep the 
result cached. Execution of pipelines (coordinate reprojection) then runs as 
decently as possible.

I've especially worked on improving the results of CompoundCRS <--> Geographic 
3D CRS transformations. I'm pretty sure CompoundCRS <--> CompoundCRS would 
also require some additional love.

One of the practical difficulties is that if you work with 'exotic' vertical 
CRS, there will be no registered transformation between them and a (the) 
Geographic 3D CRS, so you'll get a no change in the Z value.

Even

(*) I've a document in the works describing most of the logic behind 
createOperations(), but it takes a loooong time to write, as everytime I try 
to find an example to illustrate my theory, I find something to improve in the 
code :-)

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj