Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Derive location from geodata of the photo metadata #544

Open
JuliaFreitagBGSt opened this issue Jan 20, 2025 · 3 comments
Open
Assignees
Labels
BTW: non-critical Less important issues (for after BTW) Lead:Pollion For this user story / issue, Pollion has the lead. question The technical and/or design implementation requires further specification
Milestone

Comments

@JuliaFreitagBGSt
Copy link

Is it possible to derive the location from geodata of the photo metadata?

A user asked if its possible (especially for posters locations) if the geodata of his photo metadata could be used to determine the location in the app when uploading? And if so, is an extended access rights to users' devices required?

@JuliaFreitagBGSt JuliaFreitagBGSt added BTW: non-critical Less important issues (for after BTW) Lead:Pollion For this user story / issue, Pollion has the lead. question The technical and/or design implementation requires further specification labels Jan 20, 2025
@JuliaFreitagBGSt JuliaFreitagBGSt added this to the Release 1 milestone Jan 20, 2025
@Stift
Copy link
Contributor

Stift commented Jan 20, 2025

I would avoid this as the location of the user at the point the photo was taken can be any distance from the actual location of the poster. The workflow is that we set the marker at the designated location and then take a photo or take a photo from the gallery and add this to the location. Using the geo-location that is in the EXIF data would introduce a new workflow which we have to think of. What is the allowed distance between the markers location and the photo? What about situations where the geo-location of the device is not that accurate and we may have a tolerance of 50-100m or more? We don't have a mechanism to re-adjust the marker as well.
To sum it up: I would discourage this feature request atm and maybe think of such feature for bulk-imports (e.g. via cockpit?) or when we re-think the whole process, The process currently is very simple and as we try to reach a diverse audience I would keep it as such.

@Stift
Copy link
Contributor

Stift commented Jan 20, 2025

As always: we may discuss this directly to assess the pro/cons.

@Stift Stift self-assigned this Jan 20, 2025
@JuliaFreitagBGSt
Copy link
Author

I would avoid this as the location of the user at the point the photo was taken can be any distance from the actual location of the poster. The workflow is that we set the marker at the designated location and then take a photo or take a photo from the gallery and add this to the location. Using the geo-location that is in the EXIF data would introduce a new workflow which we have to think of. What is the allowed distance between the markers location and the photo? What about situations where the geo-location of the device is not that accurate and we may have a tolerance of 50-100m or more? We don't have a mechanism to re-adjust the marker as well. To sum it up: I would discourage this feature request atm and maybe think of such feature for bulk-imports (e.g. via cockpit?) or when we re-think the whole process, The process currently is very simple and as we try to reach a diverse audience I would keep it as such.

Perfect! Thanks for the extensive explanation. Lets discuss this later. I put this Issue in Backlog :)

@JuliaFreitagBGSt JuliaFreitagBGSt modified the milestones: Release 1, Release 2 Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BTW: non-critical Less important issues (for after BTW) Lead:Pollion For this user story / issue, Pollion has the lead. question The technical and/or design implementation requires further specification
Projects
None yet
Development

No branches or pull requests

2 participants