osgEarth数据加载及组织解析
osgEarth数据加载及组织解析
1．osgEarth的数据加载流程
由前文可知，用户可以使用osgEarth自己的earth文件，简单指定各种数据源，而不用关心数据如何渲染，便能在三维球上显示各种地形数据。本节，将会解读osgEarth如何解析earth文件，利用用户提供的数据源，来构建三维球上的各种地形。
图3.1所示是加载数据的整体流程，本节将就这四个步骤进行具体的解读。
图3.1 osgEarth数据加载整体流程
1.1 读取earth文件
osgEarth继承了OSG的插件机制，所以osgEarth提供了专门读取earth文件的osgdb_earth插件。通过查找并调用此插件，达到读取earh文件的目的。图3.2展示了查找读取earth插件的具体流程：
图3.2 查找读取earth插件的具体流程
这个具体流程展示了osgEarth如何找到读取earth的插件——osgdb_earth.dll。这个流程其实也是osg插件机制中的具体流程，主要在read函数中根据文件后缀名查找读写插件，查找策略见前文2.1.3的OSG插件机制，找到插件后便根据文件名构建ReadNodeFunctor的仿函数，然后调用doRead()函数来具体读取。
无论读取earth文件，还是读取影像数据、高程数据或一般的文字，都是这样一个流程，通过找到具体插件后调用插件里的doRead函数。
在osgdb_earth中，主要就是将earth文件中的内容转换成后面构造map需要的conf对象。图3.3展示了一个包含标签比较全面的earth文件，图3.4为转换后的conf结果结构图：
图3.3 普通earth文件内部代码
图3.4 earth文件转换后的conf对象结构图
如图所示，将earth文件中的标签转换成就conf对象就是将标签语言的嵌套转换成父子关系，然后每个对象包含自己的属性值。
1.2 构建map
由上一节可知，通过earth插件，将earth文件中的数据属性，渲染属性等构成conf对象。接下来，就是根据这些属性，来构造一个包含影像、高程、模型等的map。图3.5展示了osgEarth构造map流程：
图3.5 通过属性构造map对象
由图可知，此时构造的map，并没有实际的读取数据，仅仅是将从earth文件中获取的conf对象属性进行分类，构造了一个逻辑map，主要指定了map包含什么图层，每个图层的名字、数据源和所需driver插件。
1.3 构建mapNode
这一步将是加载数据中的重点。在这一步，将会通过上一步获取的map对象及options对象，调用具体的driver插件，来构成地形节点。
构建mapNode的过程可以分为两步，第一步是在osgViewer（OSG最基本的场景图形浏览器，osgEarth最基本的场景图形浏览器是在osgViewer基础上改进的osgEarth_viewer，其主要是加载组织地形数据等，核心渲染功能还是osgViewer）渲染前的预处理，主要在地形引擎的preInitialize()中完成。osgEarth2.4的默认地形引擎为MpterrainEngineNode，所以一般是在MpterrainEngineNode::preInitialize()中完成第一步。这其中，主要完成地形节点的初步框架构建，及底图影像的加载。如图3.6所示
图3.6 构建mapNode第一步逻辑
第二步便是在osgviewer开始渲染，创建漫游，相机开始添加场景时，进行后续的添加，并使用TileKey管理构建四叉树组织。此时根据视点范围及距离，通过OSG的PagedLOD分页机制，动态调度选择加载区域瓦片节点。关于数据如何按四叉树进行组织，分页LOD如何动态调度选择加载数据将在后文进行详细解读。此处主要关注构建mapNode的流程和最后mapNode的逻辑节点树。如图3.7所示。
图3.7 构建mapNode第二步逻辑
下面便来解读每一步的详细流程。
图3.8 构建mapNode第一步详细流程
图3.8展示的是构建mapNode第一步的详细流程，最后生成包含了地形节点、模型节点和overlay模型节点的子树。其中，在根据map的空间参考坐标系设置TerrainEngineNode的坐标系和椭球模型时，map对象有获取profile属性。Profile是确定数据的空间信息重要属性，其如何确定数据的空间信息将在后文进行详细说明。若map对象的options中没有设置profile，默认将其中的SRS（空间参考系）设置为WGS84坐标系。
图3.9 构建mapNode第二步详细流程
图3.9展示的是构建mapNode第二步详细流程。此处只挑出了重点的函数，主要创建了第一层的TileKey和根节点。每个rootNode包含四叉树索引组织的key，包括范围信息等，然后还包含这块范围的各种数据，所以，创建根节点的createRootNode将是我们下面分析的重点。
图3.10 创建根节点的逻辑流程
图3.10展示的是创建根节点的逻辑流程。由图可知，归纳为做了两件事，第一件即创建了包含影像图层、高程图层及TileKey的瓦片模型，第二件事是将这个模型以PagedLOD形式加入根节点。其中TileKey包含模型的空间信息，能正确确定数据在三维球上的正确位置，且以四叉树形式被组织起来。PagedLOD即分页LOD，能根据视点范围动态选择加载哪些节点。这两个技术将在后文详细解读。
图3.11 createRootNode流程
图3.11展示了创建根节点的详细流程。其中，在创建影像图层和高程图层中，相应的execute函数里分别调用了createImage()函数和createHeightfields()函数，这两个函数根据数据中的option属性，调用了相应driver的插件，而进行了实际具体的 数据读取。如果需要写自己的插件读取影像数据或高程数据，则必须重载这两个函数。
图3.12 GeoLocator的具体空间信息处理
GeoLocator确定了瓦片模型的位置，如图3.12所示，主要通过key获取地形块的范围，然后再移至相应的位置。
综上，一个包含地形节点、模型节点和overlay模型节点的mapNode便被正确的构成了。其中最主要的便是地形节点的构造，它包含的影像图层、高程图层等都以四叉树结构进行组织，以分页LOD模式进行动态调度渲染。
更为详细的流程图，可参见附件中的osgEarth数据读取流程。
1.4 加载节点至场景树
最后的加载节点至场景树很简单，就是创建一个group节点，将mapNode包含进去，然后这个将加入osgViewer的渲染流程。
具体代码如下：
osg::Group*root = new osg::Group();
root->addVhild(mapNode.get());
在程序运行时，因为视野的改变，osgEarth会利用PagedLOD动态的加载卸载瓦片节点，而会重复上面构造mapNode的步骤来构造新的节点。
2．空间信息组织编码及位置确定
上一节内容解读了osgEarth如何将earth文件读入，并利用其中的XML标签构建地形结点从而达到渲染目的。这一节则主要解读如何将数据放入三维球正确的位置并进行组织。
简单而言，关于位置属性的记录，osgEarth就只是利用任何地形数据都会包括的投影坐标系及经纬度信息进行定位。这样的优点在于，无论何种数据源的数据，只要能最后确定一定的投影参考系，便能保证被放置在正确的位置，数据之间保持正确的拓扑关系和逻辑关系。而相关的投影系转换，标准，表达方式，国际上规定也十分明确。一个统一的标准，使osgEarth能接纳更多源的数据。
本节，就会首先介绍osgEarth相关的空间参考系，然后再解读其具体如何确定数据在三维球上的位置。同时，由前文可知，osgEarth通过创建用四叉树结构的分层瓦片缓存，可以快速加载大地形数据。最后，将解读其生成的缓存文件编码。
2.1 空间参考系
osgEarth中，每个map对象，layer对象，tilesource对象，均有决定其所属空间位置的属性profile。Profile中，包含记录对象空间参考系的属性SRS。通常，我们用经纬度来表示数据的位置。可是不同空间参考系中，相同的经纬度不一定表示一个地方。所以，osgEarth中每个数据对象都会包含空间参考系属性SRS。
一个空间参考系，包含以下内容[15]：
①坐标系类型
②水平基准
③高程基准
④投影
下面也就这四个方面对osgEarth的空间参考系进行介绍。
（一）坐标系类型
osgEarth支持三种地图的显示方法。
①地理坐标系类型
展示的方式便是三维数字地球，使用角度制的经纬度。代表包括WGS84坐标系和NAD83坐标系。
②投影坐标系类型
展示的方式是将三维区域投影到二维（X,Y）平面。代表包括UTM投影，墨卡托投影。
① ECEF
|
Z轴 |
|
Y轴 |
|
X轴 |
图3.13 ECEF
（二）水平基准面
根据地理空间测量方法的不同，基准面便会不同。同一个地方也可以有不同的基准标准。因为地球并不是一个完美的球体，甚至不是一个完美的椭球，所以为了拟合地球的形状，特定的地方会选用特定的水平基准面。一般而言，在北美会使用WGS84和NAD83，在欧洲会使用ETR89。
在osgEarth中，默认的水平基准面是WGS84，如果没有为数据设定相应的水平基准信息，osgEarth会默认设置WGS84的相关参数。
（三）高程基准面
高程基准是为了测量高程的。有许多类的高程基准，osgEarth支持两种高程基准：大地基准面（基于椭球）和大地水准面（基于地球上一些高程点）。
osgEarth内置以下四种高程基准面：
①Geodetic（大地基准面）。此为默认高程基准面，osgEarth使用水平基准面椭球来作参考。
②EGM84geoid（大地水准面）
③EGM96geoid（大地水准面），一般被称为MSL，在DTED和KML数据中会被使用
④EGM2008geoid（大地水准面）
在osgEarth中，默认的高程基准面是geodetic高程水准面，海拔依据HAE（height above ellipsoid）来测量。
（四）投影
SRS同时也提供投影信息，即将三维点投影到二维平面的方法。
因为osgEarth依赖GDAL和OGR两个工具库，所以它能支持上千种投影方法，如有名的UTM投影，兰伯特投影。
SRS使用WKT（Well Known Text）,PROJ4或EPSG方式来表达SRS空间参考系。这三种方式都是国际上比较通用的方式，这也增加了osgEarth的通用性。本文就不详细介绍这三种空间参考系表达方法了。
2.2 数据组织及位置确定
在前文的数据预处理中有提到过，osgEarth是实时建立分层瓦片集来进行实时渲染。简单而言，osgEarth就是通过记录了SRS和范围信息的profile属性，创建瓦片数据TileSource，并通过TileKey来进行四叉树进行管理。
|
|
|
|
|
………… |
|
第二层 |
|
lod:1 |
|
|
|
0 |
|
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
0 |
|
1 |
|
2 |
|
3 |
|
|
|
x |
|
y |
|
西半球 |
|
东半球 |
|
第一层 |
|
lod:0 |
|
第三层 |
|
lod:2 |
|
（-180，90） |
|
（180，90） |
|
（-180，-90） |
|
（-180，90） |
|
TileKey |
|
TileKey(2,5,1) |
图3.14 瓦片分层LOD
如图3.14所示，osgEarth中的世界范围是以经纬度来表示，若将球形表面剖开铺成平面，其最左为西经180度，最右为东经180度，最上为北纬90度，最下为南纬90度。
实时加载时，osgEarth会根据map或数据的profile属性实时进行分层瓦片化。表3.1列出的是profile中关于瓦片分层的一些属性，其中的数值是一个全球影像数据的属性值。下面将会详细解说osgEarth如何利用这些数据将数据分层瓦片化，并确定数据的位置。
| profile |
extent |
srs |
空间参考系 |
| west |
-180 |
||
| east |
180 |
||
| south |
-90 |
||
| north |
90 |
||
| numTilesWideAtLod0 |
2 |
||
| numTilesHighAtLod0 |
1 |
||
| fullSignature |
3be5346 |
||
| horizSignature |
3be5346 |
||
表3.1 map对象profile属性
numTilesWideAtLod0和 numTilesHighAtLod0是确定最高一层的宽度与高度，即行数与列数。默认是宽度为2，高度为1。这个默认值正好将第一层的全球数据分成东西半球。然后osgEarth将继续向下分层瓦片，随着一层层的深入，地形块就变得越来越小。当地形块大小比视点到块的距离还小时，便不再继续深入了。
每向下深入一层，每一个瓦片TileSource便会等分成四块。每一个瓦片TileSource均有一个TileKey进行管理，上一层的TileKey会有下一层的4个子key，由此体现了四叉树组织的思想。
在osgEarth中，瓦片的左上角是原点，TileKey便是从左上角开始编码。一般为TileKey（lod，x，y），如图10中第三层瓦片所示。其中阴影部分所对应的key为TileKey（2，5，1）。
随着瓦片的细化，每一块瓦片的范围也会逐渐变小。如图10中第三层瓦片里的阴影区域，其坐标范围便是西至东经45度，东至东经90度，南至赤道，北至北纬45度的瓦片块。这些数值将被记录到这个瓦片的extent属性中，如表2所示，其对应值分别为west，east、south和north。
当数据源在此范围内有数据时，此瓦片便会加载，否则不会加载。这样总的加载块数也不会那么多。同时根据这个范围，osgEarth将会确定了数据所处位置。
2.3 缓存编码
osgEarth支持缓存机制，可以提前将网络数据缓存在本地，使快速访问。图3.15便是一个缓存文件夹的示例。
|
第二层 |
|
第四层 |
|
第三层 |
|
第一层 |
图3.15 缓存文件夹
图3.15中，第一层的文件夹名称是缓存的名称编号。一般一个cache只加载一个数据源。图3.15中显示的缓存包括三个数据源的数据。第二层，第三层和第四层，就分别按TileKey的（lod，x，y）来进行编码，最里层的osgb是osg的一种二进制文件，便存储了每个瓦片tileSource的数据。在每一个数据源的缓存文件夹中，包括了一个记载数据源属性的json文件。从图3.15可知，第一层的数据源缓存文件夹编码似乎是乱码，其实其为利用哈希算法压缩过的conf配置属性。
如图3.15中的缓存文件夹617891fe_3be5346，可以分为两段来理解。第一段是下划线前面的字符串61781fe，代表着cacheId，第二段是下划线后面的字符串3be5346，代表HorizSignature，水平署名。
第一段的cacheId是在分解conf属性，构建map对象的时候计算的。它只取得map的layer中的tilesource的conf属性，将其写成Json文件，然后对此文件使用MumurHash算法，进行哈希压缩，最后形成cacheId的字符串。具体流程见图3.16。
图3.16 cacheId计算流程
第二段的horizSignature（表2中也有此属性），是在用map构造mapNode时获取map的profile属性时计算。此时，获取map中可以确定空间信息的水平基准面、垂直基准面、地图范围、numTileWideAtLod0、numTilesHighAtLod0属性，这些属性构成的conf属性，同cacheId一样，先转换成Json文件，然后对此文件使用MumurHash算法，进行哈希压缩，最后形成horizSignature的字符串。
所以，缓存的文件名并不是乱码，也是包含了数据源tilesource与map的空间信息的。