Picture of the element

[tdelmas]

General

Affected tag(s) to be modified/added: image

Question asked: Can you provide a picture of item XY?

Checklist

Checklist for quest suggestions (see guidelines):

• 🚧 To be added tag is established and has a useful purpose
• 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
• 🐿️ Easily answerable by any pedestrian from the outside but a survey is necessary
• 💤 Not an overwhelming percentage of quests have the same answer (No spam)
• 🕓 Applies to a reasonable number of map data (Worth the effort)

Ideas for implementation

Proposed UI:

Just a button to open the camera (which should allow the user to then select an already taken picture)

Related: https://en.osm.town/@MapComplete/113209991694821771

[matkoniecz]

See #5329 #2762 #952 and other issues linked there.

Feel free to open an issue if things changed significantly since then. In such case please explain why closing reasons do not apply anymore.

But IIRC they were quite fundamental and about general app design.

[tdelmas]

Thank you for that very informative answer. I will try to argue that things changed enough since, notably with the apparition of Panoramax instances and federation.

#2762 (comment)

Primary problem is that it turns it from OSM editor into OSM editor and Wikimedia Commons upload app.

I would argue that it could include pictures not worthy of Wikimedia (fire hydrants? Toilets?) but that could be uploaded to a panoramax instance (for example), like MapComplete is doing. That instance could be self-hosted, the once of MapComplete if they accept, or someone could host one specifically for these kinds of applications.

#952 (comment)

How you propose to select objects that are both

worth photographing
without existing photo on Wikimedia Commons?

It could help to have up-to-date clear picture of elements for OSM, even if they don't belong to Wikimedia Commons.

Also, servers like https://panoramax.openstreetmap.fr and https://panoramax.mapcomplete.org/ link users to their OSM accounts (OAuth), the same mechanism coulb be used.

Also, the idea is to take a picture of an OSM item, not of a wikipedia/wikidata item and then maybe link it to an OSM item.

Finally, "street level images" are usually not great enough when they don't target a specific item, making this quest useful.

For the problem of choosing which items to suggests, the first implementation could make a (small) list of interesting things, and expand it later.

[matkoniecz]

include pictures not worthy of Wikimedia (fire hydrants? Toilets?)

These are useful at Wikimedia and can be uploaded there (though I understand people not willing to deal with extra account, platform and adding image info)

That instance could be self-hosted

AFAIK @westnordost is not looking for moderation effort and such extra responsibility, current setup deliberately deletes images after related note is closed

And I am definitely not looking for either moderation effort and such extra responsibility and would prefer to not deal with either.

Primary problem is that it turns it from OSM editor into OSM editor and Wikimedia Commons upload app.

Well, turning it from OSM editor into OSM editor and Panoramax upload app is still a problem. I still expect that if someone would be interested in maintaining or using such, it would be likely better as a separate app.

[tdelmas]

These are useful at Wikimedia and can be uploaded

As individual pictures of such items can't be linked to other Wikimedia element, they don't really belong there : https://commons.wikimedia.org/wiki/Commons:Contributing_your_own_work : "Is it likely to be useful to a Wikimedia Foundation project? For example, can you point to a Wikipedia article that would benefit from this file's inclusion?"

But they would be useful to improve the tagging of the element later.

moderation effort

If it was a set-up, managed and moderated by another entity, with an OSM-login, then would it be ok? (like the one from MapComplete or another)

I still expect that if someone would be interested in maintaining or using such, it would be likely better as a separate app.

I would argue that it makes less sense on a separate app, as it IS to add the OSM tag, and that the picture of the OSM element would be there to document it (and help later to improve tagging eventually).

As a separated app, that app would need to fetch OSM elements, find the interesting ones, and use gamification to incite users to contributes. StreetComplete users are already on the street, wanting to help tagging.

For all those reason, I feel like a separate app (or a Wikimedia one) is not better.

[matkoniecz]

As individual pictures of such items can't be linked to other Wikimedia element, they don't really belong there

See https://wiki.openstreetmap.org/wiki/Wikimedia_Commons and https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2016/11#%22realistically_useful_for_an_educational_purpose%22_-_how_broadly%2Fnarrowly_it_is_defined%3F

It is actually wider than "dedicated Wikipedia article can be written about this object"

[mnalis]

TL;DR: I think integrating Panoramax might work. Answers to previous complaints under the line.

I must say I've been playing with MapComplete Panoramax feature for a last few days and it is very well done!

These are useful at Wikimedia and can be uploaded there (though I understand people not willing to deal with extra account, platform and adding image info)

