Subsurface isn't matching my last 4 dives from the service

[Marc MERLIN]

On Thu, Jun 26, 2014 at 12:36:26AM +0200, Salvador Cuñat wrote:
> Good night Marc.
> 
> Thanks for testing my patch.
> 
> On Tue, Jun 24, 2014 at 06:37:45PM -0700, Marc MERLIN wrote:
> > The last dive (379) shows a proper location.
> >
> I think this has been absolutely casual.
> 
> I've been running some tests in the same line of your numbers, and It seems
> (to me) that the logic applied on merge_locations_into_dives() function is
> quite wrong.
> 
> I see two failures in actual implementation:
> 
> 1.- The one corrected by the patch (the first condition goes nowhere if
> the position fix is not in the diving period range)
> 
> 2.- The second part which starts when first condition fails, relays on
> find_dive_n_near() helper and simply applies the dives to the position
> fixes secuentially, and do weird things when dive times and (specially)
> position fixes times reach the six hour difference with the first time
> fixed. This is not trivial.

Do you have a new bug filed for this, or are you able to file one, or
would you like me to file one? :)

> > Also, if I feed better points via a GPX track, will they override the
> > bad points?
> 
> I don't think so. The logic depends on matching position fix time with
> dive time, you would need to have times in the GPX track that match
> somehow the times of the DC.

That's the whole point of a GPX track. A track has multiple points per
minute and can often have 10K points in a single track.
The current code in subsurface doesn't parse tracks, but if it did (and
it could borrow code from exiftool or gpsphoto as given in my previous
Email), it could find a point that within a few seconds and even log
where you dive started and where it ended for a drift dive.

Wouldn't that be cool? :)

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901