开源地理空间智能项目中的本体思想 4-2：影像篇——影像不进图谱，图谱给影像当索引

4-1 查询篇的五个案例，数据都是"对象和关系"。地理智能还有一大块数据没进场：遥感影像。影像是栅格，动辄 TB，进不了也不该进图谱。那它怎么和图谱协作？本篇两个案例是构造的，但每一层的技术都真实存在（来源见附录）。

一句话结论：影像这类"大而笨"的数据，要给它当好索引，利用STAC查询；影像算出结果，比如统计值，"写回"到系统中，对应本体的动力层。

案例六（影像）：找出保护区内植被在退化的森林

问题：柏林周边，位于自然保护区内、近两年植被明显退化的森林斑块有哪些？

笨办法：QGIS 里手工叠加森林图层和保护区图层，逐个斑块去哥白尼数据浏览器下载影像，逐块算 NDVI，填 Excel。一个周末起步，结果还是死表。

合理的做法：图谱管对象和语义，STAC 管影像发现，网格管栅格组织，各干各的，靠几何和标识符咬合。

本系列的框架里，本体的六个要素是对象、属性、关系（语义层）和动作、函数、权限（动力层）。遥感影像是数据，不是本体思想的载体。这个案例的看点，是它两次碰到动力层——第 4 跳的栅格计算是函数，第 5 跳的写回是动作。下面逐层看。

STAC 是社区规范，也是影像目录的事实标准

关于第 3 跳的 STAC（SpatioTemporal Asset Catalog，时空资产目录）[1]。

它是国际上的一个规范吗？是，但要分清是哪一类。STAC 不是 ISO 或 OGC 的正式标准，而是一个开源社区规范：由 Radiant Earth 基金会牵头的社区维护，规范文本公开在 GitHub 上，现行版本 v1.1.0（2024-09 发布）。它的地位是"事实标准"——哥白尼数据空间（Copernicus Data Space）、AWS 开放数据、微软行星计算机（Microsoft Planetary Computer）等主流影像服务都提供 STAC 目录；它的 API 部分与 OGC API - Features 标准对齐。所以严谨的说法是：不是国际标准组织盖章的标准，但已是遥感影像目录领域实际通行的事实标准。

“JSON Schema 表达本体思想”：说法成立，边界清晰

STAC 用 JSON Schema（一种给 JSON 文档定结构、做机器校验的社区规范，以 IETF 草案族形式发布）定义对象类型（目录 Catalog、集合 Collection、条目 Item）和属性（时间、云量、几何范围、波段）。任何机构的影像目录只要符合 STAC，就能被同一个客户端检索。

在本系列"本体思想=先把对象、属性、关系定义清楚再存数据"的口径下，"STAC 是用 JSON Schema 表达本体思想的真实例子"这个说法成立：它把对象类型和属性结构这两层固定下来，而且是机器可校验的固定。

但边界也要说死，这同样是为了严谨：STAC 不做三件事——不做形式语义（没有推理）；不给对象全球唯一、可跨源引用的标识符（一个影像条目的 ID 只在自家目录里有意义）；不定义跨源关系（没有"这块影像覆盖哪片森林"的标准说法）。

结构校验做得到：机器自动判断一条记录合不合格

先看一个 STAC 影像条目的样子（字段名与结构取自 STAC 1.1.0 规范，取值为示意）：

{"type":"Feature","stac_version":"1.1.0","id":"S2A_T32UPC_20260810","bbox":[13.09,52.35,13.76,52.68],"geometry":{"type":"Polygon","coordinates":[[[13.09,52.35],[13.76,52.35],[13.76,52.68],[13.09,52.68],[13.09,52.35]]]},"properties":{"datetime":"2026-08-10T10:05:00Z","eo:cloud_cover":12.3},"assets":{"visual":{"href":"https://example.org/s2/T32UPC/visual.tif","type":"image/tiff"}}}

逐行对照规范要求：必须声明type: "Feature"，必须有几何geometry和外接框bbox，properties里必须带拍摄时间datetime，云量eo:cloud_cover这类字段来自扩展、类型必须是数字，assets里给出影像文件的地址。这些"必须有、类型必须对"的规矩全部写在 JSON Schema 里，任何一条目录记录，校验器能自动判断它合不合格——缺字段、类型错，机器直接拒绝，不用人眼看。"做得到"的意思就是：一条记录合不合格，从"靠人读文档判断"变成了"机器自动判"。

