基于MySQL Spatial的矢量空间数据存储与查询

黄 鹏

(长江工程职业技术学院， 武汉 430212)

定位技术与地理位置服务的广泛应用，使得空间地理信息在智慧城市建设中占据重要位置。与传统数据相比，空间数据具有数据量大、非结构化、分类编码、空间位置相关、更新速度快等特点。目前空间数据库有两种主流技术模式：一种是采用空间数据引擎+关系型数据库的中间件技术，如ESRI公司的ArcSDE。另一种是关系数据库+空间功能扩展的对象关系型数据库融合模式，由数据库厂商专门实现，如Oracle Spatial，PostGIS，Mysql Spatial等[1]。

1 对象关系型空间数据库

对象关系型数据库采用关系模型组织属性数据，按对象存取空间数据，实现了在数据库内核中进行空间操作和处理，其优点是扩展SQL比较方便，较易实现数据共享与互操作[2]。目前市场上流行的三种对象关系型空间数据库分别是Oracle Spatial，PostGIS和Mysql Spatial。

Oracle spatial 是Oracle数据库为实现快速、高效地存取分析空间数据而推出的专用组件。Oracl Spatial定义了一种可自定义的空间对象类型SDO_Geometry，在该类型中，可以进一步定义数据的几何体类型、空间参考坐标系、数据结构、坐标值信息等。Oracl Spatial还提供了四叉树、参照树等空间索引方案，支持直接在SQL语句中调用完整的空间操作函数，极大地提高了空间数据的查询效率。Oracle Spatial实现了非结构化、有嵌套关系的空间数据与属性数据的统一存储和管理，为空间数据的管理和利用带来方便。

PostGIS是在开源数据库Postgre SQL基础上研发出来的空间功能扩展插件，它弥补了Postgre SQL在空间数据管理上的缺陷和不足。PostGIS支持几乎所有的空间数据类型，如点、线、多边形、复合点、复合线、复合多边形，也支持所有的数据存储和构造方法。PostGIS提供了Union(求并)、Difference(求差)、Distance(求距离)等空间分析函数来操作空间数据，也提供二元谓词来监测空间对象之间的空间关系[3]。此外，PostGIS还提供了空间坐标系转换、空间聚集函数、栅格数据切片缓存等功能，拓展了空间数据管理能力，在目前的开源GIS建设方案中占据重要地位。

MySQL是最初由瑞典MySQL AB公司所研发的中小型数据库管理系统，据数据库权威网站DB-Engines统计，2020-2022三年间，MySQL牢牢占据数据库排行榜第二名的位置。MySQL从4.0版本开始加入了Spatial模块，简称为MySQL Spatial。该模块遵循了美国OGC协会提出的开放式地理数据互操作规范，支持空间几何数据类型，并实现了相关的空间操作函数和空间索引方法。随着8.0版本的推出，MySQL Spatial在空间操作功能方面逐步完善，引入了地理参照坐标系，丰富了空间分析函数，又因其开源免费、知名度高等特点，已成为空间数据管理的优选方案之一。

2 MySQL Spatial空间扩展

2.1 空间数据类型及存储格式

Mysql Spatial实现了OpenGIS规范的一个子集，实现了有限的空间几何数据类型[4]，如Geometry(几何基类)、Point(点)、LineString(线)、Polygon(面)等基础数据类型，和MulitPoint(复合点)、MultiLineString(复合线)、MultiPolygon(复合面)、GeometryCollection(几何集合)等复杂数据类型。Mysql Spatial已支持的几何数据模型如图1所示。

图1 MySQL Spatial支持的几何数据模型

Mysql Spatial采用三种数据格式WKT、WKB、内部存储格式来描述空间数据的几何结构。WKT(Well-Known Text format)是一种文本标记语言，用于表示地图上的矢量几何对象、空间参照系以及空间参照系之间的转换。如将点对象表示为POINT(x y)，线对象表示为LINESTRING(x1 y1,x2 y2,…,xn yn)，而面对象则采用内环坐标加外环坐标的形式来表示，如POLYGON((x01 y01,x02 y02,…,x0n y0n), (x11 y11,x12 y12,…,x1n y1n))。

WKB(Well-Known Binary Format)格式以二进制流的形式交互几何数据，将几何信息存储在BLOB值中。如一个点状对象表示为21个字节的二进制数，其中1个字节代表字节序、4个字节代表几何类型、16个字节代表双精度x坐标、y坐标。线状和面状对象则保留前部“字节序和几何类型”的位置，剩余的字节由子对象数目和子对象的坐标数组共同决定。

