地理空间信息服务构件技术研究

2014-03-27黄伟杰

地理空间信息 2014年3期

郭勇 , 李敏 , 黄伟杰

（1. 信息工程大学地理空间信息学院,河南郑州 450052；2. 72946部队，山东淄博 255000；3. 77200部队，云南昆明 650000）

地理空间信息服务构件是在当前复杂的应用模式和计算环境下提出的概念[1]。传统的对象技术和构件技术不能满足面向服务计算环境下地理空间信息服务产品的应用开发，而面向服务框架虽然较好地解决了面向服务计算环境下跨平台和异构数据的互操作等问题[2]，但其主要实现技术Web Service 基于SOAP协议和HTTP 协议，传输效率不高。地理空间信息服务构件可提供地理信息服务，并可提供本地调用和网络远程调用等访问方式，通过地理空间信息服务构件可以实现跨平台访问和地理空间数据操作。为了在复杂的应用环境中满足多样化的需求，在基于服务构件的地理空间信息服务产品设计和开发过程中涉及很多关键技术。本文对其中多源异构条件下的空间数据库引擎和面向服务的空间数据综合查询进行了研究。

1 多源异构条件下的空间数据库引擎

空间数据库引擎（spatial database engine，SDE）是地理空间信息服务构件的底层支撑技术。SDE的工作原理是[3]：客户端向服务器端发出请求，服务器端处理请求并将其转换为关系数据库能够处理的事务，然后由数据库完成相应的请求，服务器端再将处理结果实时传递给客户端。

1.1 空间数据存储物理模型

空间数据一般可分为矢量数据和栅格数据。对于空间数据的存储，在关系数据库中常用的有2种方式：一种是使用WKB（well-known binary）来存储空间实体，另一种是使用规范化SQL92方案进行存储[4]。

1）矢量数据存储。根据SQL92标准，BLOB类型是一种标准的二进制大对象类型，可以用来存储WKB描述的空间实体，如表1。其中的Geometry字段可以是由WKBGeometry表示的BLOB字段，也可以是自定义的二进制字段。

表1 矢量数据存储结构

2）栅格数据存储。针对海量的栅格数据，一般采用分层、分块的金字塔结构进行存储。金字塔存储结构是一种多分辨率层次（multi-resolution hierarchy）模型，采用金字塔结构并进行分块存储的数据相关表结构描述如表2所示。其中各数据块都是整体数据的一个子集，是将栅格数据进行无损切割所得。分块时将每块都分成一个矩形，大小可以根据实际应用进行调整，常见的大小有64×64、128×128和256×256等若干种。存储时，将数据块的数据和相应级别、行列号、外接矩形坐标等一并进行存放，以便按索引进行数据的快速提取。

表2 栅格数据存储结构

1.2 异构数据库的访问接口

对于网络应用来说，数据可能以异构的方式分布式地存储于网络上的各个节点，地理空间信息服务构件的空间数据库引擎应该向上层应用屏蔽底层数据存储方式的异构性，提供统一的访问接口。

SQL语言是一种结构化的查询语言，其特点是不依赖于特定的操作系统和特定的关系数据库；同时，SQL也是一种规范，是不同数据库管理系统共同遵循的语言规范。但在实际中，各数据库系统的实现仍存在很大差异，成为异构数据库统一访问接口的障碍。

在实际应用中，每种数据库都有自己的一组基本数据类型，而且各数据库对基本数据类型的定义存在着差异。表3为几种常用数据库的对应参数类型。

表3 数据库基本类型对比

图1 统一SQL接口实现流程

同时，各数据库在SQL语法的定义上存在差异，所采用的保留关键字也不尽相同。这些差异导致一些SQL语句在一个数据库中能够执行，而在其他数据库中变为非法语句。为了解决这一问题，需要对SQL语句进行分解翻译，然后再进行校验和执行，如图1所示。

当接收到查询请求时，系统将其进行分解翻译，并根据不同的数据库类型将其翻译为相应的SQL语句；经过校验后进行执行，并返回查询结果。这一过程需要各数据库参数的对应关系，如图2所示。

图2 各数据库SQL语法参数UML关系图

从图2中可以看出，类ParameterLisBase为参数列表的抽象基类，往下可以派生出针对各个数据库的参数列表类，如OdbcParameterList类、OracleParameterList类等；如果需要扩充对一个新数据库的支持，只需在ParameterLisBase基础上再派生出一个相应的类进行实现即可，对原结构和系统的调用方式不需要改变。

2 面向服务的空间数据综合查询

用户查询涉及多个空间数据集是很常见的情况，需要对多样化的数据进行分析和挖掘，从多个数据集中提取用户关心的数据，并提供从图到文、从文到图和从文到文等多种查询方式，如图3所示。

为了实现图、文、库的一体化查询应用，需要在空间数据库基础上建立专题信息库和空间数据库之间以及专题信息库和专题信息库之间的联系。

例如，要查询某区域内影响装甲车辆通行的桥梁隧道情况，就涉及公路、桥梁隧道及武器装备属性等3个数据集。当这3个数据集分别位于3个不同的数据库时，空间数据集成系统需要合并这3个数据服务的中间结果集才能得到一个满足用户需求的最终查询结果，我们称该过程为集成多元空间连接查询。

空间数据库中处理多元连接查询一般采用两阶段处理方式，即查询编译阶段和查询执行阶段。在查询编译阶段，对查询命令进行分解和优化，产生一个执行代价最优的查询计划；在查询执行阶段，查询执行引擎严格执行该查询计划。

在局域网或本地应用中，通过服务构件提供的API函数直接调用接口分别在不同的库中进行查询并将结果进行合并即可；而在面向地理数据服务的空间数据集成系统中，集成查询处理器对空间数据的访问是通过调用外部接口实现的，因此，常常需要对动态生成的GML文档进行进一步空间连接查询才能得到用户需要的查询结果。

图4 专题信息和空间信息的关联方式

图5 关键字库的应用

2.1 多元空间数据关联

地理空间信息查询通常分为两类：基于属性的查询和基于空间位置的查询（空间关系查询）。基于属性查询是通过对空间对象的属性信息设定一定的条件来查询空间位置，主要包括字符型字段查询、数值型字段查询和复合型查询3种。基于字符型字段的语句通常使用“=”和“LIKE”进行SQL查询。基于数值型字段的语句通常使用比较操作运算符（>，<，=，<=，>一）和运算符（+，-，*，/）完成。复合查询通常采用“AND”、“OR”或“NOT”等逻辑运算符完成。

要实现不同空间数据库之间的关联查询，特别是属性数据库和空间数据库之间的关联应用，需要建立不同空间数据库之间以及空间数据库和属性数据库之间的关联关系。如果所有的数据库都由我们自己维护，则只需通过唯一的ID值建立空间数据和属性数据之间的关联即可，但在地理空间信息服务构件的应用中，空间数据库和专题数据库可能来自于远程，由别人进行维护，我们不能预先建立它们之间的联系，只有在应用时才能动态地建立关联。在动态关联的过程中，如果专题信息带有空间坐标信息，则直接通过坐标进行空间关联即可；但有些应用中，专题信息可能没有空间定位信息，只有文本描述，这就需要我们从中挖掘出隐含的空间信息并进行关联应用。