I think this is too specialized.

You can easily mass-geolocalize your photos by selecting as many as you wish, use geolocalization choose location and all of them will be marked with this location.

Theoretically this could be done with Batch Queue Manager - two actions in one queue, 1st assign tag, 2nd assign location. Since there is much data "geolocalization queues" could be generated automatically and distributed separately as text files(?). You want this feature, download this files, place in appropriate place and voila.

Note: I don't know how queues are stored, maybe it is worth to make them as simple plugins?

I'm not sure that I understand what you mean by "specialized" in this
context. I'm just suggesting a feature to associate co-ordinates with
any arbitrary tag that a user defines to represent a place. Do you mean
that having tags that represent places is an unusual quirk of mine?
I thought it would be a very general thing.

I added bug #192447 that is a further generalisation of this request:
allowing tags to have different associated meanings or attributes.
Maybe that will provide more context.

Perhaps a simpler approach would be to allow tags to have co-ordinates,
but not to set co-ordinates in the image based on the tag. If an image
has no co-ordinates, but has a tag with co-ordinates then the tag's
co-ordinates could be used for geolocation. If the image has
co-ordinates the tag will be ignored and the image's co-ordinates will
be used.

> Theoretically this could be done with Batch Queue Manager [...]

The problem with the batch approach is that it is not as simple as selecting
images and clicking on a tag. I generally tag hundreds of images at a time,
applying several tags to each, so messing about with dialog boxes and batch
queues for some tags and not others would be horribly slow and awkward. It
may work, but it is no improvement over the status quo of using the Edit
Co-Ordinates dialog and would probably be worse.

> You can easily mass-geolocalize your photos by selecting as many as you
> wish, use geolocalization choose location and all of them will be marked
> with this location.

My point is that I already chose the location over the past few years using
my "Places/..." tags and have 13,000 images that have a tag identifying the
location, just not one that can be used for a geolocation. It would be a
whole lot easier to geolocate the tags than all of the images. I can do
this for existing images as you say,  but I also have to repeat the tagging
and geolocating steps each time I add new images instead of just geolocating
the tag for once and for all and then just tagging new images as before.

Once I've geolocated my tags I only do this:

 1. Select images.
 2. Check the box for my "Places/*" tag.

Instead, I have to do this each time I geolocate new images:

 1. Select images.
 2. Select "Image->Geolocation->Edit Coordinates" from the main menu.
 3. Wait 5-10 seconds for the Geolocation dialog to be ready.
 4. Click in the Search field.
 5. Type in the location.
 6. Click the Search button (the results come back quickly).
 7. Pick a search result and see if it is OK.
 8. Probably refine the search or give up and pan around the map manually.
 9. Zoom in and pan around the map to find the exact location.
 10. Place the marker for the location.
 11. Click the OK button.

Maybe you think I'm making it sound harder than it is, but the trial and
error is exactly what I experienced for about 90% of the locations that
I tried to set yesterday. I would still have to do most of the second
process to geolocate each tag, but I add "Places" tags far less often than
I add new images.

You can think of the whole things as a way to associate a name with some
co-ordinates. Even that on its own would be more convenient. The Edit
Coordinates dialog could allow me to save the position to a list of
named positions (just like saving searches in the search panel) and then
I could pick an existing position quickly instead of messing about on
the map. For example, I could have a "Home" position, as I take lots of
photos at home. However, I already have a "Places/.../Home" tag and all
I would be doing is applying the "Places/.../Home" tag and also applying
the "Home" position (or "place") again in another dialog. Combining the
two together makes sense.

I know that this is something of a departure for the tagging system as
it stands. However, as I describe in bug #192447, the tagging system
should evolve along with the rest of digiKam. It is very good now and
is the compelling feature that drew me to digiKam and keeps me there,
but it could be really great.

By "specialized" I mean that you asks for very specific extension of tag functionality requiring separate interface which will not be clean and easy to use, especially with additional features required by Bug 192447.

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.

I am suggesting solution which will use existing (at least in trunk and partially) features to create new quality. BQM already allows to run Queues from context menu so access to action previously described would be as easy as tag assignation from context menu. True there are several ways to assign tags and context menu isn't fastest of them.

> I generally tag hundreds of images at a time,
> applying several tags to each, so messing about with dialog boxes and batch
> queues for some tags and not others would be horribly slow and awkward.

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.

I probably didn't explain idea behind BQM clearly enough. In BQM you can create list of actions to perform on group of images. Those lists can be saved and 
accessed later from special dialog or context menu. In my scenario for each location you could create two item action list. First item is assign some tag. Second item is assign geodata. Access to that action would be from main menu, context menu and BQM dialog.

Note: your more general idea has merits and many potential uses come to mind but assigning geodata IMO isn't among them.

> 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.

+1

I think associating geographic info with tags is an excellent idea.  I implemented this in my home-grown photo-management system, and it makes geo-tagging very straightforward.  I also associated a level of resolution with each tag (which is simple order of magnitude radius in metres; 10km/1km/100m etc), so I could roughy tag "London" and then get more specific with particular images.  

An important part of this is that it is much more general than having a single "location" embedded in to a picture; I can have multiple locations associated with an image (such as where I was standing and where the subject is, which is often quite separated for large landscapes).  However, if I'm setting the location down to 1-10m resolution, actually setting the photo location is probably better than encoding it in a tag.

An obvious generalization is to be able to attach arbitrary metadata to tags, which are then overlaid on any image to which those tags are applied.  I guess bug #192447 addresses that.

Hi guys, I know this is an old wish today, however, it seems to be at least partly covered by geo-location plugin in digiKam 2.0beta (both manual coordinate settings and reverse geo tagging). It is not polished yet, but basically works.

The major trouble would be how to migrate the manually created geo tags (Places / England / London) to whatever tag hierarchy OSM or geonames.org return.

*** This bug has been confirmed by popular vote. ***

Miche

Michael,

This file can be considerate as solved since reverse geocoding is implemented in GPSSync kipi plugin, as it's annotated to comment #6

Gilles Caulier

Michael,

Do you seen my previous comment ?

Gilles Caulier

Hi Gilles,

the original bug report wants to attach coordinates to tags. This has not been implemented. I like that idea, so I would like to keep this report open.

Michael