GPS coordinate parsing

[Dirk Hohndel]

On Tue, 2013-12-24 at 15:18 -0200, Tomaz Canabrava wrote:
> can't we just round up / down?

We'd potentially lose precision. What I think I'll do is add code that
rounds up / down and then checks if the internal representation is still
the same. If it is, it uses the rounded value.

/D

> On Tue, Dec 24, 2013 at 3:06 PM, Dirk Hohndel <dirk at hohndel.org>
> wrote:
>         On Mon, 2013-12-23 at 15:14 -0800, Dirk Hohndel wrote:
>         > I just pushed a commit that attempts to improve the parsing
>         of GPS
>         > coordinates:
>         >
>         >     We used to only support full degrees and decimal
>         minutes. We now also
>         >     support fully decimal and degrees, minutes and decimal
>         seconds.
>         >
>         >     The previous implementation only accepted a decimal
>         point. We now support
>         >     both point and comma, regardless of locale.
>         >
>         >     The previous implementation would color the input field
>         red if either it
>         >     couldn't parse the string, or if it was able to parse it
>         but it was the
>         >     same as the previous location. That's misleading.
>         >
>         >     The previous implementation also changed all gps
>         coordinates to the new
>         >     coordinates in a multi-dive edit - instead of just
>         changing the ones that
>         >     are the same as the master dive.
>         >
>         > Since I am hoping to release 4.0.1 before the end of the
>         year I would
>         > really appreciate if people could beat on this change a bit.
>         Try the
>         > multi dive edit to make sure it makes sense (basically, if
>         several dives
>         > are at the same location, then changing the gps coordinates
>         should be
>         > tracked in all of them - but if they have different
>         locations, then this
>         > should only affect the selected dive). And please test the
>         parsing of
>         > the different GPS formats. Supported are
>         >
>         > N7° 16.29924' , E134° 14.74350'
>         > N7° 16' 17" , E134° 14' 44"
>         
>         
>         Turns out I never tested my own examples. All my tests had
>         decimals.
>         I just pushed another change that fixed that. But it shows
>         another
>         problem. If you enter these coordinates and hit save,
>         Subsurface then
>         shows a decimal version and you don't know if it's correct. If
>         you then
>         enter
>         
>         N7° 16' , E134° 14'
>         
>         that is also valid, but Subsurface returns
>         
>         N7° 16.00002' , E134° 13.99998'
>         
>         oops. The distance between those two values is minuscule. But
>         it looks
>         bad.
>         
>         /D
>         
>         
>         _______________________________________________
>         subsurface mailing list
>         subsurface at hohndel.org
>         http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>         
> 
>