ｏｓｇｅａｒｈ的ENU坐标如何转换

liyihongcug

ｏｓｇｅａｒｈ的ENU坐标如何转换？
(只找到
SRS的组成
一个SRS包括：

坐标系类型（Coordinate system type）
水平基准线（Horizontal Datum）
垂直基准线（Vertical Datum）
投影（Projection）
坐标系类型
osgEarth支持三种类型的基础坐标系：

Geographic - 地理坐标系，坐标值为球面角度值(经度和纬度)，典型坐标包括WGS84和NAD83.
投影 - 局部坐标系，将地球的某个区域“投影”到2D笛卡尔平面（X,Y），包括UTM，US State Plane，和Mercator（墨卡托）等
ECEF - 全球的笛卡尔系统。ECEF= Earth Centered Earth Fixed；原点在地心的的3D笛卡尔坐标系(X,Y,Z)。ECEF是osgEarth渲染自己的图像时采用的坐标系。
)
osg 是行主序 。Bs是列主序。这个是不同
规定：

1、航空次序欧拉角：

Z轴(航偏角，yaw，Ψ)

Y轴(俯仰角，pitch，θ)

X轴(滚转角，roll，Φ)

2、导航坐标系（N系）为O-ENU坐标系，即东北天坐标系。且机体坐标系初始状态与导航坐标系重合。即有： 导航坐标系X轴指向正东方向，机头也朝向正东方向；

导航坐标系Y轴指向正北方向，机左翼指向正北方向；

导航坐标系Z轴垂直地表指向天空，垂直机体指向天空。

