importing locations to a specif list of photos is applied to all the active directory about geotagninja HOT 22 CLOSED

Yes it is fixed now
Thanks
Phil

from geotagninja.

Noted - I'll have a look.
It does indeed work that way at the moment. I think that was the original request/wasn't otherwise specified. But if I can incorporate individual filenames into the logic I'll defo do it, it's just that geotagging works with a somewhat different command logic in exiftool than the rest of the stuff.

from geotagninja.

Hummm Are you sure that it worked like that in the past ? Perhaps I am wrong…
But in the (my) real life, the way I work is:
Select a batch of photo and try to use existing file positions
There are always photos without locations ( because of Google lack of positons or in case of lack of positions from my mobile)
Then I select missing photos and try to find locations by increasing the time between positions (less precision but is often enough)
And finally add missing locations by hand by clicking the map

This means that it is necessary to have the possibility to make those jobs for selected photos only without changing anything to others.

In geosetter, I used the filter « show photos without locations ». So after each tentative to find locations, there were only the photos with missing locations

And at the end of the end, I make a « save everything »

Il think this is a major point . And sorry if I did not notice that in all my previous tests .
I am afraid I have surely added bad locations to some of my photos with the existing behavior

regards
Phil

from geotagninja.

It's definitely been the same always ;) -- the tldr is that exiftool works one of two ways:
Either the user can pass an ungodly long parameter list in command prompt or use a so-called arguments file, latter being a lot easier to manage. For whatever reason geotagging as a function either doesn't work with the args file or I have failed to figure its ways, so I had to resort to using the long command line, which is tedious but seems to work. At the time of the original request the logic (in my mind anyway) was that the active folder gets the tags applied to, not the selected files, as if there is no matching data in the gpx files then there is nothing to apply (ie no change takes place), and if there is matching data then logically it would be deemed correct.

Current somewhat lengthy code for running your position files you sent me a while ago:

Note at the end the foldername just before -v2 -- I'll see if I can make it work with a list of files instead.

from geotagninja.

Okies changed 10e15a9
See updated installer on google drive pls.

from geotagninja.

Hi, i just installed the latest google version;
strange thing with windows:
installation screen is stuck at the upper left side of my screen without posdsibility to move it
I will have to crash it

Phil

from geotagninja.

when selecting a list of photos, the nu "remove geodata" removes also the time offset

from geotagninja.

I think that's the installer being silly - not sure if I can debug it because it's just packaged by Visual Studio but it's code as such. (I have no control over it)
Let me know if trying again works

Worst case you can try https://helpdeskgeek.com/how-to/move-a-window-with-the-keyboard-in-windows/

from geotagninja.

when selecting a list of photos, the nu "remove geodata" removes also the time offset

That's a feature not a bug - logically the time offset (time zone) is linked to the location of the photo. No location, no offset.

from geotagninja.

all the popup menu are blank
and more important menu is missing !

from geotagninja.

from geotagninja.

Weird. Okay I'll have a look, it was yesterday when I last checked but there were some code changes since.

from geotagninja.

I took the version this morning

from geotagninja.

Works okay for me both Fre and Eng.
I've re-posted a build just now on googledrive. It will have a different build number but otherwise identical to what it was yesterday. See if it works.

from geotagninja.

Ok Will try later to day.
have a look in the issue about unwanted time offset blanking when removing locations from a selected list of photos. This is not major but could hide something else
I will make further tests this afternoon ( if I have menus !)
Phil

from geotagninja.

I can add in an option into Settings to control that (offset delete) on the user side if that's acceptable...?

from geotagninja.

OK the installation worked that time;
I made several tests and it is now possible to update locations to a selection of photos : fine !
for the offset, I dont think an option in the menu is a good solution because removing offset data has nothing to do with (remove) localisations; So for me it would not be removed/modified.

another feed back: from a set of photos with localisations, we have the localisations on the map; when removing the localisation, and even after refresh, the localisations are always on the map. they dont appear only by stopping and restarting the softyware and reload the photos.

One remark : by definition and by its name, your program is for "geotag"; why did you shift all the localisation columns to the right ? it is possible to change but this needs some gymnastic with the mouse !
Regards
Phil

from geotagninja.

I've found a bug in the meanwhile that if you remove the geodata (using the button in the Edit Form, not the button in the "Main Form") then that gets entirely ignored.

I dont think an option in the menu is a good solution

(ignore the odd labels, this is just what it looks on the inside and i'm working on the above bug atm.)

Basically if user checks that last box then it will do what it's doing currently, otherwise it will not delete the Offset.

from a set of photos with localisations

The map only updates if there is an actual value to update with. When the user removes the location that's a null-value, so it gets ignored by the map. I can think about working around it but technically it's a feature so to say.

why did you shift all the localisation columns

I don't lol. When @Urmel changed the dynamic column orders that came in - originally it was in the front. But I'll look into why they've moved to the back.

from geotagninja.

Reference to myself: 320a0b7
New version copied to google drive. I'll have a look at the column order in the meanwhile.

from geotagninja.

why did you shift all the localisation columns

Fixed 728e574

from geotagninja.

from a set of photos with localisations

fixed in 823d2aa
may i ask that for new issues we open new tickets please. i am personally admittedly bad enough at mixing commits together in code but at least having different tickets for different issues makes things a little easier to follow ;) -- thanks
copied to GD.

from geotagninja.

Hi @pbranly can I close this pls?
I'll be away for a week or two around from this coming Friday so I'm hoping to do a public (not "development") release if all's well beforehand.

from geotagninja.