Add support for location description

[adamreichold]

Please consider adding support for setting a location description as an alternative to specifying geographical coordinates, i.e. something that will be mapped to IPTC's Location Created or Location Shown or the legacy City, Province or State and Country tags. Picture editors often use this information stored in their image databases to find photographers working in a particular area, so it is rather useful to be able to include this information.

[jim-easterbrook]

That's a good idea. I've steered clear of it up to now because it's IPTC only (as far as I can tell) and it's difficult to validate free entry text. I think all three of the map providers Photini uses can convert GPS coordinates to a location text. Would you be happy to use that text unmodified or do you need the ability to edit it?

[adamreichold]

Thank you for the quick reply! Yes, automatically retrieving this information based on the geographical location should be sufficient. (Of course, being able to supply it manually if the map provider is unable to resolve the given location to an address might be useful, but at least for my use cases, it should not matter.)

[jim-easterbrook]

I want to get the next release out this week, then I'll start investigating what I can do with the software libraries Photini uses.

[adamreichold]

Thanks again! I am looking forward to testing these changes.

By the way, when creating a SCM-enabled OpenSUSE package to prepare for said testing, I noticed that Python's distutils are not completely happy with the chosen versioning scheme:

 /usr/lib/python3.4/site-packages/setuptools/dist.py:285: UserWarning: Normalizing '2017.03.0' to '2017.3.0'

(As an aside, I think building such packages could be easier if the Git tags would match the versions exactly and keep to a fixed format, e.g. 2017.03.0 instead of v2017.03.0 and 2017.03.1 instead of Windows-2017.03. But of course, these things can be worked around...)

[jim-easterbrook]

The Windows-2017.03 is not a Photini release but a Windows installer (that downloads the latest Photini version from PyPI). I use date based version numbers as I don't usually save up significant changes for a major version increment, just releasing incremental stuff as I go.

[adamreichold]

The Windows-2017.03 is not a Photini release but a Windows installer (that downloads the latest Photini version from PyPI). I use date based version numbers as I don't usually save up significant changes for a major version increment, just releasing incremental stuff as I go.

The date-based versions are not an issue at all IMHO. distutils just does not seem to like the leading zero and would seem to prefer 2017.3.0. And the leading v is only a problem as the tag name cannot be used as a package version directly. The same problem with the Windows tag since it also does not start with a digit. But these are admittedly paper cuts at most...

[jim-easterbrook]

My point is that the Windows-* tags should be ignored as there's no point packaging them for any Linux distribution.

[adamreichold]

My point is that the Windows-* tags should be ignored as there's no point packaging them for any Linux distribution.

I fully agree. The things I mentioned are just nitpicks that make it more difficult to create a package that automatically follows every commit in the repository and has a nice human-readable version. They are non-issues for packaging otherwise.

[jim-easterbrook]

I've sorted out the leading zero and 'v' annoyances - things have moved on since I last looked into best practice. The Windows uploader problem is harder - I need somewhere to upload Windows installer binaries to that isn't too intimidating.

[adamreichold]

Thank you for taking up these suggestions. I guess I have just volunteered to maintain that particular VCS package for the foreseeable future. ;-)

The Windows uploader problem is harder - I need somewhere to upload Windows installer binaries to that isn't too intimidating.

I do not know the process behind creating these installers, but here are my two cents anyways: I think ideally they would just be attached to the usual releases resp. tags. For example when you release e.g. 2017.5.0, it could have the two source archives and the Window installer. And even though there is no need to make a full release if only the installer needs to be updated, it should not hurt either? For example, one could just tag the same commit that is 2017.5.0 as 2017.5.1 to have a separate release without the fear of regressions (if the installer is created independently of any repository code changes that is). If the change log says that this is just an installer update, packagers can skip it if they want. (If the installer is updated via code changes in the repository, it is probably simpler to just bite the bullet and make another release instead of fumbling around with maintenance branches.)

[jim-easterbrook]

I like that. Better still would be if I can reuse the already uploaded installer - they're rather large files.

[jim-easterbrook]

@adamreichold Do you know any source of test images with location data? Ideally images with legacy data and / or with the newer location structured data.

[adamreichold]

http://metadatadeluxe.pbworks.com/w/page/20792267/Sample%20Images seems to have some examples with the old data types. I will look for some with the new structure types as well, but I am not sure when I will be able to provide them...

[jim-easterbrook]

Thanks. No hurry as there are plenty of other bits to work on.

[jim-easterbrook]

Progress so far: I've added location info to the GUI map tabs and am able to read legacy tags from files and display them. I've failed to write any data in the new Location Shown / Created format, mainly because I don't know how to persuade GExiv2 (from Python) to write structured data. I also don't know if I can read this format as I haven't found a suitable example file.

[jim-easterbrook]

Update: using exiftool to set some new format tags showed what I was doing wrong. I think I'm getting somewhere now.

[jim-easterbrook]

I think I've found out why I'm unable to save new location values, unless another tool has already saved some. It's all down to Exiv2's helpful shortening of Iptc4xmpExt to iptcExt. The proper names of the tags are of this form: Xmp.Iptc4xmpExt.LocationShown[1]/Iptc4xmpExt:City which Exiv2 shortens to Xmp.iptcExt.LocationShown[1]/Iptc4xmpExt:City. When I try and save the tag I get an Unknown namespace prefix for qualified name error, because the Iptc4xmpExt namespace is unknown. Using another tool to create one of these tags adds the namespace and then I can save more tags with no problem. I can't register the Iptc4xmpExt namespace within Photini because (I assume) Exiv2 shortens it to iptcExt and thinks it's already registered. (The GExiv2 wrapper won't register a namespace that's already known. See https://github.com/GNOME/gexiv2/blob/master/gexiv2/gexiv2-metadata-xmp.cpp#L402)

[adamreichold]

I am sorry that I am currently unable to contribute to the implementation of this function, but please know that I am rather grateful that you share your progress here. Concerning the last set of issues with Exiv2 that you raised, I guess the best way forward would be to implement only the legacy fields for now. (I did have a short look and all the tools I used up to now (mostly from the digiKam/KDE community) also write only the legacy fields.)

[jim-easterbrook]

I've resorted to legacy fields only for now, though any new location data in a file will be read and merged into the legacy values.

[jim-easterbrook]

If you get a chance to test the current stage of development I'd welcome any feedback. In particular the reverse geocoding from some maps can have a wide range of element names, some of which I won't have encountered yet and which could be useful. Let me know any problem lat/long values.

[jim-easterbrook]

Updated documentation, with new screen grabs. http://photini.readthedocs.io/en/latest/manual/map.html#address-lookup

[jim-easterbrook]

I've found a workaround for the Iptc4xmpExt namespace problem now, so could write the new tags. I suppose it would be a good idea to write the legacy tags as well, for compatibility with other software, although I generally prefer to store information in as few places as possible to reduce the chances of conflicts if one copy is modified. The user needs to be aware that the extra information in the new tags won't be seen by some other software. I'm thinking of having those fields disabled until the user sets an option to use new style locations instead of 'legacy' locations.

[jim-easterbrook]

I've released version 2017.6.0 with what I hope is a fully working location metadata implementation. The documentation warns the user not to use some fields if they need compatibility with applications that only handle legacy data, but I've not implemented anything in the code to enforce this.