[PROJ] Proj transformation for arbitrary (quaternion/Euler) spatial rotation

[Thomas Knudsen]

By default, the PROJ Helmert implementation uses small angle approximations
(cf.
https://github.com/OSGeo/PROJ/blob/master/src/transformations/helmert.cpp#L174-L205),
but by specifying the "+exact" switch (
https://proj.org/operations/transformations/helmert.html#equation-rot-exact),
the exact rotation matrix is constructed, so you should be able to get
things working with that little tweak.

Den tor. 10. nov. 2022 kl. 08.12 skrev DAVEN P QUINN via PROJ <
proj at lists.osgeo.org>:

> Thanks to everyone in this conversation for their suggestions.
>
> It seems to me that there are two approaches that have been suggested that
> may work: using the `lat_p` and `lon_p` options to `ob_tran`, and using a
> pipeline that converts to geocentric cartesian coordinates, does a Helmert
> transform (consisting entirely of rotation), and converts back to angular
> space.
>
> I have also tried the “move the pole location” signature of ob_tran (by
> computing the new location of the pole based on my desired spatial
> rotation), and it does seem to do a reasonable spatial shift, but there is
> a rotational component that is not properly accounted for in that method. I
> have tried to handle that last degree of freedom by a combination of `lon0`
> and `alpha`, but I think the alpha in this case does a rotation in
> Cartesian space.
>
> The Helmert option seems potentially viable (though slightly less
> preferred because pipelines are only possible in the most recent PostGIS
> version) but I was under the impression that was used mostly for small
> angular shifts of data already in projected (i.e., 2 or 2.5d) space, not
> rotating a full geocentric manifold through a large angle. I will try it
> out though.
>
> Another option seems like it might be two stages of ob_tran pole movement,
> first moving the north pole of the projection to the pole of rotation,
> changing the longitude around that pole, and then moving the pole back to
> its computed final location. It seems like getting the math right in this
> case would be challenging.
>
> I will continue exploring in these directions, and read the code Evan
> provided for more context. Any additional thoughts on this synthesis would
> be appreciated.
>
> Regards,
>
> Daven
> On Nov 9, 2022, 5:42 PM +0100, Even Rouault <even.rouault at spatialys.com>,
> wrote:
>
>
>
> How does Proj actually do the G.O.T? I don't mean what are the
> parameters, I mean what is the actual code that does the arithmetic?
>
>
> ==> https://github.com/OSGeo/PROJ/blob/master/src/projections/ob_tran.cpp
>
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20221110/5872776b/attachment.htm>