From: John R. <jr...@ce...> - 2013-09-04 18:52:24
|
On Sep 4, 2013, at 11:26 AM, Vassilii Khachaturov <vas...@ta...> wrote: > On 04.09.2013 21:18, Doug Blank wrote: >> On Wed, Sep 4, 2013 at 1:42 PM, Nick Hall <nic...@ho...> wrote: >>> Devs, >>> >>> A possible validation problem has been revealed by running the unit >>> tests. >> Great! That is what they are good for. Great job to all of those who >> are getting the unit tests up and running! >> >>> Latitudes and longitudes will degrees and seconds only fail >>> validation when the value entered for seconds is not an integer. 1# 2" >>> N passes, but 1# 2.3" N fails. >>> >>> Should we allow the user to enter degrees and seconds without minutes? >>> >>> I also notice that 1:2 passes, 120˚but 1:2.3 fails. >>> >>> Should we allow degrees with decimal minutes in colon representation? >> We should probably pick a standard and go with whatever it indicates. >> >> We may want to treat long/lat as we treat dates: parse and fail >> quietly, giving a UI indication that it is invalid. >> > I think we should allow decimal point there, this is great for paper (or > scanned) map scenarios. Decimal seconds absolutely. A second of latitude is almost 31 meters, and GPS is accurate to better than 1/10th of that. Decimal minutes would be weird, but it's probably simpler in code to parse them the same way seconds are done, as well as computationally safer to have everything a float during conversion to the internal representation. Missing minutes (e.g. 120˚ 31.3") should be treated as (120˚ 0' 31.3"). Regards, John Ralls |