@pipeworx/geo-reconcile

Reconciles Wikidata items against OpenStreetMap features — the join a community mapping effort needs before linking or adding anything. Give a set of Wikidata Q-ids (or a SPARQL selector that picks out an arbitrary class, e.g. "every power station in country X") and an OSM tag filter; get back one of four DISTINCT verdicts per item — matched, ambiguous, unmatched, or error — scored on an existing wikidata= tag, cross-lingual name agreement, and distance. Built generic; Georgian power stations are the first proving case, not the scope.

Part of Pipeworx — an MCP gateway connecting AI agents to 1865+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

Tools

• reconcile_wikidata_osm({qids | sparql, osm_filter, languages, radius_m, overpass_timeout_s}) — resolves each Wikidata item's coordinate (P625) and labels in the requested languages, runs one Overpass bbox search for osm_filter covering every item, and classifies each item:
  • matched — a confident link, with the evidence: an existing wikidata= tag (ground truth) or name agreement + distance.
  • ambiguous — 2+ plausible OSM candidates (or 2+ OSM features already tagged with the SAME Wikidata item, a data conflict) — ALL returned with scores, never auto-resolved.
  • unmatched — the OSM search completed and nothing plausible was there.
  • error — the search did NOT complete for this item: it didn't resolve on Wikidata, carries no coordinate, or the Overpass call failed/timed-out/was capped. Never collapsed into unmatched — a failed lookup is not evidence of absence.

Auth

Keyless. All three upstreams (Wikidata API, Wikidata Query Service, OpenStreetMap Overpass API) are free and require no key.

Overpass calls are relayed through Pipeworx's egress proxy when the gateway provides one — overpass-api.de answers 429 then 521 to direct Cloudflare Worker egress while returning 200 to the same request from elsewhere (observed against this same host, fleet #1246; also true of the standalone overpass pack). A standalone (non-gateway) deployment of this pack calls Overpass directly and works from any non-Cloudflare-Worker environment without relay configuration.

The OSM leg fails over across public Overpass instances — overpass.kumi.systems, then maps.mail.ru, then overpass-api.de — via the helper shared with the overpass pack (shared/src/overpass.ts). kumi went dark ~2026-09-19 and overpass-api.de 406s our egress (fleet #2036), so with only those two the OSM leg was dead from then until fleet #2451 added mail.ru.

Data sources

• https://www.wikidata.org/w/api.php (action=wbgetentities) — labels and the P625 coordinate claim for each resolved item.
• https://query.wikidata.org/sparql — runs a caller-supplied SPARQL SELECT to discover the item set when sparql is given instead of qids.
• https://overpass.kumi.systems/api/interpreter — the OSM feature search within the bounding box covering every resolved item's coordinate, failing over to https://maps.mail.ru/osm/tools/overpass/api/interpreter and https://overpass-api.de/api/interpreter.

Notes for the next person:

• A wikidata= tag that points at a DIFFERENT item than the one being reconciled is treated as negative evidence, not ignored. OSM sometimes models several Wikidata-listed units as one combined feature (e.g. Georgia's Vartsikhe I–IV are four separate Wikidata items but the OSM ways for I, II and IV nearby are already tagged for Vartsikhe's aggregate Wikidata item, Q4104053) — silently letting name+distance "match" a unit to that already- claimed feature would tell a mapper to re-tag something that is correctly tagged for something else. Any such conflict forces the candidate's score to 0 (excluding it from matched/ambiguous) and is surfaced separatel

... View full README on GitHub