GPS coordinate parsing
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
> 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
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
More information about the subsurface