<div dir="ltr"><div>My reading of the documentation is that the    lat_c long_c alpha   are the parameters of a 2-d rotation applied to the</div><div>projected values, not a rotation of the sphere. The only way to do a spherical rotation would be to find out</div><div>where the N Pole rotates to, and use lat_p and long_p (and alpha).</div><div><br></div><div>An affine transformation is a 2d operation (I think all the transformations are)--though now 3-d, as changes in x y and</div><div>z (local grid and elevation).<br></div><div><br></div><div>It would be good to move the General Oblique Transformation into the Transformations  section of the documentation--or</div><div>at least repeat the entry there. I scanned the projections list a couple of times and missed it--maybe just call it</div><div>Oblique so it fits into the (mostly) alphabetical order.<br></div><div><br></div><div>Duncan Agnew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 9, 2022 at 4:00 AM DAVEN P QUINN via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</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">




<div>
<div name="messageBodySection">
<div dir="auto">Hello all,<br>
<br>
I’m a geologist who is working with paleogeographic reconstructions (see example <a href="https://urldefense.com/v3/__https://davenquinn.com/viz/corelle-demo-pbdb/?time=295__;!!Mih3wA!Ek22jIRdqHNmPv2JHH5Y30sEuUXdoVxt0Fk-QFHtEMBBTuqsZd3R2iiv778TR-mZY_w_JHtLfllItIU$" target="_blank">here</a>). These require composite reproductions where different parts of a feature dataset (continents)
 are rotated with different axis-angle transformations. I’ve had good luck doing these rotations with quaternion math in the browser/Python environments, but I am now trying to use Proj transformations in order to apply rotations directly within PostGIS queries.<br>
<br>
<span>This </span><a href="https://urldefense.com/v3/__https://pbs.twimg.com/media/Fgpx4UGXEAQmPOt?format=jpg&name=4096x4096__;!!Mih3wA!Ek22jIRdqHNmPv2JHH5Y30sEuUXdoVxt0Fk-QFHtEMBBTuqsZd3R2iiv778TR-mZY_w_JHtLewKG3Gg$" target="_blank">linked image</a> <span>shows the desired result, a plate reconstruction to 250 Ma
 with a different rotation applied to each plate. This was produced by applying the desired quaternions through pl/pgsql math. Moving this math to Proj internals would result in a ~50-100x speedup.</span><br>
<br>
The tool that seems most fitting is the `ob_trans` family of projections, but I have been unable to define a rotation that can handle my preferred representation (a pole defined in Lon-lat coordinates and an associated angle of rotation around it). From my
 reading of the docs, I believe the `o_lon_c`, `o_lat_c` and `o_alpha` parameters should do this, but I cannot get them to work reliably. In fact, I can’t even reliably define a ’no-op’ transformation that leaves coordinates unchanged. Perhaps I have the angular
 coordinate system wrong, or the rotation is being done in Cartesian space even though `proj=lonlat` is used.<br>
<br>
Is it possible to define an arbitrary spherical spatial rotation in Proj transformations? Maybe I need to use pipelines instead? I’d appreciate any guidance! More details below the fold...<br>
<br>
Regards,<br>
<br>
<strong>Daven P. Quinn</strong><br>
Research scientist II · <em>U of Wisconsin Madison</em><br>
PhD · structural geology · <em>Caltech</em> ‘18<br>
<a href="https://urldefense.com/v3/__https://davenquinn.com__;!!Mih3wA!Ek22jIRdqHNmPv2JHH5Y30sEuUXdoVxt0Fk-QFHtEMBBTuqsZd3R2iiv778TR-mZY_w_JHtL9qsbApE$" target="_blank">https://davenquinn.com</a><br>
+1 704 920 8487<br>
<br>
-------------<br>
<br>
Here is an example of the pl/pgsql I am currently using to assemble a projection (I have gone through many iterations testing different offsets and the different ways to specify the transformation):<br>
```<br>
RETURN '+proj=ob_tran +o_proj=longlat +o_alpha=' || pi()/2+angle || 'r +o_lon_c=' || pi()/2+lon || 'r +o_lat_c=' || lat || 'r' proj<br>
```<br>
where (lat, lon, angle) defines a rotation pole.<br>
<br>
This results in some geometries (with a fortuitous set of poles, I guess) attaining ballpark-correct transformations while other features are shifted far outside of their origin tiles.</div>
</div>
</div>

_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!Ek22jIRdqHNmPv2JHH5Y30sEuUXdoVxt0Fk-QFHtEMBBTuqsZd3R2iiv778TR-mZY_w_JHtLGSbNb0U$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!Ek22jIRdqHNmPv2JHH5Y30sEuUXdoVxt0Fk-QFHtEMBBTuqsZd3R2iiv778TR-mZY_w_JHtLGSbNb0U$</a>  <br>
</blockquote></div>