Created attachment 104410 [details] Patch to reorder/reword gps correlator options As discussed internally this is a quick improvement of the displayed options without touching any of the underlying code.
Created attachment 104411 [details] Screenshot of the new UI
Fine for me... Gilles
Git commit f08b494231bf8405ce7155f1f7f187d17a25d6d6 by Simon Frei. Committed on 06/03/2017 at 16:06. Pushed by sfrei into branch 'master'. Improve gps correlator UI order M +2 -1 NEWS M +6 -6 utilities/geolocation/editor/correlator/gpscorrelatorwidget.cpp https://commits.kde.org/digikam/f08b494231bf8405ce7155f1f7f187d17a25d6d6
Simon, you wrote via direct mail that you opened this as a wishlist. So I would like to add to that: 1) The Max. time gap is in seconds, the Max. interpol. time gap in minutes which doesn't make much sense to me considering what we discusses earlier. Both should be in second and the max. value you can introduce should also be the same (240 min. = 4 h doesn't make much sense for interpolating a position IMHO. With such a value you even had to take continental drift into account ;-)). 2) Instead of the one checkbox "Interpolate" there should be two toggle boxes/buttons where, if you check one, the other gets unchecked to make clear: either direct match or interpolate, both not possible. From that little bit of testing I could do I'm not sure if this is really implemented in the code (one or the other), at least I had to fill in zeros in one I wanted to disable. Looked a bit as if one of the two options has a higher priority. Unfortunately I have no time right now to test a bit more. Wolfgang
Hi Wolfgang, 1) Lets assume the current behaviour is really either only do direct matches or do direct matches and interpolate when a direct match is not possible according to limit. In that case in my opinion it makes sense to have generally a much longer limit on interpolation than on direct matches. I mean that is the point of interpolation: Try to get a more accurate result in case all points are too far away for a direct match. What do I miss? 2) I agree that both at the same time is confusing and I can't see any benefit. And I would even tend to always interpolate and certainly make it the standard behaviour. I struggle to imagine a situation where interpolation is adversary. Cheers, Simon
Hi Simon, I'd rather start with 2) because that will deliver also the anwer to 1): I agree that nearly always interpolation is the better, because more precise option. The only where it is not is when you moved from one GPS point to the next not straight but in a really bad curve (like helmet camera in a slalom skiing race. Poor example, I know, too fast for GPS). If the amplitude of that curve is bigger than the distance between the two points you might get a worse result than with direct match. What you described under 1), interpolation being kind of a backup for direct match, doesn't make sense to me as long as interpolation is considered the better option anyway. And it would be everything else but intuitive. It would really require a description within the GUI. And even with all the space I have in the handbook it wouldn't be easy to explain (how it works yes, but what it is good for ...?). So I would still opt for the either - or solution and regarding the limits I think it would even make sense to have a smaller max. value for interpolation. The 2000 sec. from direct match, I mean that is more than half of an hour! Who knows later what happend in this period of time and whether interpolation still makes sense? If you really have such a time gap and don't know exactly how you moved, direct match would be the safer option. And we could enforce that a bit by limiting interpolation to, say, ten minutes or so (600 sec. of course). I imagine a pedestrian with this. If we talk about a car for ex. we are away from the max. values anyway. Cheers Wolfgang
On 07/03/17 23:02, Wolfgang Scheffner wrote: > https://bugs.kde.org/show_bug.cgi?id=377292 > > --- Comment #6 from Wolfgang Scheffner <wscheffner3@gmail.com> --- > Hi Simon, > > I'd rather start with 2) because that will deliver also the anwer to 1): > I agree that nearly always interpolation is the better, because more precise > option. The only where it is not is when you moved from one GPS point to the > next not straight but in a really bad curve (like helmet camera in a slalom > skiing race. Poor example, I know, too fast for GPS). If the amplitude of that > curve is bigger than the distance between the two points you might get a worse > result than with direct match. I don't think curving is an issue, there a direct match is just as bad as interpolation match. I tried to visualize my thoughts in a crude painting, not sure it adds anything: http://i.imgur.com/GaT6hDg.png. A problem is uneven movement. Say you linger long at point 1, then go fast to point 2 (same applies if you meander around 1 before going straight to 2). In that case direct match gives an accurate position during lingering and only for a short time (going quickly to 2) a wrong one, while interpolation is getting farther off the longer you linger at 1. That is why I consider a shorter limit on the direct match than on the interpolation a plausible scenario. > What you described under 1), interpolation being kind of a backup for direct > match, doesn't make sense to me as long as interpolation is considered the > better option anyway. And it would be everything else but intuitive. It would > really require a description within the GUI. And even with all the space I have > in the handbook it wouldn't be easy to explain (how it works yes, but what it > is good for ...?). That's what I am aiming at with doing interpolation: KISS. But that's not really digikam philosophy, so I am fine with making it a switch option between the two as you suggest below. I am in favour of making interpolation the default. > So I would still opt for the either - or solution and regarding the limits I > think it would even make sense to have a smaller max. value for interpolation. > The 2000 sec. from direct match, I mean that is more than half of an hour! Who > knows later what happend in this period of time and whether interpolation still > makes sense? If you really have such a time gap and don't know exactly how you > moved, direct match would be the safer option. And we could enforce that a bit > by limiting interpolation to, say, ten minutes or so (600 sec. of course). I > imagine a pedestrian with this. If we talk about a car for ex. we are away from > the max. values anyway. I think I misunderstood you. When I talk about max or limits, I was talking about the number entered by the user as max time between picture and track point. I never even considered that there is an upper bound on this number in the code. As explained in the first paragraph, I consider interpolation the long time option. Except for the uneven speed argument I can't think of a reason when interpolation is generally worse than direct matching. I can however imagine a (highly speculatory and probably unlikely) scenario where you only take track points every day (sailing?). In that case you want a limit of 1 day which is ridiculously big for most use cases, but I don't see why it shouldn't be valid. Or never mind I can think of one real scenario I had: In a group lots of people took pics, one person with a phone. On her pics there were therefore geotags, but they were very few. So you have a track with big gaps, meaning big time gaps to interpolate. > > Cheers > Wolfgang >
Simon, I think we got rather close meanwhile. I understand your arguments and what you want to tell me with your drawing. So if you make the switch thing, change the unit for interpolation to sec. and give both values a generous max. value I'm completely fine with that. I think the discussion shows that there are quite a few conceivable scenarios and think also different requirements regarding precision. In the handbook I would tell that to the users and say that in most cases interpolation is the better choice (which is pretty close to what I just sent to Gilles for commit). Thanks so far! Wolfgang
Git commit 2865e9325e73ff5ad408f197eb4576c583c2cf6f by Gilles Caulier, on behalf of Wolfgang Scheffner. Committed on 09/03/2017 at 09:17. Pushed by cgilles into branch 'master'. Apply patches #19, 20, 21 about geolocation editor handbook description Note : Screenshots for this section have been alreay commited previously. Only docbook files changes are included in this commit. M +4 -2 digikam/index.docbook M +186 -87 digikam/tool-geolocationeditor.docbook M +4 -0 digikam/using-mainwindow-intro.docbook M +5 -2 digikam/using-mainwindow-mapview.docbook M +19 -24 digikam/using-sidebar-maps.docbook M +2 -12 showfoto/index.docbook https://commits.kde.org/digikam-doc/2865e9325e73ff5ad408f197eb4576c583c2cf6f
Created attachment 104495 [details] Further simplify the dialogue http://i.imgur.com/TPvJ8A0.png As discussed this follow up patch now makes it a either-or selection between direct matching or interpolating. Also the offset business is simplified by providing one input for the offset instead of different switches including fine offset and timezones. All in all it is now less options for the same functionality.
Simon, I checked and patch look good. Let's go... Gilles
Git commit 8be6e433cd25c1ff2bc2eb6ad7a310fcdcf2bdbe by Simon Frei. Committed on 10/03/2017 at 21:03. Pushed by sfrei into branch 'master'. Simplify gps correlator interface M +106 -235 utilities/geolocation/editor/correlator/gpscorrelatorwidget.cpp M +1 -3 utilities/geolocation/editor/correlator/track_correlator.h M +42 -46 utilities/geolocation/editor/correlator/track_correlator_thread.cpp https://commits.kde.org/digikam/8be6e433cd25c1ff2bc2eb6ad7a310fcdcf2bdbe