[Digikam-devel] [Bug 192442] Allow tags to be used to geolocate images

[DGardner]

https://bugs.kde.org/show_bug.cgi?id=192442





--- Comment #4 from DGardner <dkde gardnersworld org>  2009-05-13 10:25:59 ---
> Creation of new tag would require not only to set name for it but would also
> present user with additional fields put coordinates (and you would have to get
> them in laborious process you described), choose contact name, put URL, etc.,
> etc.

The laborious process is inevitable given the current mechanism for
identifying co-ordinates, I agree, but how often I have to go through
that laborious process is something about which something could be done.

The user interface does not have to be cluttered, you can just add tabs
to the dialog for additional tag attributes or use the common idiom of
an "Advanced >>" button that expands the dialog contents. The choice
would stem from any decision about a long-term approach to the more
general suggestion I offered in bug #192447.

> Those tags also would have to be somehow defined/commented with
> locations and other data. There is no method to avoid that stage.
> Access to once written data would be very similar in both yours
> and mine ways.

My tags are already defined and have been for years. I do not pretend
that setting the co-ordinates for each tag is any easier than setting
it for a photo. I would expect that the same "Edit Coordinates" dialog
would be used. However, once I have a tag configured, I never need to
search for the co-ordinates for that location ever again, I just assign
the tag. (Most of the time, I take photos in locations where I have
already taken photos, so this would be a real time-saver.) Then, not
only do I get my photos geolocated, I can also search for the name of
the location because that name is part of the tag. The name could even
be displayed on the map.

The idea--and this is the crucial bit--is that I select a bunch of
images and go click-click-click on the check-boxes in my tag hierarchy
on the right and I'm done setting all my tags. There are no dialogs,
no awkward menus, nothing other than simple clicks on check-boxes. I
might add that I never use the drag-and-drop method or the context
menus to assign tags because they are too slow. I would certainly
never make any use of the BQM method as I cannot see how it is any
easier or quicker than the current approach. I really, really only
want to have to click on check-boxes on the tag hierarchy. I think
the current implementation is excellent in that respect: tagging
photos is so efficient that I use the feature very extensively.
(The only improvement that could be made to its efficiency would be
to allow tags to be associated with keystrokes and that has already
been logged in the wishlist.)

I glad to read that you think there may be some merit in my more
general proposition to support semantic tagging. I understand how
you might feel that because the Exif can already carry GPS data
that there is no point in confusing that with tagging. However,
very few cameras support GPS tagging and GPS track logs are only
ever going to be of minority appeal. Until built-in GPS becomes
universal (if ever) it would be nice if digiKam were to make the
addition of geolocation data after the fact as easy as possible.
If tag semantics are added and tags can carry additional data, then
the use of tags to carry geolocation data would be a small extension
that would greatly simplify the workflow of many users (well, one
user, anyway ;-).

 * * *

I understand how a developer, such as yourself, can have an objection
to any proposal that may add complexity for what might only be a
marginal gain. I usually take it as a sign that the developer is
experienced enough to understand that sometimes enough is enough and
that there is is such a thing as having too many features. I'm like
that myself: I'll do what I can to try to convince customers that they
don't need the feature they are asking for and, if that doesn't work,
I try to offer something as simple as possible that will go some way
towards meeting their requirements. It is not out of laziness, it is
out of an understanding gained from years of experience that what a
customer really needs is a system that works well and that I can only
guarantee that it will work well if it is not too complex to be
extended and maintained.

In that spirit, I (the customer) accept your concerns and offer this
phased approach to "ease" you into the idea. Each phase adds new
functionality of gradually increasing complexity. You can stop when
you feel it has gone far enough, and digiKam will still be better
than it was. Maybe it won't be as good as I'd like it, but I can't
win them all.

Phase 1:

Enhance the "Edit Coordinates" dialog box to allow the selected
co-ordinates to be assigned a name. For example, I select latitude
48.8582, longitude 2.2946 and I name it "Eiffel Tower" and save
that name to a list shown at the side of the dialog. This is very
similar to the existing approach for saved searches used in the
left-hand search panel of the main albums view window. The next
time I open the dialog, I can either use the hit-and-miss Google
map search, or I can just pick a saved name on the left. Either
way, I am just selecting the position and then assigning it to
the selected images. This would be a genuine improvement over the
current system and would require no addition to existing tag
functionality.

Phase 2 (optional):

Allow the position names and co-ordinates to be exported to a CSV format
file for external processing by scripts or editing in a spreadsheet
application. Allow these to be imported again to re-populate the saved
list. These files could be shared between users for major locations such
as cities, tourist attractions, etc. to avoid the need for everyone to
define their own named positions.

Phase 3 (optional):

Now that positions can have names, the names can be shown on the map
where photos at those positions are marked. If the co-ordinates do not
match any name, then the map can look as it does now. However, if the
co-ordinates match the name "Grandma's House", then that name appears
on the map much like the major city and town names already do. This is
preferable to the current approach of showing the photo names, as
photo names tend to be (for most people, I suspect) mostly numeric.

Phase 4:

If semantic attributes can be added to tags for other purposes (e.g.,
e-mail addresses, URLs, etc.), then the saved position name could be
added as one of those semantic attributes. Now, when I apply a tag,
the geolocation process can use the tag semantics to aid geolocation
and not depend on the embedded GPS co-ordinates of the image. When
the tag is applied, the co-ordinates are *not* written to the Exif
data and any co-ordinates in the Exif data take precedence over the
tag co-ordinates.

I concede that extending tags to support attributes only for the
purpose of geolocation is probably too complex to be justified.
However, were tags to have generic support for such extended
attributes, then I think geolocation data could be justified on the
grounds that it is just one more attribute being added to a system
that is designed to be extended in that way.

Phase 5:

Allow the co-ordinates of the position to be associated directly with
a tag without a need for a saved position name. In effect, the tag
represents the name of the position and that tag name can be shown on
the map. The co-ordinates are still not written to the Exif data when
a tag is applied.

The tags and positions can be exported and imported to and from CSV
format just like named positions. This would allow external tools and
scripts to exploit this data and allow easier maintenance.

Phase 6:

Support the option to override the Exif co-ordinates--where they exist--
with the co-ordinates from the tag (or the position name associated with
the tag). By default, the Exif co-ordinates will not be overwritten, but
by clicking on an icon between the check-box and the tag name in the tag
hierarchy representing the semantics of the tag (e.g., a small envelope
icon for a tag carrying an e-mail address, or a small map icon for a tag
carrying a position, etc.) the data will be applied. The icon will appear
greyed out if the data is not embedded in the image and will change to
full-colour when the data is embedded (tool-tips or other cues can be
added for accessibility purposes). Clicking on the icon toggles its
appearance and toggles the assignment of the data much as the check-box
can be toggled. It's all just click-click-click on the marginally enhanced
tag hierarchy panel.

 * * *

Whaddya think? Even if you could just deliver on Phase 1, I'd be a much
happier bunny.

Damo.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.