第 3 跳查到了影像条目，第 4 跳要算"影像覆盖哪片森林"——但 STAC 没有标准说法表达"这块影像覆盖哪片森林"，森林是另一个图谱里的对象，影像条目的 ID 出了自家目录就没人认识。所以影像几何与森林几何的空间求交，要应用层自己算。这就是边界的含义：结构校验管"一条记录长得对不对"，管不了"两个来源的数据说的是不是同一个东西"。

写回是动力层的动作，目前没有标准做法

第 5 跳暴露的是另一个空白：算出"NDVI 下降"之后，把它作为事实写回图谱，没有标准动作可用——03 篇说过，GeoSPARQL 和 DGGS 的动力层（动作、权限）是空白，就是这个意思 [2]。

值得强调的是：写回这个动作，确实体现了动力层里"动作"这个要素的思想。它不是查询——查询只读不改；它是"把一个新事实写进世界（这里是图谱）"的受控操作。谁有权写、写到哪个对象上、写完要不要触发别的动作，这些全是动力层问题，目前这方面的内容较少。

案例七（寻址+影像）：哪些格子住着人，却还没有地址

问题：一个县去年新建的民房聚落有哪些，它们该编进哪个地址网格？

地址是最典型的"字符串之苦"："海口市美兰区××路12号"对人是地址，对机器只是一段文本。寻址（addressing，给地点分配可引用的名称或编号）分两步走：把地址文本解析成结构化成分，再落到坐标——后一步叫地理编码（geocoding）。更麻烦的是，世界上大量居民区根本没有门牌，快递、急救、人口普查都卡在"这地方叫什么"上。

这个案例是构造的，但每个零件都真实存在：

第 4 跳是这个案例的心脏：把"全县有没有新房子"这个要靠人腿回答的问题，换成"哪些格子的影像里多出了建筑"这个可以批量计算的问题。有建筑足迹而无地址记录的格子，就是寻址部门该去的地方。

笨办法：民政、邮政部门的人工踏勘登记。现实世界里门牌号就是这么来的——一个县走一遍以月计，走完已经过时。影像加网格把"全县踏勘"变成"只核查有建设活动的格子"，工作量下降几个数量级。

SOSA 是 W3C 国际标准，统一描述"谁观测到了什么"

案例七说"影像检测结果是观测"。观测有没有标准说法？有，而且是正经的国际标准：SOSA 本体（Sensor, Observation, Sample, and Actuator Ontology，传感器—观测—样本—执行器本体），W3C 推荐标准（2017 年发布，与 OGC 联合制定），专门描述"某时某地，谁观测到了什么" [3]。它把观测拆成几个对象：传感器（谁测的）、观测（哪次测量）、观测结果（测到了什么）、观测对象（测的是谁）、时间。

4-1 查询篇里的 KnowWhereGraph 就复用了 SOSA 来描述观测数据，新增观测要过 SOSA-SHACL 校验才能入库 [3]。在本篇里，"某格子的影像在某时点检测到了建筑"就是一条典型观测：传感器是卫星，观测对象是格子，结果是建筑足迹。同一个标准词汇，从气象观测一路用到影像检测——这就是标准词表的价值。

格子是不是对象，取决于业务需不需要引用它

第 3 跳的格子编号，正好撞上 4-0 概览留下的开放问题：格子是空间锚点，但它是对象吗？这里不再展开，只给一个现成对照（03 篇）：H3 编号写在 GeoSPARQL 字面量里只是一段文本，不是对象；KWG 给每个 S2 格子分配了全球唯一标识符（IRI），格子才成为一等对象 [2]。建到哪一层，取决于你的业务需不需要引用它、给它挂属性——考虑因素见 4-0 概览第六章 [4]。

跳表写的是依赖关系，不是执行顺序

到这里可以说一个本篇两个案例共同展示的现象：表格里的跳写成一行一行，不代表执行时要一步一步按顺序来。

看案例七：第 1、2、3 跳（解析存量地址）是一条链，第 4 跳（影像里检测建筑）是另一条链——两条链互不依赖，先做哪条都可以，也可以同时做，最后才在"有建筑足迹而无地址记录"这里汇合。案例六同样：查森林斑块、查保护区、查影像目录，三件事谁先谁后都行。

