[PROJ] Local CRS as derived

[Even Rouault]

Le 26/07/2022 à 17:37, Javier Jimenez Shaw a écrit :
> 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?


==> it is implemented in master: https://github.com/OSGeo/PROJ/pull/3200


>
> 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.
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220726/7e965582/attachment-0001.htm>