Geo Reconcile

@pipeworx/geo-reconcile

将 Wikidata 条目与 OpenStreetMap 地理要素进行核对——这是社区制图工作在关联或添加任何内容之前需要进行的匹配。提供一组 Wikidata Q-id（或用于选取任意类别的 SPARQL 查询，例如“国家 X 的所有发电站”）和 OSM 标签筛选条件；即可为每个条目获得四种不同的判定结果之一：matched、ambiguous、unmatched 或 error。评分依据包括现有的 wikidata= 标签、跨语言名称一致性和距离。该工具按通用需求构建；格鲁吉亚的发电站是首个验证案例，而非适用范围。

属于 Pipeworx——一个将 AI Agent 连接到 1879+ 个实时数据源的 MCP 网关。这是一个独立的非官方集成，与上游提供方无关联、未获其认可，也非由其发布。

工具

• reconcile_wikidata_osm({qids | sparql, osm_filter, languages, radius_m, overpass_timeout_s}) — 查询每个 Wikidata 条目的坐标（P625）和指定语言的标签，针对覆盖所有条目的区域，对 osm_filter 执行一次 Overpass bbox 搜索，并对每个条目进行分类：
  • matched — 确认匹配，并附上证据：现有的 wikidata= 标签（事实依据），或名称一致且距离相符。
  • ambiguous — 存在 2 个或更多可能的 OSM 候选项（或已有 2 个或更多 OSM 地理要素标记了同一个 Wikidata 条目，属于数据冲突）——返回所有候选项及其评分，绝不自动确定。
  • unmatched — OSM 搜索已完成，但没有找到合理的匹配项。
  • error — 此条目的搜索未能完成：无法在 Wikidata 中解析该条目、该条目没有坐标，或 Overpass 调用失败、超时或受限。绝不会将其归为 unmatched——查询失败并不代表目标不存在。

身份验证

无需密钥。所有三个上游服务（Wikidata API、Wikidata Query Service、OpenStreetMap Overpass API）均免费且无需密钥。

当网关提供出口代理时，Overpass 调用会通过 Pipeworx 的出口代理中继——overpass-api.de 对来自 Cloudflare Worker 的直接出口请求返回 429，然后返回 521，但对来自其他位置的相同请求返回 200（在同一主机上观察到，fleet #1246；独立的 overpass pack 也存在同样情况）。独立部署（非网关）的 pack 会直接调用 Overpass，在任何非 Cloudflare Worker 环境中均可使用，无需配置中继。

OSM 部分会通过与 overpass pack 共享的辅助工具（shared/src/overpass.ts），在公共 Overpass 实例之间进行故障转移——先尝试 overpass.kumi.systems，然后是 maps.mail.ru，最后是 overpass-api.de。kumi 于约 2026-09-19 起停止响应，overpass-api.de 则对我们的出口返回 406（fleet #2036）；因此，从那时起直到 fleet #2451 添加 mail.ru 之前，只有这两个实例时，OSM 部分一直不可用。

数据源

• https://www.wikidata.org/w/api.php（action=wbgetentities）——每个已解析条目的标签和 P625 坐标声明。
• https://query.wikidata.org/sparql——当提供 sparql 而非 qids 时，运行调用方提供的 SPARQL SELECT 以发现条目集合。
• https://overpass.kumi.systems/api/interpreter——在覆盖所有已解析条目坐标的边界框内搜索 OSM 要素；失败时依次切换到 https://maps.mail.ru/osm/tools/overpass/api/interpreter 和 https://overpass-api.de/api/interpreter。

给接手者的说明：

