三维GIS数据的管理

构成三维GIS的数据主要包括两大类：立体三维模型 （包括三维精细框架、模型纹理、点云模型） 及背景三维数据（DEM、DOM和DLG等）， 对三维数据的管理是个巨大的挑战，会遇到一系列问题：

（1）几何数据量极大： 几何数据包括以DEM数据为主的地形信息和构成地面模型的三角形数据。 如果这些数据不经过适当的简化和优化， 在绘制大规模场景的过程中将会产生数量惊人的构造三角形， 影响数据的可视化效率； 而采用LiDAR技术获得的三维模型点云数据更是惊人， 一个较大范围的数据量可以轻易达到TB级别。

（2）纹理数据的数据量庞大： 纹理数据包括地面影像和地面模型所用到的纹理贴图。 大范围的三维场景意味着需要很大的地面影像， 纹理数据的数据量很可能会超过现有个人桌面计算机系统的物理内存。

（3）地物繁多，导致碰撞检测、属性査询等功能实现难度增加， 数据冗余度大，为数据管理带来极大困难。

（4）极大的数据量最终导致基于Web的三维可视化和分析困难重重， 要在浏览器中获得单机版上的精细数据效果几乎不可能完成。

对于海量三维GIS数据的管理，一直是三维GIS必须面对的一个技术难题， 目前三维数据的存储方式主要有三种：文件型数据系统、 文件数据库和关系型数据库。文件型数据系统是一组文件的集合， 它通过采用一定规则的分类排列和直接索引方式， 使三维GIS软件能够简单快捷地调用数据，但此方式的安全机制较低， 文件容易被修改或复制，同时对于大规模数据集而言存在容量限制； 文件数据库指单机版本的文件型数据库，如Esri的Geodatabase数据库、 SuperMapSDK+、mdb文件数据库、SpatiaLite等， 这些文件型数据库能够在一个独立的二进制文件内部对数据进行组织， 提供表和索引机制，并在特定API支持下像关系型数据库管理系统 一样执行SQL操作;关系型数据库则是以大型商业关系数据库为存储空间， 如Oracle Spatial或SQL Server的二进制格式数据作为存储单元。

传统基于文件与关系数据库混合的三维GIS数据库管理方式在数据安全性、 多用户操作、网络共享及数据动态更新等方面已逐渐不能满足日益增长的需要。 现有的对象关系型数据库管理系统已经开始直接支持三维空间对象， 在保留关系数据库优点的同时，也采纳了面向对象数据库设计的某些原理， 具有将结构性的数据组织成某种特定数据类型的机制， 这使得它不仅能够处理三维数据的复杂关系， 也能将逻辑上需要以整体对待的数据组织成一个对象， 这为三维GIS的海量数据管理提供了一条切实可行的途径。

除此以外，目前还出现了专门的三维数据库， 如3D City Database是由柏林工业大学开发的免费三维地理数据库， 用于存储、表现和管理城市三维虚拟模型， 该数据库需要搭建在一个空间关系数据库——如Oracle Spatial llg之上， 其角色类似于SDE这种中间件产品。 3D City Database的数据库模型建立在CityGML之上， 后者是一种用于三维城市模型表示与交换的中间标准和通用信息模型， 定义了城市中的大部分地理对象的分类及其之间的关系， 并且充分考虑了区域模型的几何、拓扑、语义和外观属性等信息。 这些专题信息不仅仅是一种图形交换格式， 而且允许将虚拟三维城市模型部署到各种不同应用中完成复杂分析任务， 例如实景仿真、城市挖掘、设施管理等。

除了这些趋势，随着NoSQL技术的发展， 目前也有人开始尝试使用如MongoDB等非关系型数据库存储二维和三维GIS数据。 MongoDB是一个髙性能的开源和无模式文档数据库， 它在许多场景下可用于替代传统的关系型数据模式或键值存储模式， 具有海量和可扩展的文件存储能力， 在数据存储上特别适合三维海量数据特征， 能够将所有的三维数据都进行集中式存储。 但它并没有特定的三维数据模型， 也尚未针对三维数据的检索与査询提供实现机制。 因此，使用NoSQL数据库尚有很长一段路要走。

三维GIS数据库的管理，最终要实现的是二三维一体化， 这些一体化包括数据管理一体化、空间符号的一体化、 三维表达一体化和分析功能的一体化。