专注GIS软件开发。

不用分区、不用分表、不用复杂索引改造，仅靠一句CASE分支就能显著降低运算耗时

样本量足够时，样本均值/总数会无限接近整体真实值:这一原理如何在PostGIS空间数据统计中应用？

详解 PostGIS 中主流的几何简化方案，包括点去重、经典抽稀算法、网格精度压缩，以及 PostGIS 3.6 全新推出的**拓扑面域批量简化**能力

通过PostGIS原生ST_AsMVT函数实现按需生成瓦片，避免了传统预生成方案的数据冗余和更新延迟问题。系统采用多层缓存机制（内存LRU+HTTP缓存）和连接池优化，结合空间索引加速查询，使10万级POI数据的查询渲染耗时控制在200ms内。架构包含前端MapLibre渲染层、API服务层、核心引擎层和PostGIS执行层，支持动态配置数据源并自动管理服务生命周期。相比传统瓦片预生成方案，该设计显著提升了数据更新效率和系统灵活性，同时降低了存储开销。

3dtubetilecreater实战避坑指南 本文总结了三维管线瓦片生成工具10类高频问题的解决方案： 环境依赖问题 Node版本需≥v24.2.0，npm安装失败时强制--force 工具路径需在config.json配置绝对路径 数据库连接问题 PostgreSQL需启用PostGIS扩展 校验server/config.json中的数据库密码和端口 瓦片生成问题 几何字段需为三维类型（PointZ/MultiLineStringZ） 大数据量时调整Node的maxBuffer至20MB 前端显示问题

本文介绍了使用3dtubetilecreater工具实现市政管线三维可视化的全流程实战。内容包括： 环境准备与目标设定：基于PostgreSQL/PostGIS数据库，通过Node.js工具链生成3D Tiles瓦片并在Cesium中展示。 测试数据准备：详细提供了创建管线表(pipe_main)和设施表(pipe_facility)的SQL脚本，包含三维几何数据示例。 项目配置与启动：说明如何修改配置文件连接本地数据库，并启动前后端服务。 核心功能实现：展示生成管线瓦片的后端接口代码和前端Cesium加载

本文详细介绍了3dtubetilecreater项目将PostGIS三维管线数据转换为标准3D Tiles的核心实现逻辑。项目采用b3dm和i3dm两种格式分别处理管线主体和附属设施数据，通过Node.js后端调度pg2b3dm和i3dm.export工具实现转换。文章从数据规范、命令行工具调用、后端代码实现到前后端联动全链路解析，重点阐述了PostGIS数据格式要求、核心接口实现及配置文件设计。该项目通过工程化封装成熟开源工具，实现了一键生成完整瓦片集的功能，为管线三维可视化提供了高效解决方案。

3dtubetilecreater 采用Vue+Express 前后端分离架构前端负责交互与三维预览，后端负责数据与瓦片生成核心依赖调用开源转换工具，架构轻量易扩展所有配置、接口、组件均对应项目真实源码，可直接二次开发。

摘要： 本文是3dtubetilecreater系列的第二篇，提供从环境搭建到项目部署的完整教程。内容涵盖Node.js、PostgreSQL+PostGIS、pg2b3dm、i3dm.export四大核心环境的安装配置，详细说明项目代码拉取、依赖安装及启动方式（支持前后端联调或单独启动）。针对常见问题如版本冲突、端口占用、路径错误等提供解决方案，确保新手能够顺利完成部署并访问前端（http://localhost:8080）和后端（http://localhost:3000）。所有步骤均通过实测验证，适配

本文介绍了开源项目3dtubetilecreater，这是一款基于PostGIS+Cesium的管线3D Tiles自动化生成工具。该项目通过集成pg2b3dm和i3dm.export工具，实现了从PostGIS管线数据到3D Tiles的一键转换，解决了传统方式需要手动处理命令行工具和数据适配的痛点。采用Vue.js+Node.js前后端分离架构，提供Web可视化操作界面，支持管线主体和附属设施的三维模型生成与Cesium预览。核心优势在于自动化流程、降低技术门槛，特别适合市政管线和园区管网的三维可视化场