• 指向与正在协调的条目不同条目的 wikidata= 标签会被视为负面证据，而不是忽略。 OSM 有时会将 Wikidata 中列出的多个单位建模为一个组合要素（例如，格鲁吉亚的 Vartsikhe I–IV 在 Wikidata 中是四个独立条目，但附近的 I、II 和 IV 的 OSM way 已经标记为 Vartsikhe 的汇总 Wikidata 条目 Q4104053）——如果只凭名称和距离就让某个单位“匹配”到那个已有其他条目认领的要素，就会误导地图编辑者重新标记一个已正确标记为其他对象的要素。任何此类冲突都会将候选项的得分设为 0（不纳入 matched/ambiguous），并单独显示在 nearby_conflicting_tags 中，以便人工发现粒度不匹配，而不是让它悄然消失。
• Overpass 对执行过程中超时或内存耗尽的查询也可能返回 HTTP 200，并附带顶层 remark 字段和不完整（有时为空）的 elements——如果天真地读取，这与“确实没有找到任何内容”逐字节都无法区分。本工具包会检查 remark 中是否包含超时、速率限制或运行时错误相关措辞，并将此类情况视为调用失败（所有受影响条目均变为 error），绝不当作真正的空结果。
• out center tags <N>; 有上限（当前为 4000 个要素），而不是不设限制，因为在大范围内执行无上限查询本身就可能导致超时。如果 Overpass 返回的数量恰好达到上限，响应中会设置 cap_hit，任何原本会返回 unmatched 的条目都会改为报告为 error——上限截断的结果无法保证该区域数据完整，因此本工具包不会声称“什么都没找到”。
• sparql 选择器只需绑定 ?item。 标签和坐标始终通过 wbgetentities 单独获取，因此 SPARQL 无需自行选择这些数据——这样可以让选择查询保持简单，并确保无论如何选择条目集合，都使用一致的标签和坐标获取路径。
• 已于 2026-09-10 使用格鲁吉亚的发电站完成在线验证：解析出的 171 个 Wikidata 条目中，有 23 个 OSM 要素已带有与其中一个条目匹配的 wikidata= 标签——这 23 个都被找回并判定为 matched，误报为 0。87 个条目尚无 P625 坐标（这是 Wikidata 数据中真实存在的当前缺口，并非此处的错误），并被正确判定为 error，而非 unmatched。
• 直接对照 OSM 重新检查这 23 个条目，会得到 24 个——多出的那个并非回归问题。 已于 2026-09-10 独立验证（fleet #1813）：覆盖整个格鲁吉亚的 nwr["power"="plant"]["wikidata"] Overpass 查询返回了 27 个要素，带有 24 个不同的 wikidata= 值。其中 24 个条目里的 23 个属于上述类别选择（wdt:P31/wdt:P279* wd:Q159719，wdt:P17 wd:Q230），且这 23 个全部被判定为 matched，每个匹配都由现有标签支持，而非依赖名称和距离。第 24 个是 Q4104053，即 Vartsikhe 发电站的汇总条目——这与前两条中描述的粒度不匹配相同。它不在结果中，是因为选择器从未请求它，并非本工具包将其遗漏。请对照已协调的条目集合，而不是直接对照 Overpass 的计数，否则你会追查一个并不存在的问题。

快速开始

将其添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "geo-reconcile": {
      "url": "https://gateway.pipeworx.io/geo-reconcile/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/geo-reconcile/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、discover_tools、search_within、remember/recall 和网关范围内的其他工具。因此，你看到的工具数量会多于表中的数量：目前，单个工具包端点除了列出该工具包自己的工具，还会列出大约 30 个共享工具。连接的 initialize 响应会说明其确切范围，是当天情况的权威依据。

这是有意为之，并非意外的多路复用。元工具可以让限定范围的连接回答本工具包未涵盖的问题——通过 ask_pipeworx 跨整个目录进行路由——无需你再添加第二个 MCP 服务。目前无法挂载不带这些元工具的工具包端点；如果额外的架构消耗的上下文超过了路由带来的价值，请连接一次完整网关，而不要连接多个工具包端点。

或者，连接完整的 Pipeworx 网关，直接列出所有工具包的工具，而不只是此工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都连接到同一个网关，以及相同的 1879+ 个数据源。唯一的区别是哪些工具包的工具会被直接列出；无论使用哪个 URL，ask_pipeworx 都能访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/reconcile_wikidata_osm \
  -H 'Content-Type: application/json' \
  -d '{"qids":["Q162887","Q3650523","Q4501177"],"osm_filter":"power=plant","languages":"ka,ru,en","radius_m":2000}'

首次调用无需账号。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/reconcile_wikidata_osm。查找工具：使用 {"query":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

独立运行（无需网关账号）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账号，也无需往返网关：

{
  "mcpServers": {
    "geo-reconcile": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-geo-reconcile"]
    }
  }
}

或者直接运行以确认其可以启动：

npx -y @pipeworx/mcp-geo-reconcile

它通过 stdin/stdout 使用 MCP，并为仅此工具包的工具处理 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。相同的源代码、相同的工具，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗英语提问，而不是直接调用工具——这既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Geo Reconcile data" })

网关会自动选择合适的工具并填入参数。

更多内容

• 文档和指南
• pipeworx.io

许可证

MIT