GeoJSON 怎样提取空间属性

在 MySQL 里提取 GeoJSON 的“空间属性”，先要分清两个概念：properties 是业务字段，应该用 JSON 函数读取；geometry 才是点、线、面等空间对象，应该交给 ST_GeomFromGeoJSON() 转成 MySQL 几何值。不要期待空间函数把 properties 自动变成查询列。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

单个 Feature 用 JSON_VALUE() 取标量属性，FeatureCollection 用 JSON_TABLE() 展开多条记录；需要做空间计算时，再从同一个 Feature 的 geometry 分支调用 ST_GeomFromGeoJSON()。

先分清 properties 和 geometry

典型的 GeoJSON Feature 同时包含属性和几何两条分支：

{
  "type": "Feature",
  "properties": {
    "name": "中心公园",
    "level": 3
  },
  "geometry": {
    "type": "Point",
    "coordinates": [116.397, 39.909]
  }
}

如果文档保存在 geojson_docs(doc JSON) 的 doc 列中，名称和等级属于普通 JSON 标量，可以这样取：

SELECT
    JSON_VALUE(doc, '$.properties.name' RETURNING CHAR(80)) AS place_name,
    JSON_VALUE(doc, '$.properties.level' RETURNING UNSIGNED) AS place_level
FROM geojson_docs;
-- JSON_VALUE 只负责把 properties 下的标量投影成 SQL 列。
-- RETURNING 类型要和后续排序、筛选需要的类型一致。

我在整理地图数据时最容易踩的坑，就是把“属性”和“坐标”当成同一种字段处理。name、level 可以直接变成关系结果；coordinates 只是几何对象内部的数据，是否转换成空间值要看后续是否需要距离、包含或相交等空间操作。

用 JSON_VALUE 读取单个 Feature

当一行只保存一个 Feature 时，使用 JSON 路径就足够了。路径从根节点开始，$.properties.name 表示进入 properties 后取 name。

SELECT
    id,
    JSON_VALUE(doc, '$.properties.name' RETURNING CHAR(80)) AS name,
    JSON_VALUE(doc, '$.properties.level' RETURNING UNSIGNED) AS level,
    JSON_VALUE(doc, '$.geometry.type' RETURNING CHAR(20)) AS geometry_type
FROM geojson_docs
WHERE JSON_VALUE(doc, '$.type' RETURNING CHAR(20)) = 'Feature';
-- 先限制文档类型，避免把 FeatureCollection 当成单个 Feature 读取。
-- 缺失路径默认返回 NULL，调用方可以据此区分缺字段与空字符串。

这里提取的是业务属性和几何类型名称，而不是把整段几何文本拆成多个列。如果确实要保留几何对象，可以读取 $.geometry，再交给空间函数：

SELECT
    id,
    JSON_VALUE(doc, '$.properties.name' RETURNING CHAR(80)) AS name,
    ST_GeomFromGeoJSON(
        JSON_UNQUOTE(JSON_EXTRACT(doc, '$.geometry')),
        1,
        4326
    ) AS shape
FROM geojson_docs;
-- geometry 分支单独送入空间解析函数，properties 仍由 JSON_VALUE 读取。
-- options=1 表示遇到高于二维的坐标维度时拒绝该文档，SRID 固定为 4326。

MySQL 文档说明，ST_GeomFromGeoJSON() 的返回值是几何对象；GeoJSON 中的 properties 不属于它的空间结果。解析时还要留意经纬度范围、坐标维度和 SRID，不能把“JSON 能解析”直接等同于“空间数据可以用于计算”。

用 JSON_TABLE 展开 FeatureCollection

如果一行保存的是 FeatureCollection，属性位于 features 数组的每个元素中。此时用 JSON_TABLE() 把数组映射成关系结果更合适：

SELECT
    d.id AS document_id,
    f.name,
    f.level,
    ST_GeomFromGeoJSON(JSON_UNQUOTE(f.geometry_json), 1, 4326) AS shape
FROM geojson_docs AS d
JOIN JSON_TABLE(
    d.doc,
    '$.features[*]' COLUMNS (
        name VARCHAR(80) PATH '$.properties.name',
        level UNSIGNED PATH '$.properties.level',
        geometry_json JSON PATH '$.geometry'
    )
) AS f;
-- JSON_TABLE 把每个 Feature 变成一行，并把属性定义成关系列。
-- geometry_json 暂时保留为 JSON，再单独转换为几何值，边界更清楚。

JSON_TABLE() 的价值是把数组元素变成可筛选、可排序、可连接的关系行。属性列可以直接参与 WHERE f.level >= 2；几何列则保持空间值语义，后续再与空间表做运算。两条路径不要混在一个“万能提取函数”里。

SRID 和坐标边界要单独处理

GeoJSON 解析时，如果不显式传入 SRID，MySQL 会按函数规则处理空间参考；工程上更稳妥的做法是根据数据契约明确写出 SRID，例如上例的 4326。同一空间计算中的几何值应使用相同的空间参考系统，否则可能出现不同 SRID 的错误。

另外，GeoJSON 的 type 是区分大小写的，Point 不能随意写成小写。经纬度超出合法范围、坐标维度超过当前处理策略、或 CRS 与输入约定不一致时，都应该被当作输入问题记录，而不是静默改写坐标。

相关问题

ST_GeomFromGeoJSON 能直接返回 properties 吗？

不能。它的职责是把 GeoJSON 几何内容转换为空间值；properties 应使用 JSON 路径函数读取。

properties 缺失时应该返回什么？

可以让 JSON_VALUE 返回 NULL，再由业务层决定是否过滤、补默认值或记录数据质量问题。不要把缺失字段和空字符串混为一谈。

什么时候只提取坐标，不转换成几何值？

如果只是展示或导出原始 JSON，可以保留 geometry 分支；只有需要空间关系、距离或索引能力时，才应该把它转换成 MySQL 几何值，并明确 SRID。

总结

GeoJSON 的属性提取可以按数据形态选择函数：单个 Feature 用 JSON_VALUE，集合用 JSON_TABLE；geometry 仍然单独保留，并在需要空间语义时调用 ST_GeomFromGeoJSON。把业务属性、原始几何和空间值分开处理，查询更容易维护，SRID 和输入错误也更容易定位。