1 引言

三维GIS的概念在2000年左右曾被炒得火热，但经过多年的发展最终因为功能简单不能解决更多实际问题而被多数用户冷落。众多的三维项目中看不中用，部分应用单位感到三维应用还仅仅是个面子工程，一度被大众嘲笑为“花瓶”。究其原因无外乎三维应用还只停留在展示阶段，三维城市建设数据组织凌乱，各种数据胡乱放置没有一个统一的组织、管理和维护机制，所谓的二三维一体化更是使用两套数据对二维和三维分开组织管理，不利于管理部门对数据的更新维护。大多数三维厂商为了提高三维场景模型的显示、调度速度，更是事先将通用的模型文件格式，生成自己私有的缓存文件，不利于数据的共享使用。于是人们对三维GIS的期望有所下降，一度因其前期投入较大，后期数据更新维护繁琐，无法发挥其应有价值，而对三维GIS望而生畏。

三维GIS如何才能真正的发挥其实际价值，被政府、企业和大众使用起来呢？显然再采用之前旧的数据存储管理方式是行不通的。为此，行业内的平台厂商们，都在思索如何对数字城市/智慧城市建设过程中所涉及的众多类型和来源的数据进行统一的组织、管理和后期的有效维护。伟景行科技股份有限公司在和数字城市建设的众多单位用户及业内专家讨论交流的基础上，在遵循国际OGC组织对几何要素类型定义的前提下，在CityMaker7研发中率先提出了面向三维数字城市应用的地理特征数据库设计方法——基于多空间列技术对数据进行组织、管理和维护。同一个对象，无论在不同的情境下是以点、面、甚至模型符号、点云模型呈现，都应该由一条要素记录对其进行统一的管理，不同的要素类型要按照国家推荐的建模标准进行制作，不同的业务数据库要依据其实际应用情境和国家推荐的数据库建设方案进行设计，以利于后期数据的共享和应用。

2 基于多空间列技术的场景组织

三维城市场景是现实世界的数字化呈现，在数据组织、管理和维护过程中，不应该割裂数据自身的内在属性而将其人为地拆分成点要素、线要素、面要素等分开存储管理。多空间列技术将要素的几何空间特征和普通的属性信息同等看待，认为一个要素可以像具有多个属性字段存储其属性特征一样，使用多个空间列来管理该要素的不同形态呈现。基于多空间列的数据组织方式一改以往同一要素不同形态的数据分开存储的弊端，将同一要素的不同形态，比如点、多边形、模型、点云等使用多空间列技术封装起来统一管理，可以有效的避免旧的数据存储方式分开存储数据而导致的数据更新不及时，数据更新不同步等问题[1]。另外面向对象的数据管理方式主张数据的管理最小粒度应该是单个对象，而不是以往复杂建筑的某一部分或简易模型组，这种数据组织方式可以很好的解决以往基于模型组件或模型组进行分析不准确的问题，以将传统离散的几何要素数据高度整合在一起，为时空属一体化的地理信息架构设计提供全新的技术手段。

本文以数字北京为例，介绍如何使用基于多空间列技术的面向对象的数据组织方式来进行数据的组织，管理和维护北京的三维场景数据。

2.1 数据库逻辑结构的设计

依据CityMaker7中对地理特征要素数据库的定义，结合国家测绘地理信息局下发的关于三维模型数据库规范的指导意见[2]，在数字北京的场景组织上，使用数据源、数据集、要素类三级结构来管理三维城市场景要素。

数字北京为数据源级别，根据行政区划下设朝阳、海淀、东城、西城等数据集，每一个数据集下都包含建筑物、地面、道路、植被、地下空间、水系、其它七大类要素和专题业务数据，其逻辑结构如图1所示。

图1数字北京地理数据库逻辑结构

2.2 数据组织结构的创建

使用CityMaker平台软件中的CityMaker Builder，依据逻辑结构图创建数字北京地理数据库（图2）。

图2 CityMaker Builder创建数字北京地理数据库

 

在数字北京数据源上，为当前数据库下的要素设置域值约束，比如国道的宽度、道路的材质类型等，在要素类上依据需要创建子类型，比如建筑细分成商业建筑、住宅建筑、办公建筑、工业建筑等；创建属性字段用于存储其属性信息；需要将多种类型的数据一起管理维护的，使用多空间列技术，创建多个空间列，用于存储管理不同的数据类型。比如建筑图层中设置【位置】、【基底】、【模型】、【点云】四个空间列，在数据的存储时，同一个对象要素可以使用一条要素记录来存储管理四种不同的呈现形式，如图3所示。

