Apps-android-commons: Switch to Wikidata in addition instead of wiki-needs-pictures

Created on 7 Oct 2016 · 37Comments · Source: commons-app/apps-android-commons

I started to wonder whether we should use Wikidata instead of wiki-needs-pictures.

Advantages of Wikidata:

Real-time. Add a picture to the item, and it disappears from the map immediately. wiki-needs-pictures is only updated once a week.
Fast: In my tests the WikiData request takes about 2 seconds (even in an area with many items needing pictures), compared with wiki-needs-pictures' 17 seconds on the same network connection.
Data plan-friendly: Wikidata uses only a few kilobytes, whereas wiki-needs-pictures downloads a file of several megabytes every time the app is started. This is thanks to WikiData has out-of-the-box area queries. Implementing area queries for wiki-needs-pictures would require a lot of development and a good server.
Memory-friendly: Not having to keep this multimegabytes file in memory.
Works for all Wikipedias, unlike wiki-needs-pictures which needs custom code for each Wikipedia (I added that code for the Japanese Wikipedia)

Advantages of wiki-needs-pictures:

Listed pictures really need someone to go there and take a picture (whereas on Wikidata most missing pictures are actually available on Commons and just not linked yet, see WDFIST).
Special requests may be implemented in the future. For instance: there are are already pictures of this temple's exterior, but a picture of the inside is needed.

All of the API requests we need (and more) can be found in the new WikiShootMe: https://tools.wmflabs.org/wikishootme/

When this WDFIST issue is fixed, I think we should also link to WDFIST like WikiShootMe does. For Wikidata items that do not have an image, it proposes some found on the Wikipedia articles linked to this item. Extremely useful before deciding whether walking that 2 kilometers detour is really worth it.

enhancement nearby question

Source

nicolas-raoul

👍1

Most helpful comment

I improved the Wikidata query, try it!

It now displays each item's label and type (if available) in the user's language, so an anglophone will see "Eiffel Tower (building)" while a Japanophone will see "エッフェル塔 (建物)" for instance. This can be useful to add a bit of information to map markers or list details. I also introduced the "class" column for icons, because QIDs are much more stable than labels.

By the way, is it planned to be developed soon? I believe we all agree that it would be a huge improvement over downloading a huge CSV file each time :-)

nicolas-raoul on 21 Mar 2017

👍2 ❤1

All 37 comments

I'm not familiar with either of these APIs, but using Wikidata sounds like the more flexible and future-proof way to go. The main point against WD right now, as I see it, is "most missing pictures are actually available on Commons". Maybe there could be a side project to add an extension that suggested Commons pictures as well, based on coordanate proximity and/or names?

The "special requests" bit doesn't sound like a complete showstopper to me: If the inside of a building is particularly interesting, isn't it often because there's a special piece of art inside, which may have its own WD item? I honestly don't know how commonly or rarely that happens.

LarsSimonsen on 7 Oct 2016

@LarsSimonsen The WDFIST paragraph in my post above could help solve this "unused pictures" problem. Unfortunately I have not been able to make it work on Android, as described at the link.

Indeed, I am not sure there are that many "special requests". We should try to estimate their number. I agree with your assertion that it is not a show-stopper. By the way, it is not implemented in wiki-needs-pictures either.

nicolas-raoul on 7 Oct 2016

I am a strong supporter of switching to a Wikidata-based list. This is exactly what is needed. Currently there is usually 1-2 picture opportunities in your neighborhood. Using Wikidata there are dozens which are just a few hundred meters from you - which really turns this into an exciting challenge! Manually updated lists are usually boring and outdated in many language editions.

We are using a WD query to search for nearby items and it works perfectly:
http://tinyurl.com/h3ncs53

edit: or WD query for items without picture here:
http://tinyurl.com/gn9djdu

VojtechDostal on 7 Oct 2016

👍1

About the special request pictures: I think there are basically 2 common cases, which we can currently not solve, but that might be something for the next grant:
1) Places with existing images and details missing: A campaign is created with specific requirements: Select all churches nearby and send the user there to take pictures of the interior. -> So this is basically just a campaign with a campaign description.

2) Even more specific requests, where each item in the list needs a description. For this we could host a list on a server and let users enter coordinates and request texts themselves. This could look similar to the campaigns in the app.

In both cases the problem is that we need to allow the user to check off items from the list, as the query will not be able to show if an image has been taken. For something like WLM of course there is no checking off, because multiple people can visit one place during the campaign.

And another thing for the future about the problem of places that already have images:
Maybe the app also needs sort of an item-page. For example a user could click on an item in the nearby list and then see all the images that are on Commons in the items' category. Then the user can select an appropriate image and it could be added to Wikidata automatically using OAuth.

tobias47n9e on 7 Oct 2016

@tobias47n9e : Thanks for the analysis!
I believe WDFIST covers your last paragraph, so better just link to WDFIST from our app than reimplement it, I would say.
About your before-last paragraph I created this issue: https://github.com/alemela/wiki-needs-pictures/issues/25

nicolas-raoul on 8 Oct 2016

