[digikam] [Bug 377292] Improve GPS Correlator UI

Simon bugzilla_noreply at kde.org
Tue Mar 7 22:31:39 GMT 2017


https://bugs.kde.org/show_bug.cgi?id=377292

--- Comment #7 from Simon <freisim93 at gmail.com> ---
On 07/03/17 23:02, Wolfgang Scheffner wrote:
> https://bugs.kde.org/show_bug.cgi?id=377292
>
> --- Comment #6 from Wolfgang Scheffner <wscheffner3 at 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
>

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Digikam-devel mailing list