3、每个轴都以逆时针旋转的角度为正角度
computeCoordinateFrame(double latitude, double longitude, osg::Matrixd& localToWorld) const
{
    // Compute up vector
    osg::Vec3d    up      ( cos(longitude)*cos(latitude), sin(longitude)*cos(latitude), sin(latitude));

    // Compute east vector
    osg::Vec3d    east    (-sin(longitude), cos(longitude), 0);

    // Compute north vector = outer product up x east
    osg::Vec3d    north   = up ^ east;

    // set matrix
    localToWorld(0,0) = east[0];
    localToWorld(0,1) = east[1];
    localToWorld(0,2) = east[2];

    localToWorld(1,0) = north[0];
    localToWorld(1,1) = north[1];
    localToWorld(1,2) = north[2];

    localToWorld(2,0) = up[0];
    localToWorld(2,1) = up[1];
    localToWorld(2,2) = up[2];

liyihongcug

没有找到方法，这个只能自己写一个类。否则模型的在局部的移动非常尴尬，居然看到在局部使用全局笛卡尔坐标，这个真是不好说居然能这样处理。闹大笑话。
思路方法：前面帖子说过，按照地理专业，先求地面点（简化问题全部在理想的水准面地面）的东向量北向量 和上向量。之后绕之旋转，请注意不是全局笛卡尔的所谓X Y Z 旋转。

比较有难度的是已经2个向量如何求计算从一个向量转向另一个向量的四元数。

liyihongcug

我们使用OpenGL和OSG的过程中，总会涉及到顶点坐标以及坐标的变换（通过向量和矩阵相乘），这其中经常会看到有人说在OpenGL中使用的是列向量，在OSG中使用的是行向量 ，由于行向量和列向量的不同导致在矩阵作乘法的时候有左乘和右乘之分，本文就这一问题作一个相对完整的解释。

行向量和列向量
1.  行向量和列向量的定义如下：
在线性代数中，行向量是一个 1×n的矩阵， 即矩阵由一个含有n个元素的行所组成。 
在线性代数中，列向量是一个 n×1 的矩阵，即矩阵由一个含有n个元素的列所组成。 
行向量a=(a1,a2,a3.....)
列向量a=(a1,
               a2,
               a3.....)
2. 左乘和右乘
说简单点，左乘(又称前乘)就是乘在左边（即乘号前），右乘（又称后乘）就是乘在右边（即乘号后）。比如说，A左乘E即AE，A右乘E即EA。

3.行向量和列向量的变换
由于向量实际上是某一维度为1的矩阵，那么根据矩阵乘法的规则，会出现下面的情况：
（1）行向量左乘矩阵
在图形学中一般矩阵都是4x4的，行向量一般设置为1x4的矩阵（齐次坐标）。当行向量左乘矩阵的时候 （1x4）* （4x4）得到的是一个1x4的行向量
（2）行向量右乘矩阵
这种情况，也就是（4x4）*（1x4），根据矩阵相乘的规则，这是不允许的
（3）列向量左乘矩阵
这种情况，也就是（4x1）*（4x4），根据矩阵相乘规则，这也是不允许的
（4）列向量右乘矩阵
这种情况，也就是（4x4）*（4x1），得到的是一个4x1的行向量

我们作三维的变化为的就是将一个坐标变换到另一个坐标，于是上面讨论的（1）（4）两种方式正好符合这一要求。根据上面的讨论有以下的结论：
行向量左乘还是右乘根本就是矩阵乘法规则的限制，行向量只能左乘而列向量只能右乘矩阵，这和三维图形学没有一点儿的关系。因此有人说OpenGL都是右乘、OSG都是左乘从结论上来说是对的，但是这和OpenGL以及OSG本身并没有半点关系，这只是矩阵乘法的定义。

行向量列向量以及在编程语言中的内存布局
假设有一个4x4的矩阵M，我们现在有一个顶点的坐标是v，通过M矩阵的变换可以把它变为v’，现在分别假设 v是行向量或者v是列向量，于是有以下两种情形：
（1）v是行向量 ， 那么  v' = v*M  
（2）v是列向量，  那么  v' = M*v  
用那种方式来理解变换都是可以的。下面一段是OpenGL规范最早的设计者的一段话，可以从中知道他当时只是想使用列向量这种方式让图形学和数学上的表达一致，而" 欺骗” 读者说OpenGL使用的是列向量。
I'm the one responsible for the 'column-major ordering' used in OpenGL, so I'll try to explain what's going on to try to put this discussion to rest.

First, there are two issues that seem to be confused.
One issue is how matrices are stored in memory,
and the other is whether one treats vectors as rows of coordinates or as columns.

I'll dispense with the second issue first.
Recent mathematical treatments of linear algebra and related fields invariably treat vectors as columns (there are some technical reasons for this). For some reason, this has not been the case in computer graphics, where vectors were written as rows, thus transposing everything from standard mathematical usage. When I wrote the OpenGL spec, I decided to do my part to right this heinous inconsistency. Thus the spec is written with vectors treated as columns, with a matrix correspondingly applied on the left of a column.
The one difficulty was compatibility with the current GL, where vectors had been written as rows. So I come up with this subterfuge: say that matrices in OpenGL are stored in column major order. The point is that you could rewrite the spec with everything transposed (with vectors written as rows), and everything would be exactly the same as it was, including the row major ordering of matrices.

那么现在又有一个疑问：既然行向量和列向量并没有什么不同，那么为什么大家都在说在OpenGL中使用的是列向量而OSG中使用的是行向量呢？ 答案就在于：当使用C/C++语言进行描述矩阵和向量相乘的时候，使用行向量的理解方式和使用列向量的理解方式在内存中存储矩阵元素的时候有所不同，这就是真正的关键点所在。还是按之前的做法，假设现在坐标点是  （1,2,3, 0），通过矩阵M，变换为坐标值是（38,44,50,56）的点，对于这个变换来说，可以使用行向量和列向量来理解，这两种理解方式正好就是OSG和OpenGL的处理方式。

（1）使用行向量的方式来理解， 那么我们的矩阵是 
        double M[4][4] =
        {
                {1, 2, 3, 4},
                {5, 6, 7, 8},
                {9,10,11,12},
                {13,14,15,16}
        };
通过矩阵乘法知道 v = (1, 2, 3, 0) ， 那么 v' = vM = (38, 44, 50, 56)， 假设正好我们使用C/C++语言进行编码，由于C/C++语言中并没有矩阵这种类型，它使用二维数组来存储矩阵元素，并且在C/C++中使用的是 行主序的方式进行存储的，因此矩阵M在内存中如下图所示：



（2）使用列向量的方式来理解，那么我们的矩阵就不是上面的矩阵了，而是：
 
        double M[4][4] =
        {
                {1, 5, 9,  13},
                {2, 6, 10, 14},
                {3, 7, 11, 15},
                {4, 8, 12, 16}
        };
通过矩阵乘法，v' = Mv

在C/C++内存模型中，这个矩阵M如下所示：


可以看到使用行向量和列向量的区别，仅仅是内存布局的不同导致我们在理解行向量和列向量的时候有差异。

从上面的分析可以得出以下的几点结论：

（1）使用行向量或者列向量来理解OpenGL和OSG都可以，实际上行向量和列向量并没有任何的差别
（2）当使用列向量来理解变换的时候，所有的变换方式都是后乘（右乘），当使用行向量来理解变换的时候，所有变换的方式都是前乘（左乘）
（3）OpenGL为了表现它是使用的列向量，所有的矩阵设计为列主序的方式，因此当我们在进行变换的时候，需要注意要将矩阵按C/C++语言内存布局的方式存储，也就是说假设有一个平移矩阵，平移量Tx,Ty,Tz应该处在的位置是数组的第 4,8,12位置处

这种处理方式在C/C++中会显得十分别扭，因为这几个平移变量的位置不连续，这也是为什么很多三维库都使用 行主序（行向量）方式的原因，因为如果使用行向量的方式，那么这三个行向量的位置正好是相邻的，和C/C++语言的存储方式一致。  不过OpenGL也提供了用来接收行主序方式的矩阵的函数：

glLoadTransposeMatrixf

glLoadTransposeMatrixd
（4）OSG为了让人感觉它使用的是行向量，所有矩阵的设计都是基于行主序的方式。这样的设计正好与c++语言中二维数组的存储方式一致，使用起来比较自然。所有在OSG中的变换都是左乘矩阵， 通过查看OSG中Matrix的实现也很容易看到这一点：
        double xarray[4][4] =
        {
                {1, 2, 3,  4},
                {5, 6, 7, 8},
                {9, 10, 11, 12},
                {13, 14, 15, 16}
        };

        osg::Matrixd mat;
        mat.set((double*)xarray);

        //x12 = 7
        double x12 = mat(1, 2); blog.csdn.net csxiaoshui java article details 51740882

liyihongcug

困惑 osg的 {0.206505939, -0.708864927, -0.841922104} } roll pitch raw 与BS的是反向的 符号相反
heading: 0.8419220914223688, pitch: 0.7088649026650486, roll: 0.20650593768060643
依次时 roll pitch yaw
osg::Vec3 v(
                atan2((2 * (q.w()*q.x() + q.y()*q.z())), (1 - 2 * (pow(q.x(), 2) + pow(q.y(), 2)))),
                asin(2 * (q.w()*q.y() - q.z()*q.x())),
                atan2((2 * (q.w()*q.z() + q.x()*q.y())), (1 - 2 * (pow(q.y(), 2) + pow(q.z(), 2))))
        );

根本 原因在于osg CS的ENU的 UP向量是垂直向上的。  而BS的向量是垂直向下的。
CS BS的 三维球的east坐标在0 0 ，right坐标在（90 0）《很经典的osgearth的文章验证是错误的》。这样导致好多错误

逆矩阵可以将解决ENU的所有问题