GPS coordinate parsing

Dirk Hohndel dirk at hohndel.org
Tue Dec 24 09:06:22 UTC 2013


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




More information about the subsurface mailing list