直接 GROUP BY geom 会失败，因PostgreSQL几何类型无默认相等比较逻辑，SRID差异或浮点误差会导致分组错误或报错“could not identify an equality operator for type geometry”。
不能直接对几何类型列用 GROUP BY 分组，必须先转为可比较的标量形式（如 WKT、哈希或简化坐标），否则会报错或结果不可靠。
为什么直接 GROUP BY geom 会失败或出错
PostgreSQL 的几何类型（POINT、POLYGON 等）是复合结构，内部包含坐标、SRID、精度等信息。数据库默认不提供几何值的全量相等比较逻辑用于分组 —— 即使两个 POINT(1 1) 看似相同，若 SRID 不同、或浮点表示有微小差异（如 1.0000000001 vs 1.0），GROUP BY 就可能把它们拆成不同组，甚至触发错误。
- 常见报错：
could not identify an equality operator for type geometry - 即使没报错，也可能因浮点误差导致本该合并的点被分散成多组
-
ST_Equals()可判断逻辑相等，但不能用在GROUP BY子句中（它不是索引友好的标量表达式）
安全分组的三种可行方式
核心思路：把几何对象映射到一个确定、稳定、可排序/可哈希的标量值上。
-
用
ST_AsText(geom)转 WKT 字符串：最直观，适合调试或低频小数据；但注意：WKT 输出精度受postgis.version和SET extra_float_digits影响，生产环境慎用 -
用
ST_GeoHash(geom, precision)生成地理哈希：控制分组粒度（如精度 6 ≈ 120m），天然支持空间邻近聚合；需确保所有几何在同一坐标系（通常是 WGS84 / EPSG:4326） -
用
ST_SnapToGrid(geom, size)简化坐标网格：强制所有坐标对齐到指定网格（如0.001度），再转 WKT 或哈希；比 GeoHash 更可控，适合规则格网分析
示例（按 1km 网格聚合点位数量）：
SELECT ST_AsText(ST_SnapToGrid(location, 0.009)), COUNT(*) FROM sensors WHERE location IS NOT NULL GROUP BY ST_SnapToGrid(location, 0.009);
STRING_AGG 和 ARRAY_AGG 对几何列的限制
不能直接 STRING_AGG(geom, ',') —— 几何类型没有默认的字符串转换函数，会报错 function string_agg(geometry, unknown) does not exist。
- 必须显式转为文本：
STRING_AGG(ST_AsText(geom), ';') - 若想保留结构供后续 GIS 处理，改用
ST_Union(geom)或ST_Collect(geom)（后者返回GEOMETRYCOLLECTION，不融合，仅打包） -
ARRAY_AGG(geom)在 PostgreSQL 12+ 支持，但数组元素仍是几何类型，无法直接用于外部应用解析；建议只在子查询或 CTE 内部使用
聚合后做空间计算的典型链路
分组本身只是第一步；真正有价值的是分组后的空间统计。别在 GROUP BY 后硬凑多个 ST_* 函数，容易性能崩盘。
- 先分组汇总 ID 或计数：
GROUP BY ST_GeoHash(location, 5) - 再用窗口函数或子查询做空间聚合：
ST_Union(ARRAY_AGG(location))或ST_Centroid(ST_Collect(location)) - 关键点：所有空间函数（
ST_Area、ST_Distance等）都要求输入是单个几何对象，不是分组键 —— 所以必须先用ST_Collect或ST_Union把一组几何“收拢”成一个
最易忽略的是坐标系一致性：跨分组做 ST_Distance 或 ST_Area 前，务必用 ST_Transform(geom, 3857) 统一到投影坐标系，否则单位是度，结果无意义。
