4-1 查询篇的五个案例数据都是对象和关系。地理智能还有一大块数据没进场遥感影像。影像是栅格动辄 TB进不了也不该进图谱。那它怎么和图谱协作本篇两个案例是构造的但每一层的技术都真实存在来源见附录。一句话结论影像这类大而笨的数据要给它当好索引利用STAC查询影像算出结果比如统计值写回到系统中对应本体的动力层。案例六影像找出保护区内植被在退化的森林问题柏林周边位于自然保护区内、近两年植被明显退化的森林斑块有哪些跳这一跳问什么数据在哪用什么技术第 1 跳空间柏林及周边有哪些森林斑块OSMlanduseforest 标签图谱查询第 2 跳语义每块森林属于哪个保护区OSMboundaryprotected_area图谱查询第 3 跳发现覆盖这些森林的卫星影像有哪些影像目录STAC API第 4 跳计算每块森林两个时点的 NDVI归一化植被指数反映植被长势各是多少Sentinel-2 影像本身栅格计算可按 DGGS 网格组织第 5 跳回写把 NDVI 变化值写回作为森林对象的属性图谱目前没有标准做法笨办法QGIS 里手工叠加森林图层和保护区图层逐个斑块去哥白尼数据浏览器下载影像逐块算 NDVI填 Excel。一个周末起步结果还是死表。合理的做法图谱管对象和语义STAC 管影像发现网格管栅格组织各干各的靠几何和标识符咬合。本系列的框架里本体的六个要素是对象、属性、关系语义层和动作、函数、权限动力层。遥感影像是数据不是本体思想的载体。这个案例的看点是它两次碰到动力层——第 4 跳的栅格计算是函数第 5 跳的写回是动作。下面逐层看。STAC 是社区规范也是影像目录的事实标准关于第 3 跳的 STACSpatioTemporal Asset Catalog时空资产目录[1]。它是国际上的一个规范吗是但要分清是哪一类。STAC 不是 ISO 或 OGC 的正式标准而是一个开源社区规范由 Radiant Earth 基金会牵头的社区维护规范文本公开在 GitHub 上现行版本 v1.1.02024-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和外接框bboxproperties里必须带拍摄时间datetime云量eo:cloud_cover这类字段来自扩展、类型必须是数字assets里给出影像文件的地址。这些必须有、类型必须对的规矩全部写在 JSON Schema 里任何一条目录记录校验器能自动判断它合不合格——缺字段、类型错机器直接拒绝不用人眼看。做得到的意思就是一条记录合不合格从靠人读文档判断变成了机器自动判。第 3 跳查到了影像条目第 4 跳要算影像覆盖哪片森林——但 STAC 没有标准说法表达这块影像覆盖哪片森林森林是另一个图谱里的对象影像条目的 ID 出了自家目录就没人认识。所以影像几何与森林几何的空间求交要应用层自己算。这就是边界的含义结构校验管一条记录长得对不对管不了两个来源的数据说的是不是同一个东西。写回是动力层的动作目前没有标准做法第 5 跳暴露的是另一个空白算出NDVI 下降之后把它作为事实写回图谱没有标准动作可用——03 篇说过GeoSPARQL 和 DGGS 的动力层动作、权限是空白就是这个意思 [2]。值得强调的是写回这个动作确实体现了动力层里动作这个要素的思想。它不是查询——查询只读不改它是把一个新事实写进世界这里是图谱的受控操作。谁有权写、写到哪个对象上、写完要不要触发别的动作这些全是动力层问题目前这方面的内容较少。案例七寻址影像哪些格子住着人却还没有地址问题一个县去年新建的民房聚落有哪些它们该编进哪个地址网格地址是最典型的字符串之苦海口市美兰区××路12号对人是地址对机器只是一段文本。寻址addressing给地点分配可引用的名称或编号分两步走把地址文本解析成结构化成分再落到坐标——后一步叫地理编码geocoding。更麻烦的是世界上大量居民区根本没有门牌快递、急救、人口普查都卡在这地方叫什么上。这个案例是构造的但每个零件都真实存在跳这一跳问什么数据与技术第 1 跳语义地址文本拆成结构化成分国、省、市、路、号libpostal开源地址解析库统计模型训练覆盖多国地址格式第 2 跳空间结构化地址换成坐标NominatimOSM 官方地理编码服务第 3 跳网格坐标换成格子编号H3 或 S2——格子编号本身就是一种机器可读的地址。商用的 what3words三词地址、Google 的 Plus Codes 是同一思路的民间编码第 4 跳影像哪些格子里检测到了建筑却没有对应的地址记录卫星影像加建筑物检测Google Open Buildings 是公开的建筑足迹数据集覆盖亚非拉大量地区第 5 跳回写给新发现的聚落赋址写回数据库动力层——与案例六相同没有标准动作可用第 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 术语速查STACSpatioTemporal Asset Catalog时空资产目录描述时空数据资产的社区规范Radiant Earth 基金会牵头维护现行 v1.1.02024-09遥感影像目录领域的事实标准API 部分与 OGC API - Features 对齐。规范https://stacspec.org/ 。JSON Schema给 JSON 文档定义结构并做机器校验的社区规范以 IETF 草案族形式发布STAC 用它固定对象类型和属性结构。结构校验用机器自动检查一条数据记录是否符合规定的结构字段齐不齐、类型对不对不需人眼判断。SOSA 本体Sensor, Observation, Sample, and Actuator OntologyW3C 推荐标准2017与 OGC 联合统一描述传感器、观测、样本与执行器。NDVI归一化植被指数用红光和近红外波段算出的植被长势指标。DGGS离散全球网格系统把地球表面剖分成带编号的层级格子03 篇专题 [2]。libpostal开源地址解析库统计模型训练覆盖多国地址格式。https://github.com/openvenues/libpostal 。NominatimOSM 官方地理编码服务把结构化地址换成坐标。https://nominatim.org/ 。H3 / S2Uber、Google 分别开源的网格编码体系给地球表面的格子发编号03 篇有详细对比 [2]。what3words / Plus Codes商用的民间地址编码思路与网格编号相同——用短编码指代一块地方。Google Open Buildings公开的建筑足迹数据集覆盖亚非拉大量地区。https://sites.research.google/gr/open-buildings/ 。参考文献[1] STAC 规范官网维护方、规范文本、采用案例https://stacspec.org/ 规范仓库 radiantearth/stac-specv1.1.0 发布于 2024-09-112026-08-20 经 GitHub API 核查。[2] 本系列 03 篇《GeoSPARQL 与 OGC DGGS》动力层空白的完整讨论、格子编号两种形态的对比。[3] SOSA/SSNSemantic Sensor Network OntologyW3C 推荐标准2017-10-19https://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