文章转载自微信公众号云布道师，作者：曾志明，版权归原作者及刊载媒体所有。前言
在 GIS 圈子中，有一句流传已久的说法：“80% 的数据都和地理空间位置有关”。GIS 作为专门处理地理空间数据的工具和技术，自然引以为豪。但略显尴尬的是，GIS 作为空间技术和 IT 的结合体，在 IT 技术的应用上，却总是落后 IT 主流技术半步。例如，作为 GIS 的领导者 ESRI，在九十年代中后期，其主打产品 ArcInfo 7.x 版本仍然是基于命令行模式的，1999 年 ArcGIS 8.0 才有了图形桌面。再如，ESRI 在 1995 年才推出基于数据库的空间数据引擎（SDE），已经晚于关系型数据库诞生接近二十年。超图作为国产 GIS 后来的佼佼者，虽然紧跟技术发展，但在大数据、云原生等应用上，仍然落后于 IT 主流技术半步。分析其根源，其实在于主流 IT 技术一开始并没有把空间数据的处理能力当作必需的内置能力。而更多是 GIS 厂商为了与 IT 主流技术适配，不断学习和跟进。这就必然有一个观望、学习和实现的过程。同时，由于 IT 主流技术原本没有内置提供 GIS 能力（Oracle Spatial/PostGIS 也是后来出现的技术，且 GIS 厂商不愿绑定在某个单一数据库之上），也从而导致 GIS 厂商不得不习惯于自成体系，从而体系结构庞大，对 IT 技术发展的跟进和适应更有一个研发周期。图：SuperMap GIS 10i（2021）软件体系
在云计算和数字化转型的浪潮中，情况正在发生一些变化。GIS 要融入云计算和数字化转型，已经不是简单跟随技术变化就能做得到了，必须要有一个思维上的转变。本文作者从事 GIS 基础软件开发二十年，曾负责国内某知名 GIS 软件从 Windows 平台迁移到跨平台的全过程，对 GIS 软件的技术实现和发展演变过程有切身的体会。近年来加入阿里云，从事空间领域的数字化转型过程，从中有一些浅薄的认识，在此抛砖引玉。期待更好地促进 GIS 与数字化转型的融合。从以功能为中心到以数据为中心
空间数据存储虽然有 OGC 标准，虽然各大 GIS 厂商无论从口号还是事实上也都部分遵从了 OGC 标准，但实际上，各主要 GIS 厂商由于历史兼容性，更看重自身功能实现以及有意无意等各种原因，对 OGC 标准的支持并非完美。例如，对于基本的二维几何对象存储，ArcGIS 和超图都有自己原生的存储格式，两者在物理存储上并不和 OGC 的 WKB 规范一致。虽然在逻辑上是类似的，也提供了到 WKB 的转换能力，但毕竟需要一个转换的过程。在空间表的元数据层面，也是如此。ArcGIS 和超图各自有自己的系统表，并采用 OGC 的标准。不过好在，ArcGIS SDE 和超图 SDX+ 作为空间数据引擎，可以对接多种空间数据库，其都提供了 for PostGIS 的引擎。但就算如此，GIS 厂商在直接读写 OGC 规范的空间数据上，仍然存在瑕疵。在一般的信息化建设系统中，往往是更看重功能的实现。故而在选定某种特定类型的 GIS 后，采用其原生的存储格式，往往在功能、乃至性能上都可能带来更大的益处。但，对于数字化转型而言，目标就是汇聚各个系统中的数据，并建立数据标准，开展数据治理，完成数仓建模和发布 API 服务。在这个过程中，功能并非最重要的，而是数据本身才是核心和关键。如此，只能是功能围绕数据为中心，而非数据对特定 GIS 妥协。以标准的格式存储一份空间数据，成为空间领域数字化转型的首要前提。在此基础上，GIS 软件则应改变思路。不能因为某个 GIS 软件可能的功能/性能优势，来试图说服用户采用其私有的存储格式。因为这样一来，数据就被特定软件和功能所绑架了。整个系统，也就没有开放性和发展性可言。对于掌握了数字化思维的业主而言，肯定是无法接受的。如果私有存储格式真的有其独到的优势和价值，对于 GIS 厂商而言，更应做的是把它公开出来，并推动其作为下一代的标准格式。从空间数据引擎到空间数据库
空间数据引擎，本质上是提供一套空间数据读写的接口，往下对接不同的数据库，使得这些数据库具备空间数据的读写能力，往上以一套统一的空间数据模型，对接各类 GIS 的地图渲染、空间分析、服务发布等能力，从而使得这些能力的代码只需要编写一次，屏蔽不同数据库之间的差异。应该说，在之前关系型数据库几乎一统天下的时候，空间数据引擎是一个很天才的设计。且无论是商用的 ArcGIS、超图，还是开源的 GeoTools、GDAL/OGR，都不约而同采取了空间数据引擎这样的技术框架。通过空间数据引擎，GIS 就可以很方便地扩展对于多个数据库的支持，起到类似中间件的作用。第一个是各主流关系型数据库也开始直接增加空间数据的存储和管理能力。例如 Oracle 的 Oracle Spatial、Postgresql 的 PostGIS，MySQL 和 SQLServer 也有了自己的 Spatial 模块。这些 Spatial 模块虽然良莠不齐，对空间数据的支持程度也有差别。但还是有两个共同特点：一是这些空间数据库由于是数据库的扩展，故而更看重对 OGC 标准的遵从，使得其空间数据的存储是标准和开放的。
二是空间数据由数据库原生支持，能减少空间数据从数据库服务端到客户端的传输，且还能充分发挥数据库在并行计算等方面的性能优势。主流 GIS 虽然在自身空间数据引擎的框架内，也纷纷跟进了对这些空间数据库的支持，但毕竟不是自己所掌控的技术，支持的程度往往比较有限，且数据兼容性方面也并非完美。
第二个变化则是更致命的，数据库这些年摆脱了“关系型”的桎梏，在各方面有了突飞猛进的发展。这些改变，使得以关系型数据库为基础理念的空间数据引擎框架，很难适应在不同方面发展的数据库技术。例如，MPP 架构的数据库更适合数仓的 OLAP、而非空间数据编辑等操作的 OLTP；ElasticSearch 内置 GeoHash 编码和倒排索引，使得大规模点数据的聚合计算性能超快；HBase 的列存储，提供了分布式计算的技术基础；图数据库则和关系型数据库的区别更大，更适合知识图谱的管理。这些，都使得基于空间数据引擎的 GIS 技术，更像是一个老古董，面对层出不穷的数据库技术，最多只能以打补丁的方式来试图缓解和弥补问题。其实，正确的做法就是两个字：“放下”。即不把自己禁锢在原来的技术框架之内，而是拥抱这些新技术、新变化。哪种数据库适合做什么，我们就用它来做什么。某种数据库若是已经有了空间数据的管理能力，我们就直接用它；若是没有，我们就在数据库中增加空间能力。这么说并非空间数据引擎就没有价值，要读写只有物理结构不同、逻辑结构类似的空间数据，空间数据引擎仍然是很好的技术。但只有思维上从空间数据引擎转变到空间数据库，我们才能摆脱 GIS 固有的思维和框架，转变到以“数据”为中心的理念上。GIS 的软件体系并不重要，空间数据以及围绕空间数据的能力才更重要。近三十年来，随着 PC 机的发展，GIS 从支持 Unix 大型机走向了以 PC 机为主的技术路线。从技术架构上，以 C/C++ 构建 GIS 技术内核；在内核之上，封装不同开发语言的 SDK；再构建 GIS 桌面和 GIS 服务器。主流商业 GIS 和开源 GIS 概莫除外。虽然随着 IT 技术的发展，尤其是云原生技术的出现，主流商业 GIS 在与 K8s、Docker 结合方面做了很多工作，例如 SuperMap 从 2016 年开始支持把 GIS 服务器打包成 Docker 镜像，ArcGIS 也从 10.8 版本开始支持 K8s。但从根子上看，GIS 引擎的核心并未脱离基于单机发展起来的技术体系，例如对对象存储支持不足、功能体系严重依赖桌面软件、多数功能并未考虑分布式和并行计算等等。可以说，当前 GIS 引擎虽然在向云靠拢，但都仍然是非“云原生”的。对于数字化转型，必然会把更多原来利用不上、收集不了的数据纳入管理，要求打通原来存在的硬件隔离和数据孤岛，要求更多的、灵活的数字化应用，要求能应对突发的访问量的增长，要求大幅度降低成本和提高效率，这些都势必要求不能延续原来不断增加服务器的思路，而是充分发挥云计算在弹性伸缩、无限扩容、按需付费、充分利用资源的能力。在数字化转型的浪潮下，云计算已经取代单机，成为 IT 基础设施的必然。就如同发展电气化，没有统一、便捷、低成本的电网，仍然采用独立的发电机，是很难想象的。GIS 要迎接和融入数字化转型的浪潮，也势必从最底层的技术核心开始，按照云计算的要求来做彻底的改造。这里面涉及的技术变化包括（但不限于）：数据存储的改变
空间数据往往都非常大，之前的处理要么存储在本地磁盘或数据库中，要么存储在磁盘阵列中。本地磁盘是一个容量小且不可靠的存在，磁盘阵列也有容量的上限。在云环境下，空间数据是存储在 OSS 对象存储或者云数据库等云存储。对于文件或瓦片类型数据，对象存储是一个可无限扩展的存储空间，且自动具备三备份，可靠性高。而云数据库无论在存储空间的横向扩展和并行计算方面，都远胜传统数据库。 软件打包部署方式的改变
软件部署是以 docker 镜像的方式提供，而非传统的安装包或者压缩文件。在云的环境中，传统的单机软件安装包，将完全没有用武之地。k8s+docker 是标配，实现按需启动、自动扩容、负载均衡。 功能实现的改变
在传统模式下，数据量大部分都是有限的，也缺乏足够的硬件资源。所以只对特定的功能做分布式和并行计算的改造。而在云环境下，功能从一开始就会充分考虑到在数据量极大的情况下的要求，从软件架构和硬件资源供给上，也是天然就具备了分布式计算和并行计算的能力。地图动态渲染方式的改变
在传统模式下，非瓦片的动态地图，一般采用 GIS 桌面配图，然后发布 GIS 服务；渲染时是在后台服务器上绘制为图片，再传输到前端查看。在云环境下，后台服务器负责提供数据（矢量瓦片），绘制则是在前端完成。这样既减轻了后台服务渲染的压力，也有利于灵活配置各类地图样式。当然，在作为底图，无须改变样式的情况下，静态瓦片仍然会存在。GIS 组件和桌面形态的改变
C/S 方式开发的 GIS 组件将不复存在，未来一切都是基于 API 服务接口的。而 GIS 桌面，除了测绘数据生产环节，仍然会需要传统基于单机的 GIS 桌面。而通用型的 GIS 桌面若如果仍然存在的话，也是采用 WebAssembly 技术直接嵌入到浏览器中，访问的也是存储在云上的数据。总结
通过上述分析，我们可以看出：未来空间数据及其分析处理渲染能力仍然存在，且会越来越重要；但传统的 GIS 套装软件则不一定被需要了。GIS 对空间数据的存储、管理、计算和渲染能力，会被解构，分散到云的各个环节中，并与具体的应用场景相结合。对于用户而言，不用再关心如何单独安装部署一个专业的 GIS 套装软件，用户单位也不用花费很多精力培养专业的 GIS 人才。就如同我们无须关心电厂的电是如何发出来的，家电厂家也无须配套提供发电机。空间数据，将和非空间数据融合在一起，为数字化转型添砖加瓦，做出自己的贡献。《慧天地》敬告
《慧天地》公众号聚焦国内外时空信息科技前沿、行业发展动态、跨界融合趋势，发现企业核心竞争力，传播测绘地理信息文化，为相关专业学子提供日常学习、考研就业一站式服务，打造政产学研金服用精准对接的平台。
《慧天地》借鉴《读者》办刊理念，把时空信息领域的精华内容汇聚到平台上。我们高度重视版权，对于精选的每一篇推文，都会在文章开头显著注明出处，以表达对作者和推文引用平台版权的充分尊重和感谢；对于来源于网络作者不明的作品，转载时如出现侵权，请后台留言，我们会及时删除。感谢大家一直以来对《慧天地》的关注和支持！
——《慧天地》运营团队
微信号：huitiandi321
邮箱：geomaticshtd@163.com