PostGIS 3.2新特性-轻识

当前PostGIS最新版本是3.3，本系列将分别详细描述下从PostGIS 3.0-PostGIS 3.3有哪些新特性，本文仅描述3.2版本新特性，部分资料说明来源于postgis作者paul的个人技术博客，其中官方原文内容说明参考：git.osgeo.org/gitea/postgis/postgis/raw/tag/3.2.0/NEWS，本文仅就相关内容整理。

一版本约束

一般约束：PostGIS 3.2支持9.6及以上版本，要求编译GEOS 3.6及以上版本。

推荐约束：PostgreSQL 14+PostGIS3.2 版本搭配，其中PostGIS 3.2编译需要Proj 6.1及以上版本，GEOS 3.10.0版本。

熟悉PostGIS的应该知道，PostGIS是依赖一系列底层基础库的，如GEOS（图形topo计算），Proj（地理投影），GDAL（矢量栅格空间读取与计算），SFCGAL（三维图形计算）还有其他基础库，不同基础库的升级会影响PostGIS功能，如果希望能使用上PostGIS新版本特性，请严格按照推荐约束使用。

二主要特性

2.1 移除wagyu编译可选项

postgis3.0集成Mapbox的wagyu算法，但是是可选项，用户可以通过

`--without-wagyu`参数不使用该算法，这样可以生成动态矢量切片但性能有点损失，由于这个选项基本毫无意义，在postgis3.2版本移除该编译选项，从而在生成矢量切片时默认统统使用wagyu算法。简化没有收益的不必要的配置。

2.2 具有副作用的gist索引构建加速

在pg14+postgis3.2版本中，使用Hilbert排序算法可以大大加快构建gist索引耗时，约提升了2-5倍。但副作用是基于这种排序构建的gist索引查询性能会下降很多，大约下降30%。考虑到索引的构建与基于索引的查询频次并不相同，用户可能构建一次或多次索引，但会更见频繁的基于空间索引去查询数据，因此，虽然该版本支持加快索引构建，但是并不是默认的。

在您理解副作用的前提下，可手动调整开启构建索引算法：

      
        ALTER OPERATOR FAMILY gist_geometry_ops_2d USING gist
      
      
          ADD FUNCTION 11 (geometry)
      
      
          geometry_gist_sortsupport_2d (internal);

也可以关闭，使用默认索引构建：

      
        ALTER OPERATOR FAMILY gist_geometry_ops_2d using gist
      
      
          DROP FUNCTION 11 (geometry);

2.3 新增ST_InterpolateRaster离散点插值成栅格

ST_InterpolateRaste

ST_InterpolateRaster用于获取一批散点，每个散点都有测量值，根据散点的xy坐标和测量值，通过空间插值与图像插值算法，生成一副栅格图像。熟悉gis的都知道例如idw（反距离权重）空间插值，熟悉图形学的知道最近邻插值，双线性插值等，该api就是通过这些插值算法生成一副插值结果，结果以栅格对象输出，存储以postgis的rast对象存储。

当前，ST_InterpolateRaster支持5种插值算法：反距离权重插值, inverse distance nearest-neighbor, moving average, 最近邻插值,双线性插值。

个人评价：在gis领域常用的空间算法是idw，克里金插值算法，这些算法通常具有较强的业务定制性优化，测量样本点通常不大，通过数据库存储测量样本点，服务端查询样本点方式，在服务端生成插值结果通常是更常用方案。

在重视oltp场景下，这些算法通常很吃cpu，耗时比较严重和不可控，除非你真的想知道在干嘛，否则这些算法最好不用于直接对用户的服务。

2.4 新增ST_Contour，基于栅格生成等值线

ST_Contour

ST_Co ntour支持基于栅格图像，使用marching squares算法生成等值线数据，仅仅支持生成等值线，不支持等值面。

个人评价：等值线面算法通常也是服务端生成，因为在数据库中生成耗时严重，postgis新实现的这些api本身其实是gdal中新增实现的方法的封装，并没有太大的实际意义。

实际业务中，数据库仍然是存散点测量数据，由服务端查询测量数据，根据空间插值生成栅格（或者说格网，栅格和格网很相似，但有一点点差异）数据，然后根据ms算法生成等值线，基于等值线与格网边框关系，线与线的关系，封装闭合等值面。

2.5 新增的ST_SetM,ST_SetZ，修改栅格数据

2.6 根据坐标提取栅格数据像素值ST_Value支持双线性插值

2.7 支持栅格的云存储

栅格影像都是geotiff这种文件格式，正常非遥感、气象等行业，很少会有将影像存储到数据库的需求。而对强应用行业来说，如何将高频观测影像结果存储和应用是个问题。

postgis的栅格数据管理能力是gdal赋予的，postgis支持in-db与out-db两种栅格存储形式。in-db即将栅格影像数值与元数据都存入数据库，out-db将栅格影像元数据存入数据库，实际影像数值数据不存，仍以文件形式存储。

总的来说，in-db由于切片的原因在大部分应用场景下性能更高，而out-db架构更灵活，但本身没更改原始数据，没有切片，在大部分场景下性能不是很高。

随着云计算、云存储等新的it架构的形成，gdal目前支持以vsicurl形式访问云服务器，存储桶上等存储的数据，例如aws s3,google cloud storage,azure等。因此，postgis新增postgis.gdal_vsi_options等变量支持绑定数据库与云存储里的影像数据。

postgis的云栅格数据管理能力实际是借由out-db和gdal的vsicurl两个混合而来的。

个人评价：明显不考虑性能，也不是面向oltp的场景，更加偏向于数据管理和离线计算（不追求性能场景下）的架构创新。一般业务用不到。

2.8 支持FlatGeoBuf格式

简单来说，FlatGeoBuf是一种流式传输格式，例如一个100M的空间数据传到客户端显示，客户端需要接收完整的数据，解析后渲染，这个网络不好就很耗时。流式传输就是客户端收到多少数据，解析并渲染多少（就是视频播放器那种边下边看的意思），则在较大数据的渲染时有好的用户体验。

更多FlatGeobuf格式说明参考：《FlatGeobuf 编码格式(fgb) —— 或许是 shp 格式的替代品》（https://zhuanlan.zhihu.com/p/378426761）

总的来说：FlatGeoBuf是无损的格式，也比较偏向于云存储优化的数据存储领域。但其实应用场景并不多，业务里应用场景更多的是基于Protobuf的矢量切片技术（有损压缩）。因此这种格式并没有广泛应用和很好的应用案例，但实现该方法，也是未来业务创新的一个机会。

三总结

postgis3.2新增内容对业务的影响较小，主要是栅格数据的处理能力加强（但不必要），云栅格（vsicurl），云矢量（flatgeobuf)等云上能力的业务创新。总的来说，当前gis里云数据云存储优化很多，比如geotiff与cloud optimized geotiff(cog，云优化tif），需部署于动态服务器的切片存储格式MBTiles与适合云存储的部署静态服务器的切片存储格式PMTiles。

在gis领域，类似”文件即服务“的形式目前有多点开花状态，文件即服务的形式可能是云存储厂商技术在推动的，比较静态化，比较适合他们的业务开展，当然如果你业务恰好很合适，也是值得思考的方向，但实际大部分业务中的很多数据是动态化的，因此，在实际选型时还是要仔细考虑实际情况。

postgis 3.2的新特性，也就是说指明了一些用户可以创新的方向，并未带来传统功能上性能更好的体验。

另外，新的栅格API并不是实际业务中最优解决方案，能别用就先别用，除非你不懂也不想写算法，只把数据库当个工具而已。。。