内部存储格式是Mysql实际存储几何对象的数据格式，它与WKB格式不完全相同，而是在二进制数的头部再加4个字节表示空间参考系的ID(SRID)值，如WGS84坐标系的SRID为4326。这样一个点状对象在Mysql中的实际存储长度是25个字节。

2.2 空间索引

为了提高空间数据的搜索效率，MySQL Spatial支持为空间数据添加R-Trees(R树)空间索引[5]。R树索引将空间对象按范围进行划分，分为叶节点和非叶节点。其中叶节点不可再分，由空间对象的最小外接矩形(MBR)构成。非叶节点是可以再分的节点，也称为父节点，它由所有子节点的公共外接矩形MBR构成，并存储有指向各子节点的指针。自8.0版本以后，MySQL Spatial支持为MyISAM和INNODB存储引擎的数据表添加空间索引，添加索引的关键字为SPATIAL INDEX，且添加索引的字段不能为空。

2.3 空间处理函数

MySQL Spatial也提供了大量的空间处理函数来操作空间数据。这些函数可以分为以下5类：几何对象构造函数、格式转换函数、几何属性访问函数、空间关系函数和空间运算函数，如表1所示。在MySQL 8.0版本以前，空间函数的操作都是在几何平面(笛卡尔坐标系)下进行，没有考虑几何对象的空间参照关系。而在MySQL 8.0版本中，空间函数已经支持同一坐标系下的几何空间运算，极大地扩展了MySQL的空间数据处理能力。

表1 Mysql Spatial空间函数表

3 矢量空间数据存储与查询

为了验证MySQL Spatial在空间数据存储管理上的有效性，选取湖北省行政区划数据(面类型)与绿地公园数据(点类型)为样本，通过Shapelib开源库实现Shapefile矢量格式数据的读取，再调用Mysql Connector Net驱动程序的API接口，将其转存到Mysql数据库中。

3.1 Shapefile矢量数据读取

Shapelib是采用c语言编写的轻量级地图工具，在.net环境下，可以通过DLLImport方法将其引入到c#语言中使用(注意指针与IntPtr、数组等参数的转换关系)，也可以使用SharpShape版本来读取数据。Shapelib读取Shapefile数据的具体过程如下：(1)通过ShapeOpen()函数获取文件句柄，调用SHPGetInfo()和SHPReadObject()函数读取要素的几何类型和坐标数据；(2)通过DBFOpen()打开属性数据，再通过字段处理函数读取字段类型及属性值；(3)读取.proj投影文件信息，根据空间参考规范，确定数据的SRID值。由于Mysql目前仅支持同一空间参考系下的函数运算，因此统一定义数据坐标系为WGS84，其SRID值为4326。Shapefile文件的读取及存储过程如图2所示。

图2 Shapefile矢量文件读取及存储过程

3.2 创建空间数据库与数据表

在数据库中，通过SQL语句“Create database myGIS; use myGIS;”创建并打开空间数据库。由于Shapelib读取获得的字段类型与Mysql数据库中的字段类型不完全一致，因此在创建数据表之前，需要确立两者之间的转换关系。几何数据类型直接转换为Mysql支持的几何类型，而字符串类型和数字类型在转换时还要保留数据的长度和精度信息。如表2所示。

表2 Shapelib读取字段类型与MySQL字段类型对比

根据空间数据的特性，几何坐标信息采用Point、

Linestring、Polygon几何字段类型保存，属性信息采用Mysql基础数据类型保存。通过SQL语句“Create Table Name()”创建空间数据表，其建表过程如下：加载Mysql-connector-net驱动程序，根据之前读取到的几何字段类型和属性字段类型，确定空间数据表的各个字段类型，创建对应的数据表。由于Mysql Spatial的空间函数已支持同一坐标系的空间运算，因此在建立几何字段的同时，需附加空间参考约束‘SRID 4326’。建立行政区划数据表的Sql语句如下所示：

CRETTETABLEhubeiRegion(FIDintprimarykeyauto_increment, -- 主键

SHAPEpolygonnotnullSRID4326,-- 几何字段

NAMEvarchar(30), -- 区划名称

KINDvarchar(4), -- 分类码

ADMINCODEvarchar(6), -- 行政编码

PROVINCENAvarchar(50)); -- 所属省份名称

3.3 插入空间数据

