Page MenuHomePhabricator

Investigation: display SPARQL queries in a map in Wikipedia
Closed, ResolvedPublic5 Estimated Story Points

Description

Background

The wish to display coordinates produced by a SPARQL query on a map came up in our initial interviews and has been a longstanding ticket T188291: Display point features (coordinates) from the results of a SPARQL query on a map in Wikipedia. We see adding this functionality as being a potential key improvement for Kartographer and its usefulness for Wikipedia users.

Questions to answer:

  • Is it possible to implement this?
  • How much effort is it?
  • Why hasn't it been done already?

Answers

It should be possible to implement this. Kartotherian already handles SPARQL queries for geoshapes. So we can re-use that mechanism and ask in a query for a list of datapoints as well as their coordinates. The implementation to display them should be easier than the geoshapes who have an extra database for caching OSM data. A simple implementation that displays datapoints (without further features like images and colors) should be managable.

Related:

Proof of Concept

<mapframe text="Churches in Jerusalem" width=300 height=300 zoom=5 longitude=31.77917 latitude=35.22361>
{
  "type": "ExternalData",
  "service": "geopoint",
  "query": "SELECT distinct ?id ?geo WHERE {?id wdt:P31/wdt:P279* wd:Q16970; wdt:P625 ?geo. ?id p:P131 ?statement1. ?statement1 (ps:P131/(wdt:P131*)) wd:Q1218.} LIMIT 2"
}
</mapframe>

Screenshot from 2022-02-18 17-59-45.png (459×413 px, 184 KB)

Open questions / Follow up tasks

IDs

  • Do we want to support a single (or a list of) Wikidata ID input by the user (to display the location of one wikidata entry)? This is also implemented for GeoShapes (example).
  • Could we also use a single ID input to display a set of geopoints? Where would we find an ID that can be used to define a set of geopoints?

Properties ➔ T302290

Possible properties are: icon types, colors, labels, etc. This could be implemented in steps:

  • Set a default styling of markers when the user doesn't add any themselves.
  • Allow users to set a styling of the markers outside of the sparql query.
  • Allow users to to define properties for geopoints the same way as for geoshapes (as part of the sparql query)?

Caching (devs) ➔ T302291

Details

Related Changes in Gerrit:

Event Timeline

Lena_WMDE set the point value for this task to 5.Jan 26 2022, 2:36 PM

Change 763242 had a related patch set uploaded (by Svantje Lilienthal; author: Svantje Lilienthal):

[mediawiki/services/kartotherian@master] [POC] geopoints via sparql

https://gerrit.wikimedia.org/r/763242

Change 763245 had a related patch set uploaded (by Svantje Lilienthal; author: Svantje Lilienthal):

[mediawiki/extensions/Kartographer@master] [POC] added geopoints

https://gerrit.wikimedia.org/r/763245

Change 763751 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/services/kartotherian@master] Basic test for geoshapes

https://gerrit.wikimedia.org/r/763751

Change 763751 merged by jenkins-bot:

[mediawiki/services/kartotherian@master] Basic test for geoshapes

https://gerrit.wikimedia.org/r/763751

https://www.mediawiki.org/wiki/Help:Extension:Kartographer#GeoShapes_via_Wikidata_Query
@lilients_WMDE Are you planning to explore implementing marker styling in the same was as here? Where the styling is integrated into the SPARQL query itself? I think it would make sense for it to behave in the same way if we are able to add the possibility of styling so that users don't have learn two separate ways of going about it.

Also maybe the styling investigation needs a follow-up ticket? Would be nice to outline in the task description the elements we are exploring, for example marker size, color, icon, title, numbering, lettering. Then if it's hard to do all of them, we could prioritize.

@ECohen_WMDE Yes, I also think it would make sense to go the same way as the geoshapes query is working. That should not be very complicated. I would try that out.

I am not sure about the follow up ticket. When we use the geoshapes approach all the properties would come from the sparql query and we would simply pass them on. So if I understood that correctly we do not need to handle them seperatly. The main work would be lying in formulating the SPARQL query and that would be something the user would do. 🤔

Update: We defined 3 areas where we should continue working. All could be follow up tickets.

A few comments on the questions added to the task below. I'll also add my own open question about the default styling.

IDs

Do we want to support a single ID input (to display the location of one wikidata entry)?

Do you mean if the result of the query is only one coordinate? Then yes. It would be a bit weird if it stopped working in this case, since I think it's mainly about displaying the results of a query, which may or may not be multiple points.

Do we want to support a list of ids?

This seems like a different feature, though could be pretty valuable. Discussed with @Lena_WMDE and added to story time agenda to discuss as a group.

Could we also use a single ID input to display a set of geopoints? Where would we find an ID that can be used to define a set of geopoints?

I'm not sure that's a thing? I haven't come across a QID that had multiple points (that wasn't a geoshape).

Properties

Do we want to implement the definition of properties for geopoints (icon types, colors, etc) the same way as for geoshapes (as part of the sparql query)?

Seems like we are agreed on doing this? Are there other alternatives that we should discuss? This could also go in the story time agenda potentially.

Do we want to add a default properties entry to the wikitext?

Not sure what this one means?

Thanks @ECohen_WMDE. I tried to make the points in the ticket desription a bit clearer.

IDs

Do we want to support a single ID input (to display the location of one wikidata entry)?

Do you mean if the result of the query is only one coordinate? Then yes. It would be a bit weird if it stopped working in this case, since I think it's mainly about displaying the results of a query, which may or may not be multiple points.

I meant the use case that is also implemented for GeoShapes, where a user can enter a single Wikidata ID or a list of them (instead of a sparql query). The code checks the geo coordinates and displays the geoshape. We could do the same for geo points. And because the code is already there for GeoShapes it should not be hard.

Do we want to support a list of ids?

This seems like a different feature, though could be pretty valuable. Discussed with @Lena_WMDE and added to story time agenda to discuss as a group.

Yes, lets discuss this in story time. :)

Could we also use a single ID input to display a set of geopoints? Where would we find an ID that can be used to define a set of geopoints?

I'm not sure that's a thing? I haven't come across a QID that had multiple points (that wasn't a geoshape).

Me neither. :) Maybe there is nothing.

Properties

Do we want to implement the definition of properties for geopoints (icon types, colors, etc) the same way as for geoshapes (as part of the sparql query)?

Seems like we are agreed on doing this? Are there other alternatives that we should discuss? This could also go in the story time agenda potentially.

Yes, I also think this would make sense. I added our ideas from our meeting today also to the ticket description above (1. set fall back, 2. allow user to set default, 3. properties in sparql).

Do we want to add a default properties entry to the wikitext?

Not sure what this one means?

I meant we could allow the user to enter a default set of properties to the wikitext outside of the sparql query. This would mean that all icons could be displayed the same. But they could also be overwritten by properties from the sparql query.

Styling

What is the default styling of markers when the user doesn't add any themselves?

Good question, the current default styling looks like a grey pin without any icon. I guess we could add a nicer default one. I added that to the properties section.

Is there potential to pull information from Wikidata for labels/titles?

Yes, they would be pulled via the sparql query (see GeoShape example).