Fix ExifTool geolocation parsing for custom path templates#525
Open
vesaias wants to merge 1 commit into
Open
Conversation
Two related fixes for the new ExifTool reverse-geolocation flow added in PR jmathai#481/jmathai#505 so paths like `%date %country` resolve correctly end-to-end: 1. geolocation.py: accept both prefixed and bare exiftool keys. `is_exiftool_available`, `exiftool_coordinates_by_name`, and `exiftool_place_name` only matched `ExifTool:GeolocationCity`/etc., missing the bare `GeolocationCity` form that exiftool returns when the `-G` group flag is not in effect. A new helper `_geolocation_field` transparently tries both forms. 2. filesystem.py: expand sub-key aliases inside `%custom` templates. `get_dynamic_path` for `custom` recursively dispatched each `%foo` token but passed the literal `%foo` as the mask, ignoring the `[Directory]` config alias. As a result, configurations like location=%country custom=%date %location full_path=%custom resolved `%location` to `place_name['default']` (the city, since exiftool_place_name sets default to the most-specific field) instead of expanding via the `location=%country` alias. The custom resolver now substitutes the alias value before recursing, mirroring the top-level path resolver. Tests: - 4 new geolocation tests cover both bare and prefixed key forms in is_exiftool_available, exiftool_coordinates_by_name, and exiftool_place_name. - 1 new filesystem test exercises the `%custom` -> `%location` -> `%country` expansion chain.
3203f8c to
4263c8a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two related fixes for the ExifTool reverse-geolocation flow added in #481 / #505 so country/city/state placeholders resolve correctly end-to-end when used inside
%customtemplates.Verified end-to-end against an iPhone photo geotagged in Chivay, Peru:
2022-03/Chivay/...— country slot filled with city name.2022-03 Peru/...— country resolves correctly from the[Directory] location=%countryalias.Changes
elodie/geolocation.py— accept both prefixed and bare exiftool keys.is_exiftool_available,exiftool_coordinates_by_name, andexiftool_place_nameonly checked forExifTool:GeolocationCity/etc., but exiftool returns bareGeolocationCity/etc. when the-Ggroup flag isn't in effect. A new_geolocation_fieldhelper tries both forms.elodie/filesystem.py— expand sub-key aliases inside%customtemplates.get_dynamic_pathforcustomrecursively dispatched each%footoken but passed the literal%fooas the mask, ignoring the[Directory]config alias. With a config like%locationresolved toplace_name['default'](the city, sinceexiftool_place_namesetsdefaultto the most-specific field) instead of expanding via thelocation=%countryalias. Thecustomresolver now looks up sub-keys in[Directory]and passes the alias value when dispatching, mirroring the top-level path resolver.Tests
geolocation_test.pycover both bare and prefixedGeolocation*key forms inis_exiftool_available,exiftool_coordinates_by_name, andexiftool_place_name(mockingExifToolso they're network-free and deterministic).filesystem_test.py(test_get_folder_path_custom_template_expands_location_alias) exercises the%custom→%location→%countryexpansion chain with a mockedplace_name.All other tests pass except for 7 pre-existing failures on master that depend on a live MapQuest key (
test_get_folder_path_with_location,test_get_folder_path_with_album_and_location_fallback,test_get_folder_path_with_custom_path,test_get_folder_path_with_with_more_than_two_levels,test_get_folder_path_with_location_and_title,test_process_file_with_location,test_process_file_with_location_and_title) — verified to fail identically againstmasterbefore this change.Test plan
pytest elodie/tests/geolocation_test.py— 27 passed, 2 skipped, 5 pre-existing env failures unchangedpytest elodie/tests/filesystem_test.py— new test passes; same 7 pre-existing failures as master[Directory] location=%countryconfig:*.JPG(Chivay/Peru GPS) lands atout/2022-03 Peru/...