本篇是一个小系列的概览。这个系列用八个真实或可复现的地理智能案例回答一个问题跨库、多跳、多源的地理查询为什么有的系统几秒答完有的做法要一个人干一整天。一篇概览本篇查询、影像、选址三篇再加一篇收尾。一、两句大白话跨网搬数据才慢数据没治理就白搭1.1 第一句慢在跨网搬数据数据搬到本地就没这个问题联邦查询一条查询跨多个服务端点发问靠 SPARQL 的SERVICE关键字实现慢在哪慢在查询到一半要隔着网络去另一台服务器上现拉数据中间结果在网络上来回搬数据一大就快不了对方服务器还可能正宕机。那是不是说如果所有的数据都在本地就不存在跨端点拉数据这个问题了对就是这样。这正是两个真实系统的实际做法QLever 把 Wikidata 和 OpenStreetMap 各装一份在自家机器上KnowWhereGraph 把 30 多个数据集一次性搬进自家图谱。可以这么记标准是联邦的数据是本地的副本。联邦查询标准真正的价值不是永远实时跨网查而是数据就算搬到本地各方仍然能用同一套词汇互相查询——哪天需要接一个新来源不用重新发明对接方式。1.2 第二句一条链能答出多少由最弱的一环决定一条多跳查询像一条链条一环扣一环。柏林的轨道车站数以百计但标了运营商编号的只有 16 个于是车站分别归谁运营这个问题就只能答出 16 个——不是查询引擎不行是数据没标。这个系列里每个案例都会撞见同一条规律一条链式查询的答案天花板由链条上最弱一跳的数据覆盖率决定。说穿了就是一句大白话数据治理得不好什么高科技都白搭。查询引擎再快、大模型再聪明数据没标、没对齐、没更新答案就出不来。这句话里的数据治理在本系列里有固定所指数据治理就三件事——①立图纸把对象、属性、关系定义清楚静态本体定义②缝数据让不同来源的数据对上号跨库对齐③管质量入库前校验、入库后保鲜。1.3 读法约定一跳是一次跨越反复出现的规律带下划线一跳就是从一个对象走到另一个对象的一次跨越。柏林有哪些公园是一跳柏林→公园公园的创办者是哪国人是三跳柏林→公园→创办者→国籍。跳数衡量查询的深度数据源个数衡量对齐的宽度。两者相乘大致就是工作量。二、八个案例覆盖三类任务查询、影像、选址案例一句话在哪篇案例一2 跳柏林 12 个区每个区每万居民拥有多少个公园4-1 查询篇案例二3 跳柏林的铁路车站分别由哪些公司运营4-1 查询篇案例三4 跳柏林的雨水顺着水系最终流进哪片海4-1 查询篇案例四5 跳柏林 247 家博物馆的创办者分别是哪国人4-1 查询篇案例五多源得州哈里斯县哪些山火的路径与机场相交KnowWhereGraph 的预付路线4-1 查询篇案例六影像柏林周边位于自然保护区内、近两年植被明显退化的森林斑块有哪些4-2 影像篇案例七寻址影像一个县去年新建的民房聚落有哪些该编进哪个地址网格4-2 影像篇案例八选址在海口给一家连锁便利店选出三个候选铺位4-3 选址篇证据口径一次说清案例一至四在 QLever 公共端点上真实跑过2026-08-13原始结果留档案例五来自 KnowWhereGraph 2025 年系统论文的能力演示本系列 02 篇已核查 [1]案例六至八是构造的但每一层技术都真实存在附录里逐条列出来源。三、两种切法都成立本系列按任务维度展开八个案例可以按两个维度分类。维度一任务维度——系统在干什么活。案例一到五是查询把已经对齐的数据问出来案例六、七是影像分析遥感影像太大不进图谱图谱给它当索引案例八是选址多准则综合判断。维度二本体维度——用到本体的哪一层。本系列的评估框架把系统能力分两层语义层对象、属性、关系描述世界有什么、谁连着谁和动力层动作、函数、权限规定如何改变世界。八个案例的大部分跳数都在语义层但案例六、七里的把计算结果写回数据库已经踩进了动力层——写回是一个动作。本系列按任务维度展开成三篇本体维度则作为暗线贯穿各篇在 4-4 收尾篇的横评里收拢。四、四篇分工查询、影像、选址、收尾4-1 查询篇柏林的四个实测问题加一个美国应急图谱的论文案例。看点是跨库查询为什么快、为什么有时候会慢以及全球唯一标识符这个反复出现的东西到底是什么、是不是哪个项目自造的。4-2 影像篇遥感影像动辄 TB进不了也不该进图谱那它怎么和图谱协作看点是 STAC 影像目录规范、JSON Schema 结构校验、传感器观测的国际标准以及写回这个动作为什么至今没有标准做法。4-3 选址篇选址听着是分析研判拆完会变成什么本篇附一个单独讨论假设数据都治理好了、查询都跑通了分析研判的瓶颈还剩在哪。4-4 收尾篇把八个案例里出现的五种做法放在一起比较说清技术选型盘点数据治理之后还剩哪些技术活。五、三条共性思考智能的地基是普通的事做扎实第一这些案例本质上做的事就两件数据治理和查询。剥掉知识图谱“本体”联邦查询这些词剩下的活是把数据定义清楚、对齐好、管起来然后能查。第二我们以为的智能是分析研判但分析研判的前提是能够查询。连信息的快速收集都做不到就不可能去做高阶的分析研判——分析研判无从谈起。案例会反复展示这一点选址听起来是研判拆到最后发现瓶颈在数据准备问答听起来是智能拆到最后发现功夫在建库时的对齐。第三把普通的事做出来恰恰就是智能的样子。当我们把数据治理和查询做出来了大家都会觉得它很普通、很 easy——不就是查吗。但我们想要的那个智能恰恰是我们觉得很普通的事情一点一点做深、做扎实之后的样子。或者说那些看起来很普通的事是智能的必经之路。六、开放问题格子是不是对象没有标准答案留给读者也留给我们自己。这个系列里网格反复出现案例五的 S2 格子、案例七的 H3 格子都是空间锚点把不同来源的数据缝在一起。但有一个问题不容易回答格子是一个对象吗在本体语境下一个东西该不该建模为对象显然跟业务有关但还是有几个通用的考虑因素它需要被别的东西引用吗如果这场火烧过的格子要被火灾记录指向格子就得是一个可被引用的对象。它需要挂自己的属性吗比如这个格子的级别“这个格子的人口”。只有编号、不能挂属性的更像一个值而不是对象。业务上要不要区分同一个和另一个两个数据集说同一个格子时靠的是同一套编号体系还是各自编码、需要再对齐一次本系列 03 篇记录过一个现成的对照 [2]H3 格子编号在 GeoSPARQL 的字面量里只是一段文本字符——它不是对象不能被引用不能挂属性而 KnowWhereGraph 给每个 S2 格子分配了全球唯一的资源标识符格子这才成为一等对象可以被关系指向、可以挂级别属性。编号解决机器怎么算重叠把编号升格为对象解决别人怎么引用它。你的业务需要到哪一层网格就该建到哪一层——这个问题没有标准答案欢迎带着你的场景来讨论。七、欢迎一起讨论这个系列会持续分享地理空间智能相关的内容。大家有问题可以在下面留言后面也会建一个群让大家一起来交流。参考文献[1] KnowWhereGraph 系统论文The KnowWhereGraph: A Large-Scale Geo-Knowledge Graph for Interdisciplinary Knowledge Discovery and Geo-Enrichment. arXiv:2502.138742025https://arxiv.org/abs/2502.13874 核查过程见本系列 02 篇《KnowWhereGraph》。[2] 本系列 03 篇《GeoSPARQL 与 OGC DGGS》格子编号作为字面量与作为一等对象的两种形态对比见其第四章。[3] 本系列原 04 篇《多跳跨库案例集——本体的必要性从哪来RDF 是不是唯一选择》本系列的原始长文保留未动八个案例的实测原始 JSON 留档路径见其附录。版权声明本文为CSDN博主「LadiesAndGentlemen」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。原文链接https://blog.csdn.net/qiupingzhao/article/details/163625924 开源 github