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

[Duncan Agnew]

One way to look at it is that the lat_p lon_p moves the new pole along a
meridian to a new location; the rotation pole
then is always on the equator (at right angles to the meridian plane). So
there as, as expected, only two parameters:
the longitude of the rotation pole, and the amount of rotation around it.
To get a general rotation, you have to
introduce a second rotation, which is always around the geographic pole; it
can be before or after that pole is
moved, The direction of the rotation pole is not a free parameter, but the
amount of rotation around it is, so
we have the appropriate number of parameters (3, as in a unit quaternion)
for a general rotation.

So if you decompose the full rotation into two quaternions, one for the
rotation around the geographic pole, and
one to move that pole to a new location (rotation pole on the equator),
then the parameters of these are what you
need for proj. (Though again the order is, move the pole, then rotate
around it).

On Wed, Nov 9, 2022 at 11:12 PM DAVEN P QUINN <daven.quinn at wisc.edu> wrote:

> 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
> <https://urldefense.com/v3/__https://github.com/OSGeo/PROJ/blob/master/src/projections/ob_tran.cpp__;!!Mih3wA!HHXFjskzBWFI9_IxlFUM-46NRb1QWDuaNyPUxfLXyVk8IKiTAoHvTltVWLjjml34reMXW8_pGh3jBdCkxGvi0A$>
>
>
> --
> http://www.spatialys.com
> <https://urldefense.com/v3/__http://www.spatialys.com__;!!Mih3wA!HHXFjskzBWFI9_IxlFUM-46NRb1QWDuaNyPUxfLXyVk8IKiTAoHvTltVWLjjml34reMXW8_pGh3jBdBc-pV4kA$>
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20221110/c419d4b3/attachment.htm>