| Summary: | REQ: option to search map | ||
|---|---|---|---|
| Product: | [Applications] kgeotag | Reporter: | jason |
| Component: | General | Assignee: | Tobias Leupold <tl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | tl |
| Priority: | NOR | ||
| Version First Reported In: | 1.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | Debian stable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
jason
2026-01-02 03:27:48 UTC
Hi, thanks for your feature request! Marble itself offers searching for places. I'll have to investigate how this is implemented, this either has to use some local database or some online service. I'll see what I can do and if this could be easily added to KGeoTag. This was easier than I thought ;-) Would you mind to test the new "search" branch and see if it's what you wanted? (In reply to Tobias Leupold from comment #2) > This was easier than I thought ;-) Would you mind to test the new "search" > branch and see if it's what you wanted? Nice. Built via podman using debian:stable and working good! The search result seems to return a more "generic" result though? (Coords look fine). What I mean is, if I search for a town (say, "Morenhoven, Germany") the search pane lists a more general result? Same for street numbered address searches. I have two other suggestions, do you want them in separate bugs? 1. The ability to open current coordinates in a (web URL) map? eg: https://maps.google.com.au/?q=<lat>,<long> 2. Alternate OSM views, like satellite Forgot to add, another thing: flexibility around the sidecar naming. I think it should be able to load either format: IMG_BLAH.CR2.xmp IMG_BLAH.xmp (ie. without the original extension.) Different software seems to be all over the place with this standard. I can't tweak the search results, I just use what Marble outputs. It's the very same you get when you search for something using Marble. One could get other results by using other data sources. Maybe, those can also be installed as a Marble plugin. E.g. when you query OpenStreetMap's Nominatim for "Morenhoven, Germany", you would get a result with "Morenhoven, Swisttal, Rhein-Sieg-Kreis, Nordrhein-Westfalen, Deutschland" as the description. However, using Marble's search functions was easy to add (and it's better than nothing, isn't it?!), whereas using e.g. Nominatim would be more work to implement (well, it would be essentially the same as the altitude lookup). Maybe something for later? Concerning your other suggestions: 1. You can already copy the current map center coordinates formatted properly for e.g. use in Google Maps. Just open the context menu on the map and choose "Current map center" and then "Copy as 'latitude, longitiude'". You'll get the string you can append e.g. to your preferred Google Maps URL. 2. The OSM view is the only one suitable for geotagging. All others are way too coarse to find or check a location, we need a few meters in resolution. So I don't think it would be meaningful to add an option to switch to a map view that can't actually be used for the only thing KGeoTag was written for. For both suggestions, I think neither being able to open coordinates in an external program/website etc. nor switiching to e.g. Marbles's sattelite view will help when geotagging photos, will it? Generally, it's better to use different bug reports or feature requests for different tasks. The mailing list or the Matrix channel would be a good way for general discussion. However, concerning the sidecar files: KGeoTag does not mess with those at all, this is all done by KExiv2. So if you think that sidecar files with other names should be read as well, you should file a bug there. (In reply to Tobias Leupold from comment #5) > I can't tweak the search results, I just use what Marble outputs. It's the > very same you get when you search for something using Marble. Understood. > However, using Marble's search functions was easy to add (and it's better > than nothing, isn't it?!) Absolutely! And thankyou so much for adding it, and so quickly. I really appreciate it. > whereas using e.g. Nominatim would be more work > to implement (well, it would be essentially the same as the altitude > lookup). Maybe something for later? For sure. I tried a (Windows only) app called GeoTagNinja, and that uses ArcGIS, which then required an API key. > 1. You can already copy the current map center coordinates formatted > properly for e.g. use in Google Maps. Just open the context menu on the map > and choose "Current map center" and then "Copy as 'latitude, longitiude'". > You'll get the string you can append e.g. to your preferred Google Maps URL. Yep, thanks for that, had already seen it. I just thought a configurable option to "launch a URL" and % formatting args would be useful. > 2. The OSM view is the only one suitable for geotagging. All others are way > too coarse to find or check a location, we need a few meters in resolution. > So I don't think it would be meaningful to add an option to switch to a map > view that can't actually be used for the only thing KGeoTag was written for. Ok, totally understood and agree. > For both suggestions, I think neither being able to open coordinates in an > external program/website etc. nor switiching to e.g. Marbles's sattelite > view will help when geotagging photos, will it? It would be for me. Being able to see the satellite landmarks when trying to manually tag photos would be useful (just to know if I'm "in the ballpark" so to speak). Which led me to thinking about launching a URL, ie. to go to the feature-rich Google Maps, where I can then toggle sat view, go to street view etc to check a landmark. (In reply to Tobias Leupold from comment #6) > However, concerning the sidecar files: KGeoTag does not mess with those at > all, this is all done by KExiv2. So if you think that sidecar files with > other names should be read as well, you should file a bug there. Ok. Perhaps there is an env var or config to influence the naming, I shall look into it. Sadly, Capture One software doesn't recognise sidecars with the full filename plus .xmp extension. Annoying. And if I already have sidecars in the "non full" format, KGeoTag (via KExiv2) doesn't recognise and load them either. Fair enough, if it helps people in their workflow, I can as well add some configurable URL to open. I think this is not too hard to do. Would you mind to file another bug report/feature request for this? Also, please file one for KExiv2 concerning the sidecar file naming. Looking at the sources, there's no option to tweak this. They simply add an ".xmp" to the file's name. Then I'll propose we can close this one? :-) Git commit 7b9192cdbc1464dd48816f790e25727fd42bf3f6 by Tobias Leupold. Committed on 05/01/2026 at 13:59. Pushed by tleupold into branch 'master'. Added opening the current map center in OSM and Google Maps M +7 -0 CHANGELOG.rst M +4 -1 src/KGeoTag.h M +66 -1 src/MapWidget.cpp M +2 -1 src/MapWidget.h https://invent.kde.org/graphics/kgeotag/-/commit/7b9192cdbc1464dd48816f790e25727fd42bf3f6 (In reply to Tobias Leupold from comment #9) > Fair enough, if it helps people in their workflow, I can as well add some > configurable URL to open. I think this is not too hard to do. Would you mind > to file another bug report/feature request for this? Nice, thankyou! I see you've done the commit already, still want another ticket? > Also, please file one for KExiv2 concerning the sidecar file naming. Looking > at the sources, there's no option to tweak this. They simply add an ".xmp" > to the file's name. I've since had a look at digiKam, and it has an option called "Sidecar filenames are compatible with commercial programs", which does exactly what I was talking about. Looks like this is handled in the source here (as an example): https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/database/collection/collectionscanner_scan.cpp#L711 |