Subsurface isn't matching my last 4 dives from the service
salvador.cunat at gmail.com
Wed Jun 25 15:36:26 PDT 2014
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
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.
> 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.
More information about the subsurface