For instance here is a request that says "ロゴ変更後の外観" ("Please take a picture of the outside of the building, featuring the new logo)"

{{画像提供依頼|ロゴ変更後の外観|date=2016年2月}}

English and French don't seem to have similar fields though, so it is not urgent, but for Japanese it would be helpful :-)

It would be nice if the points from Wikidata did not duplicate points from the same topic on Wikipedia, as is happening (AFAICT) for all (?) train/metro stations in Milan:

How often is https://tools.wmflabs.org/wiki-needs-pictures/data/data.csv updated?

Because 7 MB is costly for mobile users, I am implementing a cache mechanism at commons-app/ShootMe#6 and I would like to know how often I should invalidate the cache.

Thanks a lot for maintaining this CSV file! :-)

The problem

The CSV contains this line:

Q9323673,53.9778,21.866969,undefined,999,Q9323673

https://www.wikidata.org/wiki/Q9323673 has a Polish label "Ruda Staświny".
So, the CSV should contain this line:

Ruda Staświny,53.9778,21.866969,undefined,999,Q9323673

Even though I don't understand Polish, anything is better than a QID. Especially for users who have never heard about Wikidata, even Chinese symbols are better than a seemingly random number.

The problem is probably that wikidata.js also reads English labels: bd:serviceParam wikibase:language 'en' .

The solution

Use this trick to get a Wikidata item's label in English if available and in any other language if no English label is available:
https://query.wikidata.org/#SELECT%0A%20%20%3Fitem%0A%20%20%28SAMPLE%28COALESCE%28%3Fen_label%2C%20%3Fitem_label%29%29%20as%20%3Flabel%29%0A%20%20%28SAMPLE%28%3Flocation%29%20as%20%3Flocation%29%0AWHERE%20%7B%0A%20%20%3Fitem%20wdt%3AP31%20wd%3AQ811979%20.%20%23%20Modified%20because%20I%20was%20getting%20a%20timeout%20in%20the%20original%20request%2C%20please%20restore%20to%20original%0A%20%20%3Fitem%20wdt%3AP625%20%3Flocation%20.%0A%20%20MINUS%20%7B%3Fitem%20wdt%3AP18%20%3Fimage%7D%0A%20%20MINUS%20%7B%3Fitem%20wdt%3AP373%20%3FcommonsCat%7D%0A%20%20OPTIONAL%20%7B%3Fitem%20rdfs%3Alabel%20%3Fen_label%20.%20FILTER%28LANG%28%3Fen_label%29%20%3D%20%22en%22%29%7D%0A%20%20OPTIONAL%20%7B%3Fitem%20rdfs%3Alabel%20%3Fitem_label%7D%0A%7D%0AGROUP%20BY%20%3Fitem

It would make it much easier to run the backend.
https://docs.npmjs.com/getting-started/using-a-package.json
Thanks!

The request category can be useful to know what is wanted exactly.
For instance, for items in category https://ja.wikipedia.org/wiki/Category:7月の画像提供依頼 a picture taken in July is requested.

Embedding this information with each item can help a lot, and does not make the app slow if #10 is implemented too.

When I run the script, I get this data:

釜トンネル,36.21214234,137.61255431,landmark,061
呉港,34.24063889,132.55638889,undefined,061
賤母大橋,35.58555556,137.56277778,landmark,061
白瀬峠,35.17644444,136.43540556,pass,061
近文大橋,43.78888889,142.31305556,landmark,061
千葉県道283号若宮西船市川線,35.71138889,139.92972222,landmark,061
千歳橋 (千歳市),42.82022222,141.64638889,landmark,061
都営バス江東営業所,35.69655556,139.81802778,undefined,061
都営バス港南支所,35.63044444,139.75133333,undefined,061
南国交通空港自動車営業所,31.80288889,130.7125,undefined,061
函館湾岸大橋,41.77666667,140.72555556,landmark,061
鉢伏峠,34.657567,135.883436,landmark,061
宮古空港,24.78277778,125.295,airport,061
樅ノ木峠,34.15359722,133.82017222,pass,061
夢前バスストップ,34.96321111,134.69240833,landmark,061
与儀交差点,26.20797222,127.69141667,undefined,061
[...]

PROBLEM: These points are not shown at http://tools.wmflabs.org/wiki-needs-pictures/ . In fact, only 20 points appear for the whole of Japan, zero in Tokyo despite 35.69655556,139.81802778 above being in central Tokyo.

Is it just a problem with the server not being updated?

