<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 26/07/2022 à 17:37, Javier Jimenez
Shaw a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CADRrdKu41cjEsuRi21PDeq43g0g6Tv_dRc32VOzAKHqz0N_wcg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
<p><br>
</p>
<p>==> it is implemented in master:
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/pull/3200">https://github.com/OSGeo/PROJ/pull/3200</a><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CADRrdKu41cjEsuRi21PDeq43g0g6Tv_dRc32VOzAKHqz0N_wcg@mail.gmail.com">
<div dir="ltr">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
PROJ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>