Page MenuHomePhabricator

Show OpenStreetMap features associated with Wikidata items
Open, Needs TriagePublic

Assigned To
None
Authored By
mxn
Aug 10 2017, 8:18 PM
Referenced Files
F31844378: image.png
May 27 2020, 4:16 PM
F28113197: image.png
Feb 4 2019, 8:19 AM
F28113207: image.png
Feb 4 2019, 8:19 AM
F9376333: overpass-wikidata-OSM-gadget.png
Sep 7 2017, 3:24 PM
F9024514: overpass-gadget.png
Aug 10 2017, 8:23 PM
Tokens
"Love" token, awarded by Pigsonthewing."Like" token, awarded by Arjunaraoc.

Description

A Wikidata item page would ideally include a map showing the OpenStreetMap features that have been tagged with the current Wikidata item. Direct links would make it a lot easier to navigate from a Wikidata item to the individual OpenStreetMap features. This workflow could be useful for quality assurance of Wikidata and OpenStreetMap data.

Because OpenStreetMap way, node, and relation IDs are unstable, it isn’t a good idea to add the IDs directly to a Wikidata item. Instead, we can use a third-party service such as overpass turbo to populate the map.

Event Timeline

For now, I’ve implemented this feature as a user script:

overpass-gadget.png (2×2 px, 630 KB)

It would be great to have this user script as a gadget.

Nice work @mxn !

BTW.. i noticed that on overpass, all dutch locations are inside france according to the search autocomplete...a bit weird...

I tried this out a few times, and saw this message on this page:

overpass-wikidata-OSM-gadget.png (486×438 px, 29 KB)

@debt, that message means nothing in OpenStreetMap is tagged with the current item’s QID. The map and its overlays are provided by overpass turbo, so the gadget is unable to customize that particular message or add an edit link. It might be a different story if an overpass turbo instance were to run on Toolforge I suppose. ;-)

For the majority of items it is no longer necessary to use Overpass, as the same can be accomplished with mapframe, which is now shown on every item with coordinates in P625.

@Jc86035 the excellent thing with the overpass query is that you can see that the Wikidata object is represented in Open Street Map and linked see Wikidata tag in Open Street Map ==> Open Street Map takes a small step direction 5 star of Open Data

image.png (267×1 px, 110 KB)

image.png (436×781 px, 301 KB)

Note that this is also possible with Sophox -- e.g. a SPARQL query can use Wikidata via federation together with all of OSM data itself (tags), plus attach the OSM geometry shapes to each wikidata ID it sees in the query result. Click "run query" under the example.

mxn removed mxn as the assignee of this task.May 21 2020, 7:28 AM

While not perfect, the Overpass user script does enable users to see which OpenStreetMap features are linked to the Wikidata item. (This is distinct from P625, which is about coordinates rather than OSM features.) The original idea at the hackathon was to have this functionality incorporated into Wikidata as a gadget, so I’ll leave this issue open.

We could significantly reduce the number of API calls by not having the script query overpass for certain classes of item (instances of human, taxon, academic paper, astronomical object, language, genome, chemical compound, etc.)

If the map display could also not appear for those classes, so much the better.

I think that would require a WDS query on every page load, which would spare one API by hammering another. 😉

I considered but haven’t gotten around to making the gadget only show the overpass turbo embed on demand. That embed is what performs the query, so showing it only on demand would speed up page load quite a bit on some pages. The map is already usually below the fold, so I figure it wouldn’t be so annoying to have to click to see the map.

Cant we cache the OSM value in Wikidata to minimize traffic-> OSM?

I think that would require a WDS query on every page load, which would spare one API by hammering another.

Would it? I'm no coder, but I would have thought the script can read the content of the page on which it occurs.

making the gadget only show the overpass turbo embed on demand

As a second choice, that would be good.

We could significantly reduce the number of API calls by not having the script query overpass for certain classes of item (instances of human, taxon, academic paper, astronomical object, language, genome, chemical compound, etc.)

If the map display could also not appear for those classes, so much the better.

I think that would require a WDS query on every page load, which would spare one API by hammering another.

Would it? I'm no coder, but I would have thought the script can read the content of the page on which it occurs.

It can, but for instance, there might only be a statement that the subject is an instance of an artificial language; a SPARQL query would be required to crawl up the subclass hierarchy to determine that it’s indeed a language. One workaround would be to build a flat list of subclasses of language and check for membership in any of those subclasses, but the blacklist would be quite large.

For the majority of items it is no longer necessary to use Overpass, as the same can be accomplished with mapframe, which is now shown on every item with coordinates in P625.

The purpose of this gadget is to show the item’s relationship to OpenStreetMap specifically, whereas P625 could be derived from some other map or map database with its own idiosyncrasies. In theory, we could have the gadget only show up when a P625 statement is present, without using the coordinate in that statement. However, there are plenty of geographical items for which there’s no coordinate in Wikidata but the QID is tagged in OSM.

I'm no coder, but I would have thought the script can read the content of the page on which it occurs.

It can, but for instance, there might only be a statement that the subject is an instance of an artificial language; a SPARQL query would be required to crawl up the subclass hierarchy to determine that it’s indeed a language.

Understood, but there are a few massively-used classes for which the script could not attempt to call overpass; such as humans, scholarly articles, Wikimedia categories, stars, chemical compounds, taxons, etc.

See query at: https://w.wiki/RpX

One challenge in Wikidata is that we merge a lot see

  • SPARQL merged items in country US with Property 625 the last days = 34 objects

image.png (1×2 px, 340 KB)

i.e. we need some kind of update of the Wikidata tag in OSM objects when a WD object has been merged if the Overpass query should work...

It would be nice to display multi-level OSM relations on wikipedia / wikivoyage. For example this hiking path: https://www.openstreetmap.org/relation/2110963 - note that this is a relation of relations, not a relation of ways. The wikidata element is here: https://www.wikidata.org/wiki/Q95735225. As far as I can see, the mapshapes template support only relations that have ways as members.

It would be nice to display multi-level OSM relations on wikipedia / wikivoyage. For example this hiking path: https://www.openstreetmap.org/relation/2110963 - note that this is a relation of relations, not a relation of ways. The wikidata element is here: https://www.wikidata.org/wiki/Q95735225. As far as I can see, the mapshapes template support only relations that have ways as members.

The Wikidata page should request this (or similar) OverPass turbo query in order to display the path:

[out:json][timeout:25];
rel(2110963);
(._;>>;);
out;

instead of the default

[out:json][timeout:25];
nwr["wikidata"="Q95735225"];
out body geom qt;
MSantos subscribed.

I'm removing the epic parent so it concentrates only on tasks related to WMF Maps code/infrastructure changes, please let me know if you have any questions or concerns.