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

[Marc MERLIN]

On Sun, Jul 06, 2014 at 06:58:10PM +0200, Salvador Cuñat wrote:
> Hi Marc.
> 
> On Thu, Jul 03, 2014 at 12:08:34PM -0700, Marc MERLIN wrote:
> > On Thu, Jun 26, 2014 at 12:36:26AM +0200, Salvador Cuñat wrote:
> > > 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? :)
> >
> 
> Better still, attached is a patch that I think solves the problem. It
> worked well on test positions and test dives, and also on real positions
> and dives of my own taken yesterday during a dive trip.
> 
> Would you be so kind of trying it on those yours that failed earlier?

Sure, I'll give that a shot, thanks.
But since I already have some incorrect points that were matched with my
dives, do I need to do something to delete them so that the newly computed
points replace them?
 
> > 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? :)
> 
> This would deserve a feature request in bug trak. Althoug this is
> somehow working via companion app importing GPX files capability.

Not entirely. If I have a GPX track with points every few seconds as part of
a track, the app will ignore them all and only use actual GPX waypoints.

Ideally it would look at the tracks for all the time/position combos and
pick the closest point, even if there are no GPX waypoints.

> There would be two problems there:
>
> 1.- The positions in GPX file need to be named or won't be parsed by
> companion or accepted by the server.

Exactly :)
So subsurface itself in the future could read a GPX track, find the nearest
point and create a waypoint internally that it can then send to the server.
Now I realize the app can't do this because it does not know when the dives
happened. 
However, subsurface knows :)

> 2.- The server is still working in time model hh:mm:00 (yes, zero
> seconds) so only accepts one position each minute. Yesterday companion
> fixed 6 or 7 positions each minute for me while in the boat, but the
> server seems to accept the first uploaded and companion is unable to
> upload the others in the minute (I thought I've filed a bug for this but
> I can't see it, I'll file another one).

That's not ideal, but with what I'm describing, this wouldn't be a problem,
although only if that GPX track parsing code is in subsurface.

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/