OpenStreetMap has a wikidata tag which lets us connect OSM objects to their corresponding Wikidata items.

(Technical note: it’s a “same as” relationship - i.e. the tag asserts that the two items in different systems refer to the same entity. However, sometimes things in OSM are split into multiple objects; and sometimes one object in OSM actually refers to multiple items in Wikidata. So it’s actually a “many-to-many” matching, not “one-to-one”: a single OSM object sometimes has multiple semicolon-separated Wikidata identifiers, and multiple OSM objects sometimes have the same Wikidata identifier.)

There are over 600,000 OSM objects with the “wikidata” tag. OK great, job done? I mean, nothing’s ever “complete” in these big open-ended crowdsource projects, but if we have more than half a million crosslinks between the systems, that’s really good going.

BUT THERE’S A PROBLEM!

Using the tag to jump from OSM to Wikidata works fine. But from Wikidata to OSM? Well, there’s no persistent way to link from wkd->osm, simply because OSM’s identifiers are impermanent - they’re not guaranteed to continue existing, or to continue referring to the same thing. So it’s not particularly sensible to store OSM identifiers in Wikidata. Instead, an Overpass lookup is required.

For example, on the OSM Wikidata page I found this friendly Wikidata interface called “Reasonator” - all very nice, but instead of cross-linking immediately to the OSM object, it offers a little “Overpass” link which you can click to do a dynamic lookup.

The effect is that it makes Wikidata->OSM connections indirect, obscured, only-for-those-who-know-they-want-it. If a Wikidata coder says “OK great how do I jump to the item in OSM?” you first have to teach them what Overpass is and how it relates to OSM, then how to use its query language, how many queries a day you’re allowed to do on Overpass… bleh.

PROPOSED SOLUTION

Pretty simple proposal, then: a script that produces a Wikidata->OSM lookup table. This could be run as a weekly cron job perhaps (or something monitoring minutely diffs for any changed wikidata tag? dunno) and it could produce a lookup table that is easy for non-OSM users to consume. For example, it could produce a big CSV file like this:

 Q1002133,node/29541385
 Q1002826,node/20919015
 Q1002845,node/241795518
 Q1004173,way/38387732
 Q1004824,node/29164070
 Q1026205,node/410291638,relation/1061137
 Q1005234,relation/2797450
 ...

and a JSON file like this:

 {
 "Q1002133": [["node",29541385]],
 "Q1002826": [["node",20919015]],
 "Q1002845": [["node",241795518]],
 "Q1004173": [["way",38387732]],
 "Q1004824": [["node",29164070]],
 "Q1026205": [["node",410291638], ["relation",1061137]],
 "Q1005234": [["relation",2797450]],
 ...
 }

and then what might be useful could be for these to be published at a stable location, for other programmers to make use of dynamically. The intention is to make it easy for someone with no OSM knowledge and no GIS knowledge to be able to hook OSM into their open data ecosystem.

I wrote a Python script that makes these lookup tables. On my home desktop, it takes about 2 minutes to scan the UK extract; for the whole planet file, it takes a lot longer… 90 minutes! Oof. (The CSV and JSON files produced are 14 MB & 19 MB in size.)

Your thoughts?