https://bugs.kde.org/show_bug.cgi?id=377292
--- Comment #7 from Simon <freisi...@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 <wscheffn...@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 watching all bug changes.