根据 postgis_2.4.2-2.patch 中的差异信息对 postgis-xc 目录中的相关文件进行修改，以实现对 PostGIS 的某些修复或改进。将其中\src\include\目录的内容覆复制到/opt/software/openGauss/include/postgresql/server/修改 /etc/sudoers 文件，找到下面一行，在 root 下面添加一行，如下所示。未安装gdal，Raster相关功能无法使用。如果在安装操作系统的时候已经正确设置了omm，则忽略本步骤。

Postgresql的分区功能允许将一个大表按照特定的规则拆分成多个小的分区表。这样做的好处在于，在查询数据时，可以只扫描相关的分区，而不必扫描整个大表，从而大大提高查询速度。对于大规模数据的管理，分区还可以使得数据的维护和操作更加便捷，例如备份、恢复等操作可以针对单个分区进行，减少了资源消耗和时间成本。

PostGIS是一个强大的空间数据库扩展，它为PostgreSQL数据库添加了对空间数据的支持。通过PostGIS，我们可以存储、查询和分析各种几何形状和地理空间数据。在本文中，我们将探讨如何在PostGIS中插入不同类型的空间数据。

在给定的计算机配置下，通过合理的表结构设计、字符串处理、索引创建以及查询策略，可以较为高效地对千万级空间数据进行空间查询和关键字查询。创建表、更新字符串和创建索引的过程相对耗时较长，但一旦索引创建完成，实际查询操作非常迅速。同时，也验证了 PostGIS 在处理复杂空间查询和关键字查询方面的强大能力。本测试在探究在有限的计算机配置下，如何高效地对千万级的空间数据进行空间查询和关键字查询。通过实际操作和测试，评估不同查询策略的性能，为处理大规模空间数据提供可行的解决方案。

在某个App开发中，要求记录用户的日常轨迹，在用户巡逻设备的时，将记录的轨迹点当做该设备巡逻时候的轨迹。由于业务逻辑上没有明确的指示人员巡逻工单-GPS位置之间的关系，所以通过时间关系进行轨迹划定。

需求描述: 有一张表A，需要在R2记录中列为空的情况下，更新为R1记录中的值。

在PostGIS中有一张面要素表，需要检查该表中的哪些地方有重叠。其中重叠定义为这些多边形的面状交集。我们现在来计算出这些区域。

本文介绍在PostGIS中的线要素点，通过函数计算指定线要素表中的孤线，并计算最接近的纠偏位置。在PostGIS中有一张线要素表，需要检查该表中的孤线，并且进行自动纠正的计算。获取自动修复的容差，如果偏差大于该阈值，则不做自动修复的计算。其中孤线定义为两端端点都不在任何其他线的顶点上。我们可以直观看出B和D属于孤线。

在项目业务需求中需要计算出一些点没有落在线上，比如电网项目中的电杆点位必须落在点线传输路线上。 电杆的数据存储在专门的一张PostGIS空间表中，传输线路以矢量线段的方式存储在另一张线空间表。需要检查计算出那些没有落在传输线路上的电杆。

函数检查出来的结果有一种是Self-intersection，但是对于线数据集并不能判断出自相交的情况（项目中的要求是线对象的线段之间有相交的情况）。最近在开发关于空间数据拓扑的检查工作，检查空间线或面数据是否自相交。数据存储在PostGIS中。返回值为:正常检查完成返回结果表名称，否则返回"-1";函数进行计算，如果非自相交的线，则比有。进行检查，对于线对象，则采用。同时将检查结果写入记录表中。通过PostGIS中的。所以对于面对象，采用了。,否则认为是自相交。目前支持的几何类型为。,其他类型未做验证。

在PostGIS中计算点数据集的最小外包凸多边形等

先查看下当前gdal支持的全部格式，部分gdal版本可能不支持PostGIS。如出现PostgreSQL表名支持。

介绍在PostGIS中从点数据提取等值线。

介绍在PotGIS中将点数据转换为栅格数据。

方法类似与近似值计算，所如果被查找列如果比较长的情况下，查找结果可能不尽如人意。在Postgresql中通过关键字查询，一般情况下，利用like语句。使用like查询包含"夕阳"关键字的记录，语句可能如下。但是众所周知，这样的匹配率不尽如人意。默认表中的数据存储了上千万条记录。扩展进行实现更完美的关键字查询。在实际查找中，可能在。

