原文地址：PostGIS 3.2 New and Improved
原文作者：Paul Ramsey
上个月，就在 2021 年发布即将发布的情况下，PostGIS 的 3.2 版本面向市场了！这个新的 PostGIS 还支持最新的 3.10 版本的 GEOS，它支持了一些新功能。
光栅算法
该postgis_raster扩展使用 GDAL 栅格库进行矢量化栅格和栅格化矢量（是的！）之类的事情。此版本公开了一些更酷的 GDAL 算法。
- 新的 ST_InterpolateRaster 函数允许将测量点的集合内插到连续的光栅表面中。
-
可以将这些连续的光栅表面馈送到新的 ST_Contour函数，以计算表面的等值线。
-
使用ST_SetZ和 ST_SetM可以使用相同的栅格表面作为输入，将维度属性添加到 3D 和 4D 矢量对象 。
- 最后，ST_Value 函数（以及ST_SetZ 和ST_SetM）已升级为支持 栅格值的双线性插值。
光栅云访问
在过去五年中，地理空间领域更令人兴奋的趋势之一是越来越多的共识，即大地理空间数据应该 存在于云端、HTTP 对象存储（如 AWS S3、谷歌云存储或 Azure Blob 存储）中。这将主要原始数据存档的默认位置从“在 Joe 办公桌下的 USB 驱动器上”更改为可公开访问的位置，因此可用于集成到分析链中。
使用云中的栅格数据，可以使用postgis_raster扩展进行基于栅格的分析，而无需导入源栅格数据。您甚至可以在（适当配置的）云数据库服务（如 Crunchy Bridge ）中执行此操作。
我们最初关于云栅格分析的博客文章很有趣，但它们显示了来自数据库的云栅格的局限性：没有访问私有对象的好方法。
使用 PostGIS 3.2，现在可以 向云对象存储提供凭据，因此您也可以针对您的私有栅格集合进行远程分析。
更快/更好的效力
在过去的几年中，我们的开发重点之一是使 PostGIS 使用的计算几何引擎（GEOS 库） 更快、更现代。
在此发布周期中，对两个常见的面向用户的功能进行了现代化改造， ST_IsValid和 ST_MakeValid。
ST_IsValid被重新编写以提高效率，并且根据输入速度提高约 30%。
添加了一个新的 ST_MakeValid实现，速度提高了一倍，并且更好地尊重了输入的结构组成。结果是（取决于您的解释）对有效性错误的更“合理”的更正。
（可选）更快的 GIST 索引构建
今年，一名 Google Summer of Code学生承担了一个雄心勃勃的 PostGIS 项目：使用 PostgreSQL 14 的新 GIST“排序支持”挂钩来缩短索引构建时间。
这项工作已经完成，并且确实大大加快了GIST 索引构建时间，在 2 到 5 倍之间。
但是，有一个问题：以这种方式构建的索引的结构不如默认的增量索引构建。这可能导致查询性能下降，从零下降到 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);复制
请记住，即使您关闭了排序支持，您使用排序支持构建的任何索引仍将具有次优结构。
FlatGeoBuf 格式
在“也许这会起飞”类别中是对 FlatGeoBuf 格式的新支持。与 PostGIS 支持的其他 MVT 和 GeoBuf 格式一样， ST_AsFlatGeoBuf函数接收一行或一组行，并输出bytea对这些行中的所有数据进行编码的单个二进制文件。
FlatGeoBuf 格式是一种矢量，其原理与 Cloud Optimized GeoTiff相同：一种格式，其中空间中彼此靠近的特征在格式字节流中也彼此靠近。这允许使用相对较少的 HTTP 范围读取来提取数据的空间窗口。“云优化”就是减少服务常见用例所需的访问次数。
到目前为止，FlatGeoBuf 在野外的使用并不多，但它填补了矢量云存储空间中未满足的需求，因此这种情况可能会迅速改变。
关于更多
任何版本的更改摘要都会错过大量的利基增强和修复，因此真正的爱好者应该查看已 关闭的工单积压 和发布 新闻文件。