数据表建好之后，将Shapefile中的坐标数据转为标准SQL语句“Insert into values”插入表中。(1)将空间坐标数据逐一转为WKT文本格式，纬度在前，经度在后；对于线、面对象，需要逐一获取其子对象Part的坐标串数据，再附加其空间参考ID，以保证与数据表的结构相一致；(2)利用Mysql Spatial提供的ST_GeomFromText()函数逐一构造几何参数；(3)依据shapelib读取得到的属性数据，补齐其余的属性字段参数；(4)调用API接口的ExecuteNonQuery()方法，执行SQL语句向数据表插入一条记录。插入空间数据后的行政区划表如图3所示。

图3 MySQL空间数据存储

3.4 空间查询与索引

空间数据转入数据库后，还需要建立空间索引，

为后续的空间查询做好铺垫。空间索引的方法默认为R-Tree索引。其创建的方法是在几何字段上建立R树索引约束，关键字为Spatial Index。创建索引之前，还要确保空间索引字段不为空(非空约束)，且数据表的存储引擎为InnoDB，以支持地理空间参考下的空间查询功能。建立空间索引的SQL语句如下所示。

ALTERTABLEhubeiRegionADDSPATIALINDEX(shape);

(1)以查询“与武汉市接壤的市级行政区划”为例，实现行政区划图层内部的空间邻接关系查询。由于ST_Touches()函数在8.0.27版本中不能良好支持地理空间坐标系下的关系运算，因此可利用空间拓扑关系的映射不变特性，将其置于平面坐标系(SRID:0)来间接判断要素间的空间邻接关系。SQL查询语句如下，查询结果如图4(a)所示。

图4 MySQL空间查询结果

SET@g= (SELECTST_SRID(shape,0)fromhubeiregionWHERENAME=“武汉市”);

SELECTNAME,ST_AsText(shape)FROMhubeiregionWHEREST_Touches(@g,ST_SRID(shape,0));

(2)以查询“武汉市行政区划内的绿地公园”为例，实现行政区划图层与绿地图层的空间包含关系查询。Mysql Spatial提供ST_Contains()函数来判断实体要素间的空间包含关系。SQL查询语句如下，查询结果图4(b)所示。

SET@g= (SELECTshapefromhubeiregionWHERENAME=“武汉市”);

SELECTNAMEFROMgreenlandWHEREST_Contains(@g,shape)limit14;

3.5 查询结果分析

将上述样本数据导入PostGIS 14中，与Mysql Spatial的查询结果作对比分析。评测指标采用服务器执行SQL语句的实际查询用时，排除查询缓存和客户端渲染技术对结果的影响，对比结果如表3所示。(1)数据导入方式：PostGIS提供了工具命令shp2pgsql及图形化界面来导入Shapefile数据，导入后的坐标数据被定义为Geometry类型；而Mysql Spatial不提供shapefile文件导入功能，本文中使用shapelib第三方库实现；(2)空间关系判断：以“市内绿地”(点-面包含)及“行政区划接壤”(面-面相邻)的关系判断为例，在不考虑空间参照系时，PostGIS中的查询时间分别为67ms、116ms，Mysql Spatial中的查询时间分别为88ms，48ms，后者总耗时少于前者。而在代入地理参照系后，前者的查询时间几乎没有变化，而后者的“包含查询”用时增加到508ms，且无法直接判断邻接关系，提示Mysql在空间关系的判断上还存在不足；(3)距离量测与边界查询：两者均提供了ST_Distance()函数进行地面距离的测算，在PostGIS中需要将Geometry几何对象转为Geography地理对象，才能获得大地距离。以“白玉公园”到“新城广场”中心点的距离为例，在PostGIS中的测量值为13 802.145m，耗时71ms，在Mysql中的测量值为13 802.158m，耗时66ms。另外，在读取面要素的几何边界(武汉市行政边界)时，两者分别用时75ms、31ms，说明在不考虑空间关系运算时，Mysql的计算速度略优于PostGIS；(4)空间索引：PostGIS综合使用了R树与GIST索引两种方式，而Mysql采用的是R树索引，这也是导致两者查询效率产生差异的因素之一。

表3 Mysql Spatial与PostGIS查询结果对比

4 结 语

随着8.0版本的推出，Mysql Spatial进一步丰富了其空间处理函数，引入了地理坐标系和投影坐标系，并支持同一参考坐标系下的空间运算。其空间运算性能虽然相比PostGIS还有差距，但已能实现基于地理实体的空间关系判断与距离测量，读取几何数据较快，具备了在中小型GIS系统中存储和管理矢量数据的能力。研究中也发现，Mysql Spatial 8.0在地理坐标系下的邻接关系判断不够完善，其空间分析函数不如专业的GIS应用软件丰富。因此，Mysql Spatial未来可能会继续专注于空间数据存储、管理与查询功能的完善，而将专业的地理分析功能交由商业GIS软件来实现。