Page MenuHomePhabricator

Commons .map doesn't support ExternalData such as WikiData ids, SPARQL query, or another .map
Open, MediumPublic


For example, if a .map contains a Wikidata id, the entire map will fail to display when called via <maplink> or <mapframe>. This page demonstrates the problem.

This limitation should be documented, and a decision made about whether the software should allow ExternalData here, which would in turn allow for recursive GeoJSON loading. As with the parser, any potential recursion would have to be bounded in time and memory.

NOTE: the Collaboration Team has prioritized this item for action as part of Map Improvements 2018, but there is concern that we don't know how difficult the task might prove. Our intention is to investigate and, if fixing proves too hard, fall back to some other remediation that will warn the user or somehow fail gracefully.

Event Timeline

debt added a subscriber: debt.

Hi @Gareth - it appears that you're missing the lat/lng in your map sample. Please refer to this page for mapframe samples with wikidata.

JGirault added a subscriber: JGirault.

@debt This is a valid bug, I'm reopening it.

The problem here isn't missing latitude/longitude (which are unofficially optional).
The problem here is the ExternalData chain is not respected:

  • Our data loader is able to retrieve External Data from Commons or from the Geoshape/line/mask service.
  • Once the data is retrieved, it is considered valid GeoJSON. But in this instance, we are getting invalid GeoJSON with ExternalData, meaning the script should parse that and make another series of API call to the Geoshape/line/mask service in order to retrieve valid GeoJSON.

It could be considered a limitation (kind of frustrating though), or rather it could be limited to some extent: we do not want to loop over the data infinitely. What if a data page on Commons loads another data page on Commons and so on? We don't want this to happen.

Anyway, if we decide to support this to some extent, we need to make improvements to the wikimedia-mapdata script.

debt triaged this task as Medium priority.Oct 18 2017, 2:50 PM
debt added a project: Maps-Sprint.
debt added subscribers: Yurik, Evad37.

Moving to the sprint board, as we have a couple other related issues that this issue might be able to piggy-back onto as community work is being done: T178370 and T178321

This comment was removed by Abbe98.

@Mholloway, we discussed this in today's Discussion Meeting (which was a kind of maps triage meeting). As per the "Note" at the top in blue, what have you learned about this task? Will we plan to fix it or to warn users?

@JGirault's analysis is accurate, and I think fixing this is a complicated enough undertaking to be beyond the scope of Map Improvements 2018. That said, we could provide better error messages about what's going on, and update the docs to clarify the current inability to load chained ExternalData.

Mholloway removed a project: Maps-Sprint.
Mholloway added a subscriber: Mholloway.

Are we sure this is just with wikidata ids etc ? I see something like this with even a simple .map page

<mapframe width=300 height=300 zoom=17>
  "type": "ExternalData",
  "service": "page",
  "title": "Haarlem/Grote"

Rendered on nl.wp, as if it is located in Algeria instead of in Utrecht, Netherlands

@TheDJ It sounds like you are describing a different problem (and one I can't reproduce). Do you have a page published that demonstrates this?

To your broader point, I think you are correct that the problem in this task doesn't turn on the presence or absence of Wikidata IDs; I think this is a specific example of the general problem that the map loader can't handle chained ExternalData references, and if present they will prevent the map from loading at all.

awight renamed this task from Maps that contain Wikidata ids and are stored on Commons fail to display when called via <maplink> or <mapframe> to Commons .map doesn't support ExternalData such as WikiData ids, SPARQL query, or another .map.Mar 25 2022, 9:49 PM
awight updated the task description. (Show Details)

Was it intended in the first place to support "data":{"type":"ExternalData"}? This seems to be undocumented on help page. Shouldn't <maplink/mapframe> and other data reusers just query OSM data and other map data pages directly?

Note that currently only 11 data pages (of which only 3 are not sandbox subpages) use ExternalData on Commons. So maybe it wouldn't be too difficult to disable this confusing "feature"?