开源空间数据引擎MsSQLSpatial介绍及探讨

编者按:所谓的空间数据引擎，其实就是基于关系型数据库的空间数据库技术的软件实现，实质上是个封装了空间领域知识的中间件，GIS等应用层通过这个中间层与关系型数据库交互。典型的莫过于GIS开发者都比较熟悉的ESRI ArcSDE，Supermap SDX＋等等。那么，这个MsSQLSpatial与以前的空间数据引擎差别在哪里？

引言

本文依托介绍开源空间数据引擎项目MsSQLSpatial，对基于MS SQLServer 2005 CLR Integration（公共语言运行时集成，下文简称“CLR集成”）技术实现一个空间数据引擎及优缺点做一些探讨。

MsSQLSpatial项目介绍

这个项目遵从于OGC Simple Features Specification for SQL Revision 1.1，基于两个著名的.NET平台下的开源GIS项目NetTopologySuite(NetTopologySuite是JTS Topology Suite的C#/.net版本，简称NTS)和SharpMap(一个基于.net 2.0的Map渲染类库)来构建，

所以划分为NTS、SharpMap和SqlClr三大模块，SqlClr这部分为CLR集成实现代码。主要实现了基于SQLServer 2005 CLR集成的空间数据库相关封装。当前提供了一个命令行工具来支持shape文件和PostGIS的数据导入。

开发语言：C Sharp 2.0

目前版本：Release 0.1.RC2。

许可协议：GNU LESSER GENERAL PUBLIC LICENSE Version 2.1

官方网址：http://www.codeplex.com/Wiki/View.aspx?ProjectName=MsSQLSpatial

MsSQLSpatial官方给的说法是一个MS SQLServer2005空间扩展（Spatial Extensions），确切的说它应该是一个专属于SQLServer2005的空间数据引擎。所谓的空间数据引擎，其实就是基于关系型数据库的空间数据库技术的软件实现，实质上是个封装了空间领域知识的中间件，GIS等应用层通过这个中间层与关系型数据库交互。典型的莫过于GIS开发者都比较熟悉的ESRI ArcSDE，Supermap SDX＋等等。那么，这个MsSQLSpatial与以前的空间数据引擎差别在哪里？下文我们将讨论这个问题。（实际上Oracle 10g也支持CLR集成，但在此不进行相关比较。）

基于CLR集成的空间数据引擎

显而易见，每一次数据库技术与数据访问技术的进步发展都会带动空间数据存储管理解决方案的进步与发展，就好像关系型数据库上BLOB数据类型的支持才使得空间数据库实现了空间特征数据与属性数据一体化存储管理。关于MS SQLServer 2005如何如何的新特性在这里笔者就不打算给微软做广告了，相信微软强大的宣传机器早就把这个近千人耗时5年开发出来的重量级产品吹嘘得天花乱坠。且不管广告如何，作为一个与整个.NET平台紧密集成的全新一代的数据库产品，我们更关心它的新特性会给GIS最重要的组成部分之一“空间数据库技术”带来什么样的解决方案。这个关键，就是它的“CLR集成”。通过宿主 Microsoft .NET Framework 2.0 公共语言运行时 (CLR)，可以在SQLServer 2005上利用.NET Framework 类库和任何如C#、VB.NET、C++/CLI等CLR 语言来开发数据库应用，扩展用户自己的类型系统和聚合函数。许多之前在SQLServer 2000上用T-SQL或扩展存储过程等编程模型难以实现的或无法实现的任务现在可以用托管代码来完成，譬如几何计算这样具有复杂逻辑的计算密集型任务。

<!--[if !vml]--><!--[endif]-->在空间数据库的设计问题上，没有CLR集成技术的RDBMS例如SQLServer2000，在涉及查询脚本的空间表达时就出现了问题，T-SQL语句难以做到空间关系和属性特征联合查询。因此空间索引和以二进制方式存储的空间特征数据都必须通过数据访问接口获取出来映射到空间数据引擎这个中间层还原成空间对象才能完成空间关系的判断。还有点不妙的就是每次涉及空间分析的操作都会从空间数据库服务器中取出一部分冗余的结果集，如果在I/O密集的情况下则更糟。SQLServer 2005上，非常显著的一个特点是，这类基于CLR集成的开发的.NET应用程序集是直接部署在数据库服务器上，SQLServer2005在进程内宿主.NET CLR，外部GIS应用层可直接与空间数据库交互时使用T-SQL语句完成属性谓词和空间谓词查询操作。本质上还是在空间数据库中使用两步查询机制，首先使用索引查询出候选对象集，然后再采用精确的几何计算，在候选对象集中求出精确解。我们来看MsSQLSpatial的解决方案， MsSQLSpatial用CLR表值函数封装了一组简单而有效的空间索引实现，在这些CLR表值函数中实习了OGC简单特征规范定义的用于描述各种对象的空间关系的空间关系谓词，由NTS类库提供底层的空间对象和空间关系算子，在数据库进程内部直接完成空间查询操作。需要补充说明的是，由于SQLServer2005 CLR UDT（用户自定义类型）8000字节的最大限制，导致无法实现定义空间数据类型，所以在MsSQLSpatial是使用了聚合函数来克服这个问题。这点比较令人遗憾，若然可以实现相当优雅的空间查询语言。

SQLServer2005数据库CLR集成技术代码和数据的紧密结合使我们能够充分利用服务器的处理能力。而且因为它减少了数据层和中间层之间的流量，CLR 函数也可以利用到SQLServer 2005查询处理器的并行和优化功能。但如果在空间数据引擎中完全封装，这无异于把密集计算的任务完全放在空间数据库服务器上。在空间数据库的I/O量与计算资源之间如何取舍，这是值得斟酌之处。

MsSQLSpatial展望

MsSQLSpatial是开源GIS网站Freegis.org于今年八月份才加入的一个新的开源项目，更新比较频繁。正由于其刚刚开始，可能作者忙于调整架构和实现相关应用，所以相关文档和介绍相当的少，对其长远的发展规划和定位还不得而知。

这个新生的开源项目目前还比较简单，没有提供构建高级空间索引的能力，进行空间查询时其仅是对最小外包矩形（MBR）比较后获得粗略子集后就通过一个委托调用NTS中空间对象的操作算子进行精确的匹配计算以获得目标结果集。MsSQLSpatial目前也没有栅格数据相关部分，要达到海量矢量/栅格管理，拓扑关系支持、长事务、日志、多用户并发、权限控制等商业层次要求的空间数据引擎还有很长的距离。不过在这个技术体系框架之下，这个的紧密捆绑目前最好的商业关系型数据库之一与采用先进的数据库编程模型的开源空间数据库项目，只要作者不是太懒的话，其还是很具发展潜力的，期待其后继版本能够带来更多的东西。

不过，话说回头，这样一个在微软.NET体系下相当有意思且相当有价值的一个开源GIS项目，微软是要偷着乐啊。