https://tools.wmflabs.org/wiki-needs-pictures/data/countries/GB currently includes 6881 rows. Among them https://www.wikidata.org/wiki/Q26300425 is missing. The upper limit of classified monuments in UK is around 330k, IIRC.

I see the SPARQL query currently looks for subclasses of Q811979 and Q15700834 is one, so we should be ok. If I try the query manually, however, I get a timeout. Perhaps the results set is just too big in some cases and the query needs to be made smaller/more efficient?

It would be cool if it was possible to add Commons links directly from the map interface instead of having to go to the Wikidata page. There could be a button for that in the balloon that shows up when you click on a marker.

After I take an item's picture to Commons and upload it, I would love the ability to mark it as "done", so that I don't see it anymore on the map and can continue walking around the area with a clear view of what is left to take.

When travelling I usually keep moving away to new places, so waiting a week (or even 30 minutes) is not doable.

Probably quite hard to implement, but if it could be done it would be very useful.

The demo does not seem to work over HTTPS: https://tools.wmflabs.org/wiki-needs-pictures/

We would like to use this webapp, but for privacy of our journalists/witnesses users in all sorts of countries, all traffic should be over HTTPS.

Also, is it possible to avoid non-Wikimedia domains? Right now I see requests to mqcdn.com

Thanks!

In OsmAnd/Maps.me/Google Earth/etc

GPX could be generated by reusing the GPX output generator at https://github.com/baturin/wikivoyage-listings/tree/master/src/main/java/org/wikivoyage/listings/output

Each Wikivoyage article has a number of points of interest ("POI"): museum, restaurants, etc
75% of the POIs are not notable enough to have a Wikipedia article, so they are not on Wikidata either.
Each POI on the English Wikivoyage can have an image, example (see the image= field):

*{{see
| name=Roppongi Crossing | url= | email=
| address= | lat=35.66330 | long=139.73230 | directions=
| phone= | tollfree= | fax= | image=Roppongi_night.jpg
| hours= | price=
| content=The heart of Roppongi is this big intersection of '''Roppongi-dōri''' (六本木通り), under the elevated highway, and '''Gaien-higashi-dōri''' (外苑東通り).}}

Unfortunately, many of the POIs don't have a picture yet.
Solution: wiki-needs-pictures could find these POIs (available as CSV/SQL here) and show them on the map. That would be a great addition, and something that WikiShootMe does not have (and may never have).

Other tools like WikiShootMe consider that once a Wikidata item has a picture, there is nothing left to do.
But the Wikidata stance is: Any image even low-resolution/blurry/low-contrast is better than nothing.
There is potential for picture quality improvement.
So, here is my proposition:

In areas where there are no needed pictures, go through the Wikidata items and detect which ones only have a low-quality picture. Add these to the wiki-needs-pictures database.

Picture quality could be determined by an algorithm.

Any special reason to use MapQuest? Nowadays we can use maps.wikimedia.org and avoid sending private data outside the WMF cluster. Seems just a matter of rewriting one URL in the config, AFAICS: https://www.mediawiki.org/wiki/Maps#Getting_started

The CSV file is currently around 7 MB, it is huge for mobile users. Mobile users are probably the people who want to use wiki-needs-pictures the most.

The quantity of data will continue to grow, and could even reach several hundred megabytes if Wikidata requested images are included.

So, rather than loading 7 MB upfront, how about splitting the data in regions, and only loading the regions that are around me? That will probably require abandoning the clustering gadget, but I believe this is needed.

In April I added an image to https://www.wikidata.org/wiki/Q18457443

Problem: it is still showing up in the CSV.

If you push the latest source code I will try to track down the problem. Thanks!

There are no images for https://www.wikidata.org/wiki/Q1808259
The building was demolished in 1999, and the college does not exist anymore.
Such items could benefit from being marked as "does not exist anymore".

That would alert photographers that the thing is not there anymore. They might find some remains, though.

(Low priority enhancement)

In the current CSV file, there is a place called "Aoyama theater" and another place called "青山劇場" (which means "Aoyama theater" in Japanese). Their latitude/longitude are a little bit different.

Both are linked to the same wikidata item https://www.wikidata.org/wiki/Q11661222 so it would be possible to detect that they are duplicate, and only use one.

Benefits:

• smaller CSV file
• less confusing for users

It would be cool if the webapp could center on my current position.
Webapps can get that after asking for a permission via the browser.

https://www.wikidata.org/wiki/Q2264241 shows up as undefined but is p31 = railway station on Wikidata.

See duplicate issue at: commons-app/apps-android-commons#246