古建筑三维模型数据库系统设计

吴志群

（北京北建大科技有限公司，北京100000）

1 概述

图1 数据库系统架构图

古代建筑是中国古代辛勤劳动人民集体智慧的结晶。许多古代建筑都是文化考察与旅游的重要场所，它是研究我国古代经济、文化、政治、科技发展的重要实物资料。中国古建筑不仅是现代建筑文化传承、技术创新的重要借鉴，更是中华五千年文明发展的重要载体，同时也因其特有的艺术风格，在世界各国建筑风格中脱颖而出，成为一种独特的建筑体系。然而伴随着现代社会的快速发展、全球气候日益变暖、极端天气日益增多等多方面因素影响，许多具有高艺术价值的古建筑正面临被人为或环境破坏的危险，而这些急需保护的古建筑，有些仅是拥有文字、图片等不易反应古建筑真实样貌的简单资料，有些甚至有些没有任何资料保存，仅有的那些资料也是在纸上以文字记载的形式进行记录，没有完整的数字形式的数据资料妥善保存，随着时光的流逝他们很可能被损毁或丢失，一旦这些古建筑被破坏，无法得到有效的修复，可能将永远消失于人类的视野中，这对于中华文明乃至世界文明都是不可弥补的巨大损失[1]。

图2 数据库逻辑视图

通过探索多元化的古建筑保护途径，高效、直观并且完整的保存古建筑各类数据信息已成为国内外古建筑保护单位急需解决的问题。传统古建筑保护单位对于古建筑的数字化保护方式为拥有该古建筑的影像照片、尺寸大小等图文资料，且这些资料均以文件型的存储方式散乱的存储于硬盘等各类存储设备中。通过文字资料保存古建筑数据的方法比较抽象，无法真实的反应古建筑的样貌，且数据量庞大，查找困难；利用影像照片存储古建数据的方法虽然比较直观形象，但很难达到古建筑修复时所需要的精度，无法满足科学研究以及古建筑修复、重建的要求。并且古建筑数据信息以文件型的存储方式存储于各类存储设备也面临着数据冗余过大、查找困难、无法共享等一系列问题。针对古建筑数字化多源数据存储的问题，建立基于数据库存储技术的古建筑数字化数据库系统是当前研究的热点。

2 数据库系统总体设计

古建筑数据库后台管理系统主要依托关系数据库系统、分布式文件系统两种关键技术，对古建筑三维点云、古建筑三维模型、古建筑构件、古建筑影像、电子档案、属性等数据进行管理。关系型数据系统采用Postgresql+postGIS 方式，基于多分辨率金字塔中的关系模型构建二维行列关系表格，依托于SQL 语言实现数据的查询、更新、添加、删除等处理操作。分布式文件系统主要通过非关系型HDFS 文件系统存储文件数据，支持存储节点的动态增添、海量数据的读写、高并发访问等。

PostGIS 数据库子系统和HDGS 分布式文件子系统来设计一个适于大规模空间数据的存储与管理系统，其具体体现如下：

图3 TIN 模型的子集结构图

2.1 对于点云、模型等基础数据，构建分层分块的多分辨率金字塔，从而方便数据的更新、重组与删除。

2.2 基于PostGIS 关系型数据库，实现多分辨率金字塔数据的快速索引、查询、编辑等。

图4 TIN 数据E-R 模型

2.3 基 于 HDFS (Hadoop Distributed File System)实现对大文件、松散型文件的处理以及分布式存储，并将其作为数据的底层存储系统。

2.4 基于MapReduce 并行编程模型，实现数据的并行处理。

2.5 基于HBase 分布式数据库，实现非结构化数据的存储管理（图1）。

古建筑数据库管理系统将分为数据库维护（权限管理和系统数据备份与恢复）数据管理通用模块、点云数据存储模块、三维模型数据存储与管理、古建筑构件[2～3]数据存储与管理模块、影像数据存储与管理模块、电子档案数据存储与管理模块、属性数据存储与管理模块等6 大模块。本子系统将提供上述的大文件、松散型文件处理，保存与提取，文件分布式存储，支持高效的局部更新和全局更新，数据检查、入库和发布，数据并行处理6 个工具分别对应这9 个模块（图2）。

根据业务需求可以将子系统的各种功能划分到不同模块中实现，以提供相互之间的合作。子系统主要的模块功能主要有如下功能：

（1）数据管理通用模块，主要包括，提供数据管理的用户界面和实现与各类数据管理模块的对接。

（2）点云与影像数据存储与管理，支持结构化点云存储，非结构化影像存储，分布式存储，单瓦片点云数据编辑、保存与提取；高效的局部更新和全局更新；对接数据处理工具，提供数据检查、入库和发布等一揽子流程化功能；数据并行处理。

（3）三维模型数据存储与管理，支持OBJ、3DS 等主流格式的模型存储；模型LOD 形式存储；单瓦片模型数据编辑、保存与提取；BIM模型数据存储

