streetcomplete
Picture of the element
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):
- [x] 🚧 To be added tag is established and has a useful purpose
- [x] 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
- [x] 🐿️ Easily answerable by any pedestrian from the outside but a survey is necessary
- [x] 💤 Not an overwhelming percentage of quests have the same answer (No spam)
- [x] 🕓 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
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.
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.
https://github.com/streetcomplete/StreetComplete/issues/2762#issuecomment-821959163
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.
https://github.com/streetcomplete/StreetComplete/issues/952#issuecomment-370842313
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.
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.
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.
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"
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 https://github.com/streetcomplete/StreetComplete/issues/1601#issuecomment-544299633:
- 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.
- For this to work, the user needs a wikimedia account
Not a problem here, Panoramax uses your existing OSM account via Oauth2
- 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.
- 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 https://github.com/streetcomplete/StreetComplete/issues/952#issuecomment-371606551 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.
Is there any existing Panoramax instance that would potentially accept SC pictures? And do maintenance/moderation as needed?
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)
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
@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 https://github.com/nobelization/panoramax-mobile-app/issues/105#issuecomment-2432666311 :
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.
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,
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.
So, in order to link photos with OSM elements generally, this definitely would need to be an overlay in which you can upload pictures for elements, because I don't think this would work as a quest.
Even for an overlay, it's not quite clear for which elements it should be possible to add pictures. Only places and things? More? Regardless, that overlay would get quite busy. Displaying which elements already have a picture linked would probably be possible, but to display these pictures (right on the map) quite impossible. Even displaying them when opening the form is a problem for an app that should otherwise work fully offline.
It would also be quite an oddball amongst the overlays, as you are not directly contributing missing data, rather, metadata or something that might be useful later. For the user, unlike in other overlays, it would be quite unclear which POIs should have a picture and which shouldn't. Also, who is only going to add pictures of elements? (I mean, that's the purpose of overlays in StreetComplete, to focus on one thing.)
So for this reason, to be honest, I think this whole idea of adding pictures to an element is a feature that would be more fitting for a general-purpose (POI) editor like iD, EveryDoor or Vespucci. E.g. in the view where all the possible (supported) feature properties are displayed, have an additional image field that has a [📷] button with which one can easily add a foto. That foto is in parallel uploaded to a persistent image hosting service and the URL to it is added in the image tag of the element.
(For now,) I will close this as a will not fix. I think this is a bit out of scope for StreetComplete. And I am happy that the EveryDoor developer is thinking about implementing such a thing.
But which service to use for that? Really Panoramax?
Panoramax
Pros:
- Reporting mechanism: Hides pictures when reported
- automatically license plates and faces are blurred (might backfire, though)
Cons:
- that service is not really made for taking pictures of things somewhere, it's seems a bit of a mis-use or unintended usage of Panoramax to me to use it essentially as a persistent photo-hosting service.
- user needs to authorize with OSM twice (first for the editor app, second for picture upload). That this is not ideal is reflected by how Pieter did this ugly workaround just to avoid extra authentication
I don't know, maybe a Panoramax instance which has all those images from the OSM elements would indeed open up new use cases and in general be a convenient way to access these. But then, that Panoramax instance should show all the pictures linked from the image tag in OSM elements, no?
Alternative
To avoid the cons of Panoramax, one might also just host a simple image hosting service akin to https://github.com/streetcomplete/sc-photo-service but with a different cleanup-mechanism: The cleanup doesn't look at whether the note in which the pictures were mentioned is still open, but looks if the image is still linked from the associated element in OSM.
Pros:
- no need to authorize twice. Same "photo activation" mechanism is used as for the StreetComplete photo notes
- very lightweight (just a bunch of PHP scripts, a MariaDB database and lots of webspace)
- straightforward moderation/reporting mechanism: When the link is severed, the image will be deleted (by a cronjob, i.e. after some time)
Cons:
- license plates and faces are not blurred automatically. (It would need to be implemented)
sc-photo-upload could be forked, or even extended, to be able to do both. The limit in picture size for image note uploads, by the way, is something that is enforced client-side by StreetComplete
Even for an overlay, it's not quite clear for which elements it should be possible to add pictures.
Same reason there is no (widely available) theme in MapComplete for "all objects with an image", because it is such a random collection of items.
Panoramax
Yeah, our use case of Panoramax works and has a few advantages, mostly that images taken with MapComplete now also show up in e.g. iD. There has been some friction though because it isn't 100% the right tool (as you mention), but it is the best that is available - so I'm happy with it ;) .
About the 'logging in twice': maybe we should work something out together with the Panoramax-devs? However, even something gets worked out; it'll take a long time before a fix is implemented and deployed.
In conclusion: I completely understand your take on not implementing this on SC!
Even for an overlay, it's not quite clear for which elements it should be possible to add pictures. Only places and things?
My idea was to have that new "Take picture" as an optional item (e.g. near "Leave note") in menu on existing "Places" and "Things" overlays (e.g. only shown if chosen element lacks all of wikimedia_commons / panoramax / mapillary / image tags).
I think it would work nicely if one wanted to take a picture that is missing. But perhaps that is more in SCEE style... :man_shrugging:
Completely new "Pictures" overlay might also work, but seems like worse solution to me (unless it pre-downloaded all the pictures, which seems like overkill). It might work if it only displays one icon for places/things not having a photo (preferably smaller, like a dot), and other icon for those having a photo, but that would IMHO be more visually spammy than the idea of just having "Take picture" in the menu in existing Things/Places overlays as outlined above. Special overlay for pictures would make the functionality more visible, on the other hand (if that is something we want).
Even displaying them when opening the form is a problem for an app that should otherwise work fully offline.
Yeah, that is understandable. The same problem is there for Notes currently (even for notes with pictures taken with SC, one needs to be online to be able to display actual pictures, even if notes themselves were pre-downloaded alongside with the quests).
- automatically license plates and faces are blurred (might backfire, though)
That depends on the instance, though. e.g. IIUC, panoramax.mapcomplete.org instance does not do the blurring?
- that service is not really made for taking pictures of things somewhere, it's seems a bit of a mis-use or unintended usage of Panoramax to me to use it essentially as a persistent photo-hosting service.
I'm not sure why you think so?
- Panoramax was primarily intended to have pictures of stuff visible from the street (like google street view, mapillary etc.) and that in my experience definitely include store fronts, memorials etc.
- the whole point of panoramax=* key is exactly to link such "street view" pictures to specific OSM element represented by that picture.
- AFAICT Panoramax.fr instance guys were fine with the idea (see previous comments)
- there are some 40k+ such
panoramax=*keys already (probably mostly from MapComplete, whose "Themes" are somewhat similar to StreetComplete overlays)
- user needs to authorize with OSM twice (first for the editor app, second for picture upload). That this is not ideal
Sure, not ideal. The issue can be reduced by only asking for panoramax login on first try when user tries to upload pictures (which most SC users won't; as most don't even use overlays). Or, perhaps deeper looking into Oauth2 might reveal some way to use single login :man_shrugging:
Another mentioned alternative might be (instead of SC doing all the work) calling external panoramax app via intent, like we do for StreetMeasure (IIRC Panoramax app devs at the time also indicated that be open to implementing functionality be called by intent from StreetComplete if that was an supported idea on SC side). That would take care of both thinking about the login and about choosing the instance (the user would select those in their panoramax app anyway after installing it).
To avoid the cons of Panoramax, one might also just host a simple image hosting service akin to [....]
<snip>
Well, that alternative looks to me like "let's reinvent Panoramax, but without login (and federated web-frontend)". Yeah, login might be annoying if there is really no way (to be determined) to avoid having user to log in twice (user could choose to remember the login data in webview, though, I think?), but it also useful (and helps with moderation should it be needed). As is federated web-frontend (sure, I might re-invent that wheel too, but why?)
There has been some friction though because it isn't 100% the right tool
That is MapComplete's unique selling point, though (and nicely done, I must say!) I wish mobile browser experience was more usable to be able to run apps like MapComplete all the time; but unfortunately it is just way too painful to use. But it seems to me StreetComplete is mostly in the same category of "good enough tool" for the job.
Same reason there is no (widely available) theme in MapComplete for "all objects with an image", because it is such a random collection of items.
One can still make their own theme for that in MapComplete, right? I use it mostly to add pictures of memorials, artwork, water sources and occasional storefront which is not easy to find. But having to switch between several MapComplete themes is quite painful (the same issue I have with SC Overlays; but multiplied in pain because such switching is very slow in MapComplete, not to mention it seems to eat my mobile plan). Which is I would prefer having it in SC(EE) things/places overlay as an simple option to add picture.
@pietervdvn Is it possible to call MapComplete programmatically via URL with some OSM object id, and have element open automatically so I could add picture to it? That probably might work too (instead of calling intent for panoramax app; and no app needs to be installed locally on the device)
note: see comment below, I was wrong
I'm not sure why you think so?
AFAIK it was intended for mass-captured street view imagery (replacement for Google/Bing street level view), not as Wikimedia Commons reimplementation
AFAIK it was intended for mass-captured street view imagery (replacement for Google/Bing street level view), not as Wikimedia Commons reimplementation
Not really. A majority of pictures are wide views, but there is no reason to restrict Panoramax to this.
We're working on tags that could help describe the kind of picture content, or the picture content itself. This will allow to filter pictures in case you want only close-ups or wide views.
The issue can be reduced by only asking for panoramax login on first try when user tries to upload pictures
That would require either having two photo handling systems at once or putting barrier to having photos in notes
notes with photos are massively useful so I would worry about barriers there
That would require either having two photo handling systems at once or
Yes. I did not intend to suggest changing current Notes feature -- it should continue to work as before. I.e. adding photos to Panoramax would be completely separate feature.
notes with photos are massively useful so I would worry about barriers there
I agree. While I understand that having single system for handling both Notes and Panoramax pictures (i.e. retiring sc-photo-service and replacing it too with Panoramax) might be desirable; unless it is possible to achieve single sign-on via OAuth2 for both services (something that should be researched if there was a chance of implementing the Panoramax in SC), they should better remain separate.
That depends on the instance, though. e.g. IIUC, panoramax.mapcomplete.org instance does not do the blurring?
Yes, it does do blurring. The GPU-power for this is currently kindly provided by the panoramax.fr people.
One can still make their own theme for that in MapComplete, right? I use it mostly to add pictures of memorials, artwork, water sources and occasional storefront which is not easy to find. But having to switch between several MapComplete themes is quite painful (the same issue I have with SC Overlays; but multiplied in pain because such switching is very slow in MapComplete, not to mention it seems to eat my mobile plan). Which is I would prefer having it in SC(EE) things/places overlay as an simple option to add picture.
Have a look at https://mapcomplete.org/studio where you can select a bunch of layers to form your own theme
@pietervdvn Is it possible to call MapComplete programmatically via URL with some OSM object id, and have element open automatically so I could add picture to it? That probably might work too (instead of calling intent for panoramax app; and no app needs to be installed locally on the device)
Yes, open a relevant theme and add #<object-id> to the URL.
(Note: it is a bit rude to discuss mapcomplete in the StreetComplete issue tracker. For follow up questions, please ask this in the MapComplete chat)
As a user, I would love to be able to share pictures on Panoramax through SC.
I like the fact that the picture will not be lost after a note has been resolved (and that I don't have to create a note to make a picture available to myself and other contributors)
It would allow me to just walk around using SC to solve quests, and not switch apps to share pictures widely with Panoramax (this will likely boost my usage of SC)
Some thoughts on this I want to leave here for when this comes up the next time:
[...] this definitely would need to be an overlay in which you can upload pictures for elements, because I don't think this would work as a quest.
Even for an overlay, it's not quite clear for which elements it should be possible to add pictures. Only places and things?
Does it have to be an overlay? For some POIs like Restaurants and Art a Quest seems like the obvious choice for me. To avoid spammyness I wouldn't default-activate this for more than one or two types of POIs. Some other places and things which make sense, could be added as not-default-activated Quests. This introduces the user to this kind of quest but dosen't overwhelm them. If they think hey I want to add Pictures to xyz too they can activate those quests in the menu.
Making your own Quest-Preset seems to be better suited than an overlay. At least in my mind. Only one Overlay being active at a time makes it a "valuable" resource. It is used to display spacial objects like buildings and ways or to add Points. Pictures feel more like metadata to me (comparable to Charge Point Operator). Displaying this on as a mapstyle/overlay doesn't provide any value.
Instead, "Add picture" submenu entry under existing Places / Things overlay would suffice IMHO to let people add images to objects on demand
Making it possible to add Pictures to even more Objects and providing an Option via the Äh ... menu seem more like a SCEE thing to me. (seems comparable to the edit tags option)
Question asked: Can you provide a picture of item XY?
Checklist
@tdelmas I just had the same idea. Too bad it's not planned.
