<div dir="ltr"><div>Thanks Greg. Your answer gives me some hope that I am not very wrong with my ideas. But still many open questions.<br></div><div><br>About a better transformation for the vertical values (3 degrees of freedom, not 1), I found this in the EPSG:<br>METHOD["Vertical Offset and Slope",ID["EPSG",1046]]<br><a href="https://epsg.org/coord-operation-method_1046/Vertical-Offset-and-Slope.html">https://epsg.org/coord-operation-method_1046/Vertical-Offset-and-Slope.html</a><br></div><div>But I have the impression that it is not implemented in PROJ. Am I right?</div><div><br></div><div>Cheers<br></div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__<br>Entre dos pensamientos racionales <br>hay infinitos pensamientos irracionales.<br><br></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Jul 2022 at 13:27, Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Javier Jimenez Shaw <<a href="mailto:j1@jimenezshaw.com" target="_blank">j1@jimenezshaw.com</a>> writes:<br>
<br>
> I want to define a local projected CRS, and be able to compute<br>
> transformations from geographic 3D coordinates to this final system (site<br>
> calibration). This final (3 axes) system have to be expressed in a WKT2<br>
> string, including somehow the coordinate operations.<br>
<br>
I have this problem too, but only in a hobby sense so I have not been<br>
really struggling with it.  Concretely, a local coordinate system normal<br>
to gravity, from classical surveying measurements, with stations having<br>
horizontal and vertical components.  I am guessing yours has the U<br>
component matching the plumb line, rather than normal to the ellipsoid,<br>
and you're ok with ignoring the Laplace correction.<br>
<br>
My sense is that full treatment of local CRS is beyond what almost<br>
anybody does, and people with big enough areas and who care about the<br>
Laplace correction just don't use a local CRS.<br>
<br>
> It looks like a DERIVEDPROJCRS is a good candidate (I got inspired in<br>
> <a href="https://gis.stackexchange.com/questions/387189/how-to-use-affine-transform-parameters-in-a-proj-or-wkt2-string" rel="noreferrer" target="_blank">https://gis.stackexchange.com/questions/387189/how-to-use-affine-transform-parameters-in-a-proj-or-wkt2-string</a><br>
> ). Maybe there is something better.<br>
> I would choose the BASEPROJCRS properly (something like a Transverse<br>
> Mercator centred in the area of interest), and I can compute the 2D affine<br>
> transformation parameters.<br>
<br>
That makes sense.  My tentative approach which was 2D only uses Lambert<br>
conformal conic because it's my state plane system, but same thing.<br>
<br>
> However I have some questions with the vertical component. I guess there is<br>
> not affine transformation method in 3D ("Affine parametric transformation"<br>
> is 2D), so I would have to define a compound of "derived projected" and<br>
> "derived vertical", right?.<br>
<br>
It seems to me that the 3D transform should exist.  It is semantically<br>
sensible.<br>
<br>
> For the vertical I could use the method "Vertical offset" (is there<br>
> any other option that is not just a constant value?).<br>
<br>
If you are transforming the vertical separately one input, then the<br>
output can't be function of the horizontal position.  So the options are<br>
an offset, and then a scale and offset, and so on, to view it through<br>
Taylor-colored glasses.<br>
<br>
> But that means that I need a proper vertical crs as base. If the<br>
> initial 3D input is in ellipsoidal heights (very likely, as they are<br>
> RTK measurements), how can a add a derived vertical to change the Z<br>
> value?  There is no such a vertical crs that means "ellipsoidal<br>
> height", even in WKT2, right?<br>
<br>
It seems like there should be, because it is semantically sensible.  But<br>
if not you could transform to the continental/national orthometric<br>
height, or even WGS84 orthometric height (avoiding the ensemble :-)<br>
<br>
> This solution would leave me only 5 degrees of freedom: 3 for the<br>
> translation, 1 for the horizontal rotation and 1 for horizontal the scale<br>
> (now I notice that I would not have vertical scale). Vertical and<br>
> horizontal calibrations would be independent.<br>
<br>
Yes, 2 rotations are missing.  But this is exactly saying that the U<br>
axis of the local CRS is the ellipsoidal normal.  I think this is<br>
equivalent to deciding to process EN and U separately.<br>
<br>
And yes, there's no vertical scale.  That makes sense for real<br>
situations.<br>
<br>
Horizontal scale shows up in two different situations:<br>
<br>
  As scale (3D) in datum transformations, e.g. at the ppb level among<br>
  ITRF realizations.  This isn't relevant at all to a local CRS.<br>
<br>
  To account for non-1 scale due to a projection.  This is I think what<br>
  you are dealing with.<br>
<br>
> How can I deal with the vertical component?<br>
<br>
I can only think of using e.g. NAVD88/EVRF2007/etc.<br>
<br>
> Is there any better solution?<br>
<br>
Define a code for ellipsoidal height only as a vertical CRS and then use<br>
it.<br>
<br>
Or probably better, TM as a 3D CRS with Easting, northing and HAE, and<br>
then a 2D affine plus a vertical, or use 3D affine with two zero<br>
rotations, a scale for horizontal and scale=1 for vertical.  But this is<br>
a change to doctrine and not feasible in the short term.<br>
<br>
I guess what's hard fundamentally is that you are trying to have a 3D<br>
local CRS, and my sense is that this is generally not done -- even<br>
though it is completely sensible.<br>
</blockquote></div>