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

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:

@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. ;-)

@mxn - gotcha, thanks :)

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

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.

The new user script link is https://www.wikidata.org/wiki/Wikidata:Tools/Enhance_user_interface#overpass

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?

In T173052#6154762, @mxn wrote:

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.

In T173052#6161088, @Pigsonthewing wrote:

In T173052#6154762, @mxn wrote:

In T173052#6154753, @Pigsonthewing wrote:

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.

In T173052#4857228, @Jc86035 wrote:

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.

In T173052#6161412, @mxn wrote:

In T173052#6161088, @Pigsonthewing wrote:

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

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.

In T173052#6204992, @Whitepixels wrote:

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;

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.