图3基于多空间列技术的面向对象的数据组织

2.3 地理空间数据的整合

数字北京三维地理数据库可以整合多种类型的数据文件，模型数据类型支持skp、dae、osg、x，矢量数据支持常见的shp、dwg，也可以直接加载存储于Oracle、Sql Server或ArcSDE数据库中的地理数据。

通过多空间列的数据组织方式，真正的实现了数据的二三维一体化管理，在实际业务应用中可以根据需要，设置某个空间列的显示，进行对比分析。

图4多空间列数据展示

3 三维城市场景的更新和维护

和三维场景模型的制作环节一样，数据的更新维护环节，在三维城市的建设中，也要耗费大量的人力、物力和财力，三维模型数据的现势性对三维数据库管理系统的应用只管重要，其准确性影响着系统的分析、查询、统计的结果[3]。一个有效的数据更新维护机制，将可以大大的节约数字城市的维护成本，提升三维数字城市的应用价值。以三维城市中最重的建筑模型要素为例，对其更新维护可以分为三大类。

3.1 对要素基本属性的更新维护

在日常业务中，更新最为频繁的就是对要素基本属性的更新维护，比如建筑的权属人发生了改变，需要对其属性进行更新。CityMaker提供三种数据的更新维护方式，如图5所示。

图5数据的三种更新维护方式

 

直连编辑：数据维护人员可以直接连接地理数据库，对需要修改的要素属性进行修改，实现数据的同步更新，一般适用于较小范围的数据更新；

离线编辑：数据维护人员将地理数据库中的数据签出到本地进行操作，操作完成后再进行签入，从而实现数据的同步更新，一般适用于较大范围的数据更新；

服务编辑：在数据服务发布时，通过对部分用户授予编辑权限，此用户可以通过连接数据服务来实现数据的同步更新，一般适用于较小范围的数据更新。

 

3.2 对要素模型贴图的更新维护

除模型属性的更新维护外，另一个在三维城市维护中占用较大工作量的是对模型贴图的维护，随着时间的推移，城市中的店铺信息发生改变，虽然模型的属性可以通过修改属性值进行简便的维护，但是模型的显示仍然是旧的模型贴图，无法进行同步更新。传统的三维平台软件一般需要重新制作模型再导入到三维场景中，费时费力。CityMaker提供了一种有效的贴图更新维护机制，通过CityMaker Builder产品自带的材质编辑功能，来实现模型贴图的更新（图6）。

图6材质编辑功能面板

3.3 对要素引用模型的更新维护

在CityMaker三维地理数据库中，要素记录是实际操作的对象，三维模型只是要素的符号化表示，当模型的数据的主体结构发生了改变时，需要对要素引用的模型数据重新制作，此类数据维护最为麻烦，但此类数据改动相对较少。针对此类数据更新，CityMaker Builder提供两种方式：

替换模型：通过替换模型功能，可以将所选择的模型替换为导入的单个模型，模型自身的属性信息并不会发生改变。此种方式只使用于同类单一模型的替换；

导入素材：通过导入素材功能，无需选择任何模型，只要将修改后的模型导入即可，程序会自动进行模型名称检测，如发现数据库中已有该数据模型，会弹出同名设置对话框，如图7所示。此时点击覆盖按钮即可实现数据模型的批量更新。

图7同名设置提示

 

4 结语

本文阐述了当前三维城市场景数据组织的现状，并结合实际的例子描述了如何使用多空间列技术对三维城市场景数据进行组织、管理和维护。通过使用基于多空间列技术的面向对象的数据组织方式，可以有效的避免传统数据组织方式将数据分散组织，不易更新、维护的种种弊端，可以将要素的多种显示形态统一存储管理，真正的实现二三维一体化管理，拓展数字城市中各业务部分的具体应用。通过高效、可行的数据更新维护机制，使三维城市场景能够及时地进行更新维护，真正的被用户用起来，喜欢用，目前该方式已成功应用于数字北京、数字澳门、数字新加坡的三维城市场景的组织和维护中。