[digikam] [Bug 455775] New: Improve workflow by recording accuracy in GPSHPositioningError
https://bugs.kde.org/show_bug.cgi?id=455775 Bug ID: 455775 Summary: Improve workflow by recording accuracy in GPSHPositioningError Product: digikam Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: Plugin-Generic-GeolocationEdit Assignee: digikam-bugs-n...@kde.org Reporter: sy...@debian.org Target Milestone: --- Please add GPSHPositioningError as an EXIF field that can be batch edited in Digikam via Edit Geolocation to improve photo workflows that upload to web services making use of the field to record accuracy. I understand that Apple iPhone cameras set this field. Unfortunately, I have not found a GPS tracker for Android that sets it, otherwise the tracker itself could handle this job. I also understand that GPS DOP, while it is position related, is not something that should be directly used to set accuracy. See discussion here: https://forum.inaturalist.org/t/gps-accuracy-not-captured-when-uploading-photos-taken-with-a-camera-with-a-built-in-gps/18861 Details about my use case: In order to prepare my observation photos to upload via iNaturalist web uploader, I currently use Edit Geolocation to correlate a gpx track made on Android with my non-GPS-capable camera photo timestamps. However, the accuracy information must be manually added per photo in the iNaturalist web uploader because the GPSHPositioningError is not recorded. This is not efficient. While there are other means to add that info (e.g. running exiftool at the command line to set that field to a reasonable default value - see https://forum.inaturalist.org/t/geotagging-photos/66/5 ) it is an inconvenient extra step I would like to avoid by having Digikam handle it in the geolocation editing phase of my photo workflow. Proposed placement in the UI: For example, where another position-related field that can be changed in Edit Geolocation is "DOP" in the Details pane (which iNaturalist web uploader does not use - see the first link above), perhaps "H pos error" could be placed beneath that, and then a user could enter a reasonable default value like 10 metres. Thus, with a few more clicks and keystrokes after performing geolocation, a batch of photos will be ready for upload, and the accuracy default will be set on every photo, saving that extra manual step. Alternatively, in the GPS Correlator pane itself under "Offset of pictures (hh:mm:ss):", add "Accuracy (in metres):" (or however you think this should be described) that can optionally be used to set the GPSHPositioningError directly, i.e. without a second pass in the Details pane. This would be a more efficient alternative, though I understand it's probably a tough sell to put it here for what might seem to you like a niche use case. Note: while there is an iNaturalist plugin, that is not currently a part of my workflow for various reasons. Besides, I do not consider this request limited in scope to uploading to iNaturalist, as other platforms may also make use of GPSHPositioningError to indicate accuracy. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 394544] New tool to export to inaturalist
https://bugs.kde.org/show_bug.cgi?id=394544 --- Comment #18 from Ben Armstrong --- (In reply to caulier.gilles from comment #17) > I don't write this plugin. joergml...@gmail.com do it, i just review the > code. > See comment #13 for details. > > Again, Thanks to Joerg Lohse for this great work... My mistake. Thanks, Joerg. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 394544] New tool to export to inaturalist
https://bugs.kde.org/show_bug.cgi?id=394544 --- Comment #16 from Ben Armstrong --- Nice work, Gilles! I tried the 7.3.0 snapshot appimage built yesterday and did an upload using the extension. It worked with only two minor issues: - I tried typing my identification and clicked the matching one and it was not selected. It worked when I tried again but pressed enter instead of just clicking the matching identification. - I didn't see any way to adjust the position / enter accuracy, but was able to fix this on the web afterwards. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 394544] Export to inaturalist
https://bugs.kde.org/show_bug.cgi?id=394544 --- Comment #3 from Ben Armstrong --- Gilles, I appreciate that when building & supporting a plugin ecosystem, having the freedom of language choice through bindings for those languages has a cost, so by limiting it to C++ and Qt5, it is less of a burden to support, but unfortunately, that diminishes my interest in writing any code for this wishlist, as any such code would be novice-level at best, and both user communities (iNaturalist, Digikam) deserve better than that. Still, I'd be happy to play some supporting role here, so that includes clearly articulating what would be useful in such an extension, testing & debugging any code written (if it gets that far), or any other way I can help. If I cannot realize a substantially Digikam-centred workflow, perhaps I could take a different tack, prototyping something standalone that works with my Digikam collection. And in any case, here are some issues I'm currently facing with Digikam's support for GPS tags that a plugin like this could help with: - It is important to submit accuracy with each observation created on iNaturalist. While there are ways to collect that data automatically, I have yet to determine how to merge it into my photo collection and submit in a form that iNat accepts. - Unfortunately, while OsmAnd (which I use for GPS tracking) stores HDOP per trackpoint, I know of no way horizontal positioning error can be computed from that figure & then written out to the corresponding EXIF tag (GPSHPositioningError). And that's the only mechanism they have to input accuracy from photos submitted on the web. - Indeed, even after using Digikam's GPS correlation to merge HDOP from my tracks, it doesn't loook like Digikam writes that out, not even to GPSDOP, in the EXIF (I'd have to use exiftool for that). - And even if Digikam did that, iNat ignores GPSDOP and only accepts GPSHPositioningError. - Therefore, while I can use Digikam's GPS correlator to import those HDOP values into Digikam per photo, I am currently without any way (via Digikam or otherwise) to turn that into usable data for my observation submissions. If the plugin would ease this particular pain point, it would greatly improve the workflow: - snap shots in the field while taking GPS track with HDOP - import into Digikam for processing - GPS edit, using correlator to merge HDOP values - submit to iNat with accuracy info included in a form iNat will accept Thanks for considering this request. Ben -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 394544] Export to inaturalist
https://bugs.kde.org/show_bug.cgi?id=394544 Ben Armstrong changed: What|Removed |Added CC||sy...@debian.org --- Comment #1 from Ben Armstrong --- See https://www.inaturalist.org/pages/developers and https://www.inaturalist.org/pages/api+reference which provides a place for developers to start on this. I'm trying to use Digikam to establish a photo processing workflow entirely based on open source software. On the input/import end, I'm using OsmAnd on Android to collect GPS tracks, OpenCamera on Android to take photos. Then I use Digikam to GPS correlate tracks & photos from my discrete camera (and also to supplement Android photos with DOP values from the OsmAnd tracks, which the Android platform doesn't yet support recording in EXIF natively). Currently, I do all other editing & photo processing within Digikam. For exporting, I typically publish (currently via batch uploads of files through the web interfaces of each platform) to five different target platforms: Strava (a group for stewards of our local wilderness trail), Facebook (valuable to support discussions with a broader community not on other platforms), Flickr (mostly as fairly large, "free" cloud storage), Wordpress (self-hosted), and iNaturalist. Anything I can do to automate / optimize / cut out redundancy in my workflow would greatly improve life for me. A significant barrier in this workflow to uploading efficiently to the iNaturalist platform is submissions through their web interface of large photo sets. In Chromium, it is necessary to partition sets of greater than about 30 photos at a time into subsets, otherwise my Atom-based workstation with 8G RAM runs out of memory to handle the page. Integration with Digikam done properly would likely help with this. The main feature request & other useful features all sound like things that would help me too. I'd love to see something started, and then those additional requests filed as separate wishlists once work is underway. As a professional software developer, primarily in Ruby these days, but with some proficiency in other languages, and also as a Debian developer of some years, helping develop an iNaturalist export extension for digikam is certainly something I'd be interested in exploring. I must caution, though, that I have no KDE development experience. I don't think that's a huge barrier to me making some sort of contribution, but it probably rules me out as being a driver for this effort. -- You are receiving this mail because: You are watching all bug changes.