（4）古建筑构件数据存储与管理，支持大文件、松散型文件处理；构件分类管理；构件检索；构件上传下载。

（5）档案资料数据存储与管理，支持档案多文件管理；档案按编码、按类型存储；数据全局与局部更新；对接数据处理工具，提供数据检查、入库和发布。

（6）数据库安全，支持用户管理权限设置；支持数据备份与数据恢复；支持多节点数据调取。

（7）满足C/S、B/S 交互访问。

3 古建筑三维模型数据库设计

古建筑三维模型数据模型总的关系图以三维线框、表面、实体模型[4～5]为例进行说明，三维体的基本要素可以抽象为点、边、线、面、实体和复杂体，呈现出由简单到复杂的递进关系。其中，根据线框的特性，建立了线框模型（WireFrame），包含一系列顶点以及由顶点连接的棱边；表面模型（surface）是在线框的基础上，加入环边的信息及边的连接关系；仅仅依靠表面模型，无法判别实体与表面的位置关系，实体模型（正则形体）主要是明确定义了表面的哪一侧存在实体，具体做法是，在表面模型的基础上增加了每个表面的外法矢量信息。这几种模型可作为复杂体(Compound)的三种表达方式，下面具体讨论古建筑复杂体的数据库存储结构。

图5 线框、表面、实体模型E-R 模型

3.1 不规则三角网（TIN）模型

TIN 模型是利用点云进行三维重构生成的三维模型，是多源空间数据应用最多的数据之一。一个场景对象一个或多个TIN 模型构成，TIN 模型主要由顶点列表、子集结构、材质、矩阵参数以及组件名称组成。

TIN 模型中，顶点列表包括位置信息、法线、纹理坐标组成；子集信息（如图3 所示）包含顶点列表、材质名称、材质对应的资源视图、子集对应的索引缓存的开始位置、子集对应的顶点数目以及材质对应的影像数据、光照模型，因此设计如图4 所示的TIN 数据模型。

以下TIN 模型中数据结构说明：

Struct ModelVertex 存储顶点数据结构，包含顶点坐标、纹理和法向；

Struct ModelSubMesh 存储子集结构，包含对应材质索引、子集对应的索引及索引数目；

Struct ModelSubMaterial 子集材质结构，包含影像、材质反射率；

Struct TriModelMesh 模型构件结构，包含顶点集合、面片索引集合、子集索引集合、材质集合、矩阵集合、组件。

3.2 线框、表面、实体模型

表示线框、表面、实体模型[6～7]的数据结构，如图5 具体如下：

3.2.1 复杂体（Compound） 表包含一个标识信息CompoundID，一些属性信息Attribute1、Attribute2… ，PartID 对应WireFrame、SurfaceModel、RugularShapeSolid 三张表的里标识信息，SolidTypeID 对应SolidType 表里的标识信息，SolidType 表主要用于确定SolidTypeID 对应的是WireFrame、SurfaceModel、RugularShapeSolid 中哪一种模型，如表1 所示。

3.2.2 WireFrame、SurfaceModel、RugularShapeSolid 三张表分别存储线框模型、表面模型和正则形体模型；

3.2.3 线框模型使用顶点和邻边来表示形体，可以作为多面体的一种表达方式，用来确定多面体的形状和位置，这种方式被广泛用于工程图。WireFrame 表使用二进制格式存储顶点（BVertex）和邻边（VertexIndex），邻边是使用顶点的序列来构成，另外使用了一个标识（WireFrameID）来表示该线框模型；

3.2.4 表面模型是通过有向棱边围成的部分来定义形体便面，由面的几何来定义形体，它基于线框模型的基础上，增加了有关（环）信息、棱边的连接方向等内容，使用表SurfaceModel 来存储，该表包含一个标识SurfaceModelID 和在面标识序列SurfaceIndex，其中SurfaceIndex 是标识在表Surface 里面存储的面的ID 集合，表Surface 就存储形体的各个面信息，该表包含面标识SurfaceID 和线框标识WireFrameID 以及棱边的序列索引；

3.2.5 正则实体模型，主要是明确定义了表面的哪一侧存在实体，在表面模型的基础上增加了每个表面的外法矢。因此表RugularShapeSolid 中包含标识RegShID，表面模型标识SurfaceModelID，以及使用二进制存储的各个面外法矢向量的集合OuterVector。

表1 SolidTypeID 与模型的对应关系

4 结论

本文主要针对古建筑数据库系统建设，提出了基于三维激光扫描仪获取的三维激光点云数据、高分辨率影像照片、三维模型以及属性数据等多源数据的古建筑综合数据库系统的存储模型，重点研究了古建筑不规则三角网模型，线框、表面和实体模型的实体表达方法，并进一步阐述了维模型数据库存储的数据结构。本文的古建筑数据库存储技术与方法为古建筑数字化保护提供技术支持。