这对智能体（agent）执行查询是个实在的好消息：没有依赖关系的跳，可以任意排序、可以并行；有依赖关系的跳，才必须排先后。所以读这个系列的跳表，读的是依赖关系，不是执行顺序。选址篇的五个条件之间依赖更少，是更典型的例子，4-3 还会回到这一点。

本篇小结：本体给影像当索引，写回对应动力层

本篇的两个案例，一个从影像里发现"森林变差了"，一个从影像里发现"这里有人住了"，是同一架构的两个侧面：图谱管对象和语义，影像目录管影像发现，网格管栅格组织，各干各的，靠几何和标识符咬合。咬合不上的地方指向动力层：动作定义较少，写回这样的操作算是动作吗？也还没有标准动作（动作层空白）。

下一篇拿一个综合任务收束：选址——它听起来是分析研判，拆完之后会变成什么？4-3 选址篇见。

附录

A.1 构造案例口径

案例六：构造案例，未实际执行。STAC 目录、Sentinel-2 影像、OSM 森林与保护区标签均为真实存在的技术与数据。STAC 版本与维护方、采用情况于 2026-08-20 核查（见参考文献 [1]）。

案例七：构造案例，未实际执行。libpostal、Nominatim、H3/S2、what3words、Plus Codes、Google Open Buildings 均为真实存在的工具与数据集。

A.2 术语速查

STAC（SpatioTemporal Asset Catalog，时空资产目录）：描述时空数据资产的社区规范（Radiant Earth 基金会牵头维护，现行 v1.1.0，2024-09），遥感影像目录领域的事实标准；API 部分与 OGC API - Features 对齐。规范：https://stacspec.org/ 。

JSON Schema：给 JSON 文档定义结构并做机器校验的社区规范（以 IETF 草案族形式发布）；STAC 用它固定对象类型和属性结构。

结构校验：用机器自动检查一条数据记录是否符合规定的结构（字段齐不齐、类型对不对），不需人眼判断。

SOSA 本体：Sensor, Observation, Sample, and Actuator Ontology，W3C 推荐标准（2017，与 OGC 联合），统一描述传感器、观测、样本与执行器。

NDVI：归一化植被指数，用红光和近红外波段算出的植被长势指标。

DGGS：离散全球网格系统，把地球表面剖分成带编号的层级格子（03 篇专题 [2]）。

libpostal：开源地址解析库，统计模型训练，覆盖多国地址格式。https://github.com/openvenues/libpostal 。

Nominatim：OSM 官方地理编码服务，把结构化地址换成坐标。https://nominatim.org/ 。

H3 / S2：Uber、Google 分别开源的网格编码体系，给地球表面的格子发编号（03 篇有详细对比 [2]）。

what3words / Plus Codes：商用的民间地址编码，思路与网格编号相同——用短编码指代一块地方。

Google Open Buildings：公开的建筑足迹数据集，覆盖亚非拉大量地区。https://sites.research.google/gr/open-buildings/ 。

参考文献

[1] STAC 规范官网（维护方、规范文本、采用案例）：https://stacspec.org/ ；规范仓库 radiantearth/stac-spec，v1.1.0 发布于 2024-09-11（2026-08-20 经 GitHub API 核查）。

[2] 本系列 03 篇《GeoSPARQL 与 OGC DGGS》：动力层空白的完整讨论、格子编号两种形态的对比。

[3] SOSA/SSN：Semantic Sensor Network Ontology，W3C 推荐标准，2017-10-19：https://www.w3.org/TR/vocab-ssn/ ；KWG 复用 SOSA 与 SOSA-SHACL 校验，见本系列 02 篇《KnowWhereGraph》。

[4] 本系列 4-0 概览：《案例集概览——地理智能的地基是数据治理和查询》第六章。

[5] 案例七涉及的开源项目：libpostal https://github.com/openvenues/libpostal ；Nominatim https://nominatim.org/ ；Google Open Buildings https://sites.research.google/gr/open-buildings/ 。

版权声明：本文为CSDN博主「LadiesAndGentlemen」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qiupingzhao/article/details/163625924 开源 github