上述方法只适用于地上三维对象的计算。如果是地下三维对象，应当将ST_Extrude对象的全部Z值减去高差的1/2。主要思路：将二维面对象转换为POLYHEDRALSURFACE对象。

延迟约束和完整的表级数据结构。线性网络约束从一个简单的道路网络开始。CREATE TABLE roads ( pk bigint PRIMARY KEY, name text NOT NULL, geom geometry(LineString, 3005) NOT NULL CONSTRAINT geom_no_zero_length CHECK (ST_Length(geom) > 0) CONSTRAINT geom_no_self_intersection C

空间数据质量通常涉及几何之间的更高阶关系。 正如强大的非空间模型将强制执行外键关系一样，空间约束可用于强制执行空间关系。触发器约束地块"地籍" 的形式，反映土地合法划分的空间层。 地籍的核心业务规则之一是，一块土地不能同时位于两个地籍中。两种不一致违反了上述原则：一个宗地与另一个宗地部分重叠，例如右下角的红色宗地。一个宗地完全包含在另一个宗地中，如左侧的红色宗地。创建一个检查规则（插入和更新时候使用）：CREATE OR REPLACE FUNCTION overlapping_parc

约束用于确保数据库中的数据反映数据模型的假设。外键是否与相应键匹配? (REFERENCES)是否填写了必填列? (NOT NULL)唯一值列实际上是唯一的吗? (UNIQUE)是否通过其他数据质量规则? (CHECK)为什么要在数据库中而不是在应用程序层实施数据质量规则？ 因为如果您在应用程序层限定所有数据，则每当添加“另一个应用程序”写入数据库时，都必须复制“所有逻辑”。如果您有幸编写了一个成功运行了超过两年的系统，那么多个写入应用程序迅速普及的可能性将达到100％。 在数据库中强制执行

更多更复杂的联合查询在本节中，我们将对一般的空间查询做一些更复杂的事情。创建一张人口普查表我们已经在数据库中创建了一个名为nyc_census_sociodata的表。 该表包括有关纽约的有趣的社会经济数据：通勤时间，收入和受教育程度。 只有一个问题。 数据由“人口普查区域”汇总，我们没有人口普查区域空间数据！在本节中，我们将:为人口普查区创建空间表将属性数据连接到空间数据使用我们的新数据进行一些分析创建一张人口普查表通过总结blkid键的子字符串，我们可以从人口普查区块中构建更高级别

空间索引回想一下，空间索引是空间数据库的三个关键功能之一。索引使使用空间数据库处理大型数据集成为可能。如果不建立索引，则对功能的任何搜索都将需要对数据库中的每个记录进行“顺序扫描”。通过将数据组织到可以快速遍历以查找特定记录的搜索树中，可以加快索引的搜索速度。空间索引是PostGIS的最大能力之一。在前面的示例中，建立空间联接需要将整个表相互比较。这可能会非常耗时：将两个10,000条记录的表连接起来，每个表没有索引将需要100,000,000个比较；使用索引的成本可能低至20,000次比较。当我

空间联接是空间数据库的基础。 它们允许通过使用空间关系作为JOIN键来组合来自不同表的信息。 我们认为的大多数“标准GIS分析”都可以表示为空间JOIN。在上一节中，我们使用两步过程探索了空间关系：首先，我们提取了Broad St的地铁站点； 然后，我们用这一点来问其他问题，例如“Broad St车站在哪个社区？”使用空间JOIN，我们可以一步一步地回答问题，检索有关地铁站及其附近的信息：SELECT subways.name AS subway_name,neighborhoods.name.

本文将逐一介绍空间关系的定义及使用。空间关系PostGIS的强大功能是能够计算Geometry之间的空间关系。通过比较代表自行车位置，街道和地铁线的几何形状，可以回答诸如“距公园最近的自行车架在哪里？”或“地铁线与街道的交叉点在哪里？”之类的问题。PostGIS提供了Open Geospatial Consortium / SQL-MM标准中定义的全套空间关系功能。这些功能允许测试空间（拓扑）关系和基于几何之间的距离的关系。大多数关系函数接受两个几何作为输入，并以布尔值形式返回指定关系的值。 .

地球不是平坦的，没有简单的方法可以将其放在平面的纸质地图（或计算机屏幕）上，因此人们想出了各种巧妙的解决方案，每种解决方案各有利弊。有些投影会保留区域，因此所有对象之间的大小都相对。其他投影像墨卡托投影一样保留角度（共形）；一些预测试图找到一个好的中间混合，在几个参数上只有很小的失真。所有投影的共同点是它们将（球形）世界转换为平坦的笛卡尔坐标系，选择哪种投影取决于如何使用数据。加载nyc数据时，我们已经遇到了投影。 （回想一下令人讨厌的SRID 26918）。但是，有时需要在空间参照系之间进行转换和重.

坐标为“地理”或“纬度/经度”的数据非常常见。与墨卡托（Mercator），UTM或Stateplane中的坐标不同，地理坐标不是笛卡尔坐标。 地理坐标不代表在平面上绘制的距原点的线性距离。 而是，这些球坐标描述了地球仪上的角坐标。 在球坐标中，一个点由与参考子午线的旋转角度（经度）和与赤道的角度（纬度）指定。您可以将地理坐标视为近似的笛卡尔坐标，然后继续进行空间计算。但是，距离，长度和面积的测量是没有意义的。由于球坐标测量角距离，所以单位为“度”。此外，索引和真/假测试（如相交和包含）的近.

介绍在开始处理数据之前，让我们看一些简单的例子。 继续并在控制台中执行以下SQL语句。CREATE TABLE geometries (name varchar, geom geometry);INSERT INTO geometries VALUES ('Point', 'POINT(0 0)'), ('Linestring', 'LINESTRING(0 0, 1 1, 2 1, 2 2)'), ('Polygon', 'POLYGON((0 0, 1 0, 1 1, 0 1, 0

本文介绍SP-GiST索引及PostGIS中索引的使用：SP-GiST以及如何使用索引前面的文章介绍了两种索引，本文介绍SP-GiST索引及全部PostGIS中的索引使用方法。1. SP-GiST 索引SP-GiST代表“空间分区的通用搜索树”，它是索引的一种通用形式，它支持分区的搜索树，例如四叉树，k-d树和基数树（重试）。这些数据结构的共同特征是，它们将搜索空间重复地划分为不必具有相同大小的分区。除GIS索引外，SP-GiST还用于加速对多种数据的搜索，例如电话路由，ip路由，子字符串搜

本文介绍如下索引：GISTBRIN索引使使用空间数据库处理大型数据集成为可能。 如果不建立索引，则对功能的任何搜索都需要对数据库中的每个记录进行“顺序扫描”。 索引通过将数据组织到可以快速遍历以查找特定记录的搜索树中来加快搜索速度。 PostgreSQL默认支持三种索引：B树索引，SP-GiST和GiST索引。B树用于可沿一个轴排序的数据。 例如数字，字母，日期。 空间数据可以沿着空间填充曲线，Z阶曲线或希尔伯特曲线进行排序。 但是，这种表示方式不允许加快常见的操作。GiST（通用搜索树）索

本文包含以下内容：利用索引空间查询SQL示例有效地使用PostGIS需要知道哪些空间功能可用，并确保适当的索引可用以提供良好的性能。这些示例中使用的SRID 312仅用于演示。您应该使用spatial_ref_sys表中列出的REAL SRID，并使用与数据投影相匹配的REAL SRID。如果数据未指定空间参考系统，则应仔细考虑为什么没有这样做，也许应该这样做。如果是因为要建模的对象没有定义地理空间参考系统，例如分子的内部结构或尚未建造的游乐园的平面图，那很好。但是，如果已经计划了游乐园的位置

本文包含以下内容：关于 PostGISGreenplum 数据库中的PostGIS 扩展提供PostGIS能力升级Greenplum的PostGIS扩展迁移PostGIS 1.4到2.0使用PostGIS 功能和限制1. 关于 PostGIS关于PostGIS的介绍，本文不再赘述，请参考本公众号相关专题文章。2. Greenplum 数据库中的PostGIS 扩展可从Pivotal Network网站（https://network.pivotal.io ）获得Greenplum