Any thoughts on the use of this API? http://tools.wmflabs.org/articles-by-lat-lon-without-images/index.php?wiki=en&lat=51&lon=-0.1&radius=10000&reencode=true

The Pebble watch app by Sage Ross uses it, and it seems to give me good results. We could let the user pick which wiki they want, so maybe it would work for non-English locations? I tested with a point in Japan (can't read Japanese so no idea if the results are relevant though): http://tools.wmflabs.org/articles-by-lat-lon-without-images/index.php?wiki=jp&lat=36&lon=138&radius=10000&reencode=true

Also not sure how often it is updated.

misaochan on 7 Nov 2016

What is the advantage of this articles-by-lat-lon-without-images API, compared to the Wikidata API? Simpler syntax? Faster maybe?

A problem is that it seems to only consider the articles of a single Wikipedia, for instance "en".

nicolas-raoul on 7 Nov 2016

Based on what I have read about the articles-by-lat-lon-without-images API, I thought that the advantage would be negating this issue:

On Wikidata most missing pictures are actually available on Commons and just not linked yet

Or am I misreading that?

Also, err, I could potentially reuse some code from the Pebble app's GitHub repo, haha. :) It is written in JS, but still helpful.

misaochan on 7 Nov 2016

Interesting approach, thanks! Too bad it does not get more languages wikipedias, for instance the user's language + English + the languages used at the specified location.

By the way, the API internally just gets articles and parses them to check whether they contain an image: https://github.com/Abbe98/articles-by-lat-lon-without-images-service/blob/master/index.php so no need for updates, it is real-time, I think. I am afraid this approach might be fooled by transcluded images though.

nicolas-raoul on 7 Nov 2016

Using this API means we don't get important items such as this one: https://www.wikidata.org/wiki/Q26589362 because it does not have a Wikipedia article, despite being on UK's National Heritage List.
Also, it seems not all data comes up, I submitted an issues about that: https://github.com/Abbe98/articles-by-lat-lon-without-images-service/issues/4

nicolas-raoul on 7 Nov 2016

Updated Wikidata query example

nicolas-raoul on 7 Nov 2016

Ah okay, thanks for the feedback @nicolas-raoul !

misaochan on 7 Nov 2016

I improved the Wikidata query, try it!

By the way, is it planned to be developed soon? I believe we all agree that it would be a huge improvement over downloading a huge CSV file each time :-)

nicolas-raoul on 21 Mar 2017

👍2 ❤1

Awesome! :)

@nicolas-raoul We are planning to work on it during the pre-hackathon/hackathon, and if needed I'll wrap up any loose ends afterwards.

misaochan on 21 Mar 2017

I'm trying to produce a minimum viable product of this, hopefully by the hackathon. In any case, by trying, I hope I can see how much work needs to be done for completing the transition.

By "minimal" I mean Wikidata-derived icons etc would not probably be included by then, for example.

whym on 13 Apr 2017

👍1

@whym: Wonderful!
If you have any kind of Wikidata/SPARQL question don't hesitate to ask me :-)

nicolas-raoul on 13 Apr 2017

That would be great, thanks @whym ! Even if it doesn't fully work, it would be nice to have a base to start from during the pre-hackathon.

misaochan on 13 Apr 2017

Here is the query I'm using. It's mostly yours @nicolas-raoul, with slight modifications.

I tried including emojis in the results - they may render consistently than icons to the user. On the other hand, icons cover a larger range of things.

How do I properly do the recursive searching of the nearest superclass' icon/emoji? For example, when both "hospital" and its superclass "building" have an icon, a simple property path expression returned the "building" icon for me, which is not ideal.

EDIT: query changed.

whym on 13 Apr 2017

Unfortunately there is no recursion structure in SPARQL, but here is how you could do it.

nicolas-raoul on 13 Apr 2017

@whym You are right that Wikidata contains many false positives (Wikidata items without a picture even though the Wikipedia article has pictures). However:

wikipedia-needs-pictures has many false negatives (articles that have pictures but not of the main subject, for instance an article about a mountain peak that only has pictures of the mountain range and animals present in the area)
Wikidata is filling the gap very fast. I matched pictures myself for pretty much all of central Tokyo. It is easy and fun using Wikidata Game ("Image" game), or much faster using this WDFIST query.

nicolas-raoul on 14 Apr 2017

@nicolas-raoul Also HarvestTemplates is very useful for getting images from Wikipedia to Wikidata in an automated way : https://tools.wmflabs.org/pltools/harvesttemplates/

VojtechDostal on 14 Apr 2017

👍1

I've pushed the new release with Wikidata queries to beta (v2.2), so please opt in to beta testing and help us test it. :) Will leave this thread open for feedback for a few days, then will close and push to production if no issues.

misaochan on 15 Apr 2017

I think @VojtechDostal is having some issues with the new Nearby function as mentioned at #506 :

I also tried to load "Nearby" items, but they don't seem to load at all. The window remains blank.

misaochan on 16 Apr 2017

@VojtechDostal https://github.com/VojtechDostal Does pressing the refresh
button on the top-right corner work?

