Migrate GPXTrackSync to use EXIFWrapper and Remove ObjectExifIn-Mapping about geotagninja HOT 6 CLOSED

Regarding the "update list view"...

• Currently, the Directory Elements are just read once when initially populating the list view
• The actual properties of the DEs would also support a "changed" notion so that we can color single cells to have been modified

If we migrate TrackSync - it still writes to the list view as text (and not in the DEs as updated data). This has a couple of things to be aware of:

• The conversion logic tags to model to column values is separated in two : TagsToModel and ModelToColValues - we would need to adapt for that.
• When we want in the future to use this DE attribute changed feature, we then would need to touch it a second time.

I thus propose to first introduce (in parallel to current things) the possibility to instead of writing changes to the list view, to write them into the directory elements and use a defined update mechanism to refresh the list view and show changes. This refresh however may only touch modified fields in order not to destroy the modified coloring of not-yet migrated parts of the program.

from geotagninja.

Hi,

My two cents...

Migrating TrackSync

• not sure this is possible tbh or if it's sensible. Admittedly since there is no analytics built into the app i don't know how many people use the app or what particular functionality is being used more commonly but I'd hazard TS is less used. Also the actual time required for the user to go through the whole process of selecting image files, clicking all the various buttons and dropdowns to set up the whole TS thing (such as time zones, shifts, GPX source paths, whatnots) is pretty time consuming. What I mean is that the extra 2 secs for ET to fire up each time when they press the button isn't significant and I'd imagine throughout one whole session users wouldn't have more than 1 (or 2) syncs done.
• somewhat harkening to my other comment re: preview generation, I think this would require yet another instance of ET to keep running in the background.
• the code logic with TS is "a bit" different from the "normal" read-in. this is partially because the args file and/or the arguments themselves need(s) to have each and every .gpx file and each and every image file named explicitly and because the actual output from ET doesn't go to the image file but instead goes to placeholder XMP files that then get read in as part of the process (so as that user can have the choice to refresh the folder and on purpose forfeit the changes if they want to). I think this would be relatively complicated to move to a different logic.

Directory Elements

Ultimately I think we should try to move away from the current 3-tier datatables (DT1, DT2, DT3) and have the DEs instead. I think we'd need to keep the 3-tiers unless we come up with a better way of doing it but as in the current version, the 3 tiers are identical in structure.
Since the DE stuff is ultimately your baby I think you know more about it than I do but if we tried to transition something (as in point at a random current function and transition it) from DT3 to DE we could probably replicate that comparatively easily afterwards.

from geotagninja.

I understand that TrackSync feels like a "less important" feature - for me, it's actually an important one :) I used GeoSetter and now GeoTagNinja a lot for this, as my camera does not have a gps tracker built in and I thereby can just sync the recorded track from my smartphone.

• the code logic with TS is "a bit" different from the "normal" read-in. this is partially because the args file and/or the arguments themselves need(s) to have each and every .gpx file and each and every image file named explicitly and because the actual output from ET doesn't go to the image file but instead goes to placeholder XMP files that then get read in as part of the process (so as that user can have the choice to refresh the folder and on purpose forfeit the changes if they want to). I think this would be relatively complicated to move to a different logic.

Ok - I understand that TS works using generated XMPs. Couldn't we shortcut the whole EXIF Folder import just on that one? Currently the full blown we import everything is used. Plus: we only want long, longref, lat, latref, alt, altref?
If we could strip this down, I think we will get rid of some lines of code and the rest will be easiert to maintain. Wouldn't even need to migrate to EXIFWrapper...

from geotagninja.

Couldn't we shortcut the whole EXIF Folder import just on that one?

Not sure I fully understand that but....the "Exif folder" is the users\username\roaming\geotagninja\tmpLocFiles folder, basically where everything else (session-lived) sits as well. You're generally correct that all we need is the coordinate-related stuff but it is also just what we get i think (as in the exiftool -geotag= only outputs that).

The rest are pulled by the app/API.

The reason why we get XMP files rather than the data being written into the images is on purpose -> user can decide not to apply the changes and if we had written to the image file itself then that's that, no undo option.

from geotagninja.

Fully with you about the process here.

Regarding the adaption of the method used - sorry, I meant the "ExifGetStandardisedDataPointFromExif". This is only referenced by ExifGetTrackSyncData and does much more than it is needed by ExifGetTrackSyncData. I further calls ExifGetRawDataPointFromExif, which also is only needed for the TrackSync.

So maybe, we can streamline these two methods and also get rid of the object_in mapping in SQLite if we hard code the used tags....

from geotagninja.

Closing this as in the last dev version I've finally done away with the sqlite tables.

from geotagninja.