I also contribute to the Wikimedia Commons, and I must say it is enormous difference. Yes, Commons is more useful for quality pictures, but to do it properly (filling all the metadata) is going to take a lot more work - from a minute (best case) to a dozen minutes and sometimes even few hours (when I get drawn into the rabbithole of creating wikidata, with all kinds of links to and fro, creating sub-wikidatas and their commons and links, etc.) .
E.g. lately Commons app lost few dozen of my unuploaded pics, and while I have copies of the pictures, I estimate it will take me several painstakingly hard days to recover from that. (when I gather enough courage to start, I'm still stressed about that)

In MapComplete, sending a picture of that restaurant or shop or menu or whatever to Panoramax is literally 2-second job -- and most of that time being spent on camera focusing. I'm very impressed. There is not even a point in trying to make usability comparison with Commons App from an submitter's point of view; MapComplete+Panoramax wins hands down there.

Of course, MapComplete is still web app (so not great mobile UI), and mostly wants to be online all (or majority) of the time and its UI is theme-based which (just like StreetComplete Overlays, but multiplied) has a lot of disadvantages (i.e. annoying and timewasting constant switching between them unless one is interested exclusively in only one very narrow subject/theme) -- but I digress, the point is that Panoramax feature in itself looks great in MapComplete, and makes me want it in SC.

---

Regarding issues from #1601 (comment):

1. For wikimedia, we want well-made high-resolution pictures where ideally some time was invested to make good photos, from different angles etc. Not just any snapshot one can do with his phone

Not a problem for Panoramax snap of that shop / cafe / restaurant / menu. Even a lower quality picture is still fine.

2. For this to work, the user needs a wikimedia account

Not a problem here, Panoramax uses your existing OSM account via Oauth2

3. The app does currently not support uploading quest answers to anywhere else than the OSM API. To change this will require a larger refactor of the upload process

This probably still stands, although reusing OSM authentication API probably makes it somewhat easier.

4. While it may be possible to find castles with missing pictures via Overpass, this use case is quite limited (to castles). There are more photo-worthy objects in the world that do not have a photo yet. But of course, it would be difficult to find these automatically

(also mentioned in other tickets like #952 (comment) under umbrella "how to find on what to add pics"). I don't think that Quest a right approach anyway, it will either be way too spammy, or too hard to filter and missing too many places.

Instead, "Add picture" submenu entry under existing Places / Things overlay would suffice IMHO to let people add images to objects on demand (and would also solve "need to be online" issue which many other previous suggestions had for searching wikidata etc. for information where pics are missing). It might show previous Panoramax images if they exist, but that is not hard requirement (and would require one to be online to show them). However to acquire and queue images for later upload could be done completely offline (just as taking picture Notes is currently).

And I am definitely not looking for either moderation effort and such extra responsibility and would prefer to not deal with either.

Well, turning it from OSM editor into OSM editor and Panoramax upload app is still a problem.

Both are being tested by MapComplete.org currently, so we can wait a little and see?

I would argue that it makes less sense on a separate app, as it IS to add the OSM tag, and that the picture of the OSM element would be there to document it (and help later to improve tagging eventually).

Agreed, that it the whole point. There is already standalone Panoramax app (in beta) at https://github.com/nobelization/panoramax-mobile-app which can take single shots too, so main point of SC support would be easy linking of OSM to Panoramax picture.

---

Another possibility would be to have SC invoke Panoramax app to take single picture via some intent or whatever (e.g. how it currently invokes StreetMeasure) and use that on OSM elements the mapper has chosen. Of course it would need code support on both sides, but would reduce code duplication much and solve account issues, who is responsible for uploaded pics etc.

[matkoniecz]

Is there any existing Panoramax instance that would potentially accept SC pictures? And do maintenance/moderation as needed?

[matkoniecz]

Also: we should skip cases where images are already linked through wikidata or wikipedia

Which can be done by skipping anything that has wikidata or wikipedia tags or by elaborate checking of Wikidata, Wikipedia, Wikimedia Commons and calling their APIs.

(there is no point in asking people to take pictures of something that has it already)

[cquest]

Is there any existing Panoramax instance that would potentially accept SC pictures? And do maintenance/moderation as needed?

OSM-FR Panoramax instance could be a good start.

To limit moderation, an OSM login would be the best (we use OSM.org OAuth on this instance).

We have a reporting mecanism in place which will hide pictures when reported. We also take care of bluring faces and license plates automatically.

For the long term, letting the user chose on which Panoramax instance he/she want to share his pictures would be much better asseveral OSM local chapter are considering setup up their own instance.

The meta-catalog then allows to search/view pictures shared on any instance that is federated.

Example: https://api.panoramax.xyz/#focus=pic&map=17/46.021391/4.764538&pic=38d2276d-3d78-487a-834a-35745c6d413f&speed=250&xyz=13.00/0.00/0

[tdelmas]

@mnalis we got an answer about

Another possibility would be to have SC invoke Panoramax app to take single picture via some intent or whatever

Here nobelization/panoramax-mobile-app#105 (comment) :

Hi, that would be, indeed, wonderful.
We will focus on releasing a V1 of the Panoramax app working correctly on its own and we might prioritize this later.
Of course, if there is a proper request (directly from Street Complete or any other significative app) to actually implement it, that would be a sign for us to move quicker.

[pietervdvn]

Hi, MapComplete dev here.

I totally cheated about authentication. As we were caught pants-down with no working image upload (IMGUR suddenly blocked us), I simply created one single account on our panoramax.mapcomplete.org and added the username as "artist". It'll then be returned in the API as author: ["MapComplete", "<actual username>"], so I can display the proper username. Panoramax instances will display "MapComplete, " however.

The reason for this is that I either had to subject the user to logging into panoramax by logging in again or do some weird and very hard tricks with OAuth.

If this flow is proven to be possible, simplified (and potentially implemented in panoramax-js), I might add the possibility for contributors to select their own panoramax-instance. There will always be some default set, as 99% of the users would be scared of the choice anyway.