Is the permission to location granted to the app?

Can you share the location where you tried this? It could be
location-specific issues. If you want to keep it private, you can send to
[email protected] or [email protected].

Also, if you can, providing a larger portion of the logs containing tags
like NearbyPlaces, NearbyListFragment, LocationServiceManager will help a
lot. (Again, please be aware that this might contain personal information
regarding locations.)

On Sun, Apr 16, 2017 at 10:34 AM, Josephine Lim notifications@github.com
wrote:

I think @VojtechDostal https://github.com/VojtechDostal is having some
issues with the new Nearby function as mentioned at #506
https://github.com/commons-app/apps-android-commons/issues/506 :

I also tried to load "Nearby" items, but they don't seem to load at all.
The window remains blank.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/commons-app/apps-android-commons/issues/289#issuecomment-294327871,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAApsvVVlJLhiRfN7pdw3TYsZLjI0ySVks5rwXAsgaJpZM4KQtge
.

whym on 16 Apr 2017

Pressing the refresh button does nothing. It doesn't even display any action in logcat. The app used to work before quite nicely, so my theory has been that it has something to do with the beta.

I am trying it in Prague. Is that specific enough? :-)

When I open the app, remove the preexisting content of the logcat and then press "nearby", this is what I get:

04-16 10:05:35.484 170-170/? E/BufferQueueCore: [PopupWindow:209c83b4] setDefaultMaxBufferCount: setting count to 3, previous is 2
04-16 10:05:35.854 751-1153/? E/Watchdog: !@Sync 565 [04-16 10:05:35.866]
04-16 10:05:38.357 19829-19829/? E/ViewRootImpl: sendUserActionEvent() mView == null
04-16 10:05:38.427 19829-19829/? E/MotionRecognitionManager: mSContextService = null
04-16 10:05:38.427 19829-19829/? E/MotionRecognitionManager: motionService = com.samsung.android.motion.IMotionRecognitionService$Stub$Proxy@c2764f1
04-16 10:05:38.467 170-170/? E/BufferQueueCore: [fr.free.nrw.commons/fr.free.nrw.commons.nearby.NearbyActivity] setDefaultMaxBufferCount: setting count to 3, previous is 2
04-16 10:06:02.911 751-764/? E/ActivityManager: failed to get LpnetManagerService instance or Pkg was null
04-16 10:06:05.854 751-1153/? E/Watchdog: !@Sync 566 [04-16 10:06:05.867]
04-16 10:06:35.853 751-1153/? E/Watchdog: !@Sync 567 [04-16 10:06:35.868]

and nothing happens. Does it help?

VojtechDostal on 16 Apr 2017

Still no idea. On my emulator (Android 7.1 equivalent), I get something like this for Latitude=50, Longitude=14.43.

screenshot_1492340157_small

Additional questions: What version of Android is it? Is "Use Wikidata" enabled on Settings? Can you try with another Android device?

whym on 16 Apr 2017

@whym I tried testing this again (emulator, API 25) and got a blank screen on my first try, with the logs below. But the refresh button works for me, it loads normally upon refresh.

04-17 00:37:57.141: D/fr.free.nrw.commons.nearby.NearbyListFragment(2992): NearbyListFragment created
04-17 00:37:57.143: D/fr.free.nrw.commons.nearby.NearbyListFragment(2992): Saved instance state is null, populating ListView
04-17 00:37:57.143: D/fr.free.nrw.commons.nearby.NearbyListFragment(2992): Loading attractions near null

@VojtechDostal How are you getting your logs, are you using Android Device Monitor on Android Studio? If you are, go to the text box in the middle and type tag:fr.free there, and select "debug" from the drop down on the right. Then copy ALL the logs you see and paste here (don't worry about it being long, it shouldn't be excessively long with this method).

I have a screenshot below to show how to do it:

android device monitor

misaochan on 16 Apr 2017

After today's update, I can open settings but the Nearby function still does not work, same behaviour as described above.

I am using Samsung Galaxy J3, Android 5.1.1.

Will try the @misaochan 's method when I have a little more time, possibly tonight or tomorrow morning

VojtechDostal on 16 Apr 2017

I chose "Debug" from the rollup menu and filtered the results for "fr.free" and this is what I got when I opened Nearby:

But nothing loads.

VojtechDostal on 16 Apr 2017

Thanks for providing the log. The problem appears to be that, in the query, the location is formatted like "Point(12,34 12,34)" using commas which should be "Point(12.34 12.34)" using periods. I'm guessing that we need to cancel the localization.

whym on 17 Apr 2017

👍2

@whym do you think I should push another release to beta now? Or is there any other fix in the works?

misaochan on 17 Apr 2017

@misaochan I'm not working on anything at the moment. I'd suggest releasing it and seeing if any other issues arise.

whym on 17 Apr 2017

Rolled out the fix to beta, please test in a few hrs' time.

misaochan on 17 Apr 2017

Woohoo yes it works now :-)

After the last update, list of nearby items loads and it is really the list of nearby Wikidata items. Very precise, with nice descriptions in my language.

screenshot_2017-04-19-08-11-12