[PROJ] Local CRS as derived

[Greg Troxel]

Javier Jimenez Shaw <j1 at jimenezshaw.com> writes:

> I want to define a local projected CRS, and be able to compute
> transformations from geographic 3D coordinates to this final system (site
> calibration). This final (3 axes) system have to be expressed in a WKT2
> string, including somehow the coordinate operations.

I have this problem too, but only in a hobby sense so I have not been
really struggling with it.  Concretely, a local coordinate system normal
to gravity, from classical surveying measurements, with stations having
horizontal and vertical components.  I am guessing yours has the U
component matching the plumb line, rather than normal to the ellipsoid,
and you're ok with ignoring the Laplace correction.

My sense is that full treatment of local CRS is beyond what almost
anybody does, and people with big enough areas and who care about the
Laplace correction just don't use a local CRS.

> It looks like a DERIVEDPROJCRS is a good candidate (I got inspired in
> https://gis.stackexchange.com/questions/387189/how-to-use-affine-transform-parameters-in-a-proj-or-wkt2-string
> ). Maybe there is something better.
> I would choose the BASEPROJCRS properly (something like a Transverse
> Mercator centred in the area of interest), and I can compute the 2D affine
> transformation parameters.

That makes sense.  My tentative approach which was 2D only uses Lambert
conformal conic because it's my state plane system, but same thing.

> However I have some questions with the vertical component. I guess there is
> not affine transformation method in 3D ("Affine parametric transformation"
> is 2D), so I would have to define a compound of "derived projected" and
> "derived vertical", right?.

It seems to me that the 3D transform should exist.  It is semantically
sensible.

> For the vertical I could use the method "Vertical offset" (is there
> any other option that is not just a constant value?).

If you are transforming the vertical separately one input, then the
output can't be function of the horizontal position.  So the options are
an offset, and then a scale and offset, and so on, to view it through
Taylor-colored glasses.

> But that means that I need a proper vertical crs as base. If the
> initial 3D input is in ellipsoidal heights (very likely, as they are
> RTK measurements), how can a add a derived vertical to change the Z
> value?  There is no such a vertical crs that means "ellipsoidal
> height", even in WKT2, right?

It seems like there should be, because it is semantically sensible.  But
if not you could transform to the continental/national orthometric
height, or even WGS84 orthometric height (avoiding the ensemble :-)

> This solution would leave me only 5 degrees of freedom: 3 for the
> translation, 1 for the horizontal rotation and 1 for horizontal the scale
> (now I notice that I would not have vertical scale). Vertical and
> horizontal calibrations would be independent.

Yes, 2 rotations are missing.  But this is exactly saying that the U
axis of the local CRS is the ellipsoidal normal.  I think this is
equivalent to deciding to process EN and U separately.

And yes, there's no vertical scale.  That makes sense for real
situations.

Horizontal scale shows up in two different situations:

  As scale (3D) in datum transformations, e.g. at the ppb level among
  ITRF realizations.  This isn't relevant at all to a local CRS.

  To account for non-1 scale due to a projection.  This is I think what
  you are dealing with.

> How can I deal with the vertical component?

I can only think of using e.g. NAVD88/EVRF2007/etc.

> Is there any better solution?

Define a code for ellipsoidal height only as a vertical CRS and then use
it.

Or probably better, TM as a 3D CRS with Easting, northing and HAE, and
then a 2D affine plus a vertical, or use 3D affine with two zero
rotations, a scale for horizontal and scale=1 for vertical.  But this is
a change to doctrine and not feasible in the short term.

I guess what's hard fundamentally is that you are trying to have a 3D
local CRS, and my sense is that this is generally not done -- even
though it is completely sensible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220726/4d79e7e6/attachment.sig>