[PROJ] Local CRS as derived

[Javier Jimenez Shaw]

Thanks Greg. Your answer gives me some hope that I am not very wrong with
my ideas. But still many open questions.

About a better transformation for the vertical values (3 degrees of
freedom, not 1), I found this in the EPSG:
METHOD["Vertical Offset and Slope",ID["EPSG",1046]]
https://epsg.org/coord-operation-method_1046/Vertical-Offset-and-Slope.html
But I have the impression that it is not implemented in PROJ. Am I right?

Cheers
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Tue, 26 Jul 2022 at 13:27, Greg Troxel <gdt at lexort.com> wrote:

>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220726/62fbecb2/attachment.htm>