Expand DMS format and fix sec rounding logic

[laigyu]

re:#5144

try to let 45°,90°0'0.5" display as 45°,90°0'1"

precision error explain:
if the sec input is 0.5 ,after calculating it will not equal 0.5 but 0.499999999829015,
my soloution is round it by 10e-8 to fix it to 0.5
and do the origin display round 0.5=>1

new format
|35 11 10.1 , 136 49 53.8|| D M SS|
|35 11.168 , 136 49.896||D MM|

zoom center loc always use the user input ,
dont matter how display rounding and show,
always center correct.

[1ec5]

Thanks! This is looking pretty good at a glance. Perhaps some tests would be a good idea, since there are several edge cases when we do the rounding manually.

[tyrasd]

Could you please explain the rationale behind adding the additional decimal precision? IMHO, the resolution of the single minutes is already far sufficient for the intended use case (i.e. navigating to a specified location). 0.1 seconds would only translate to a few additional pixels on the screen… A small negative side effect of showing the decimal is that in some locales (e.g. German) this would introduce the output of a decimal comma in the displayed coordinate which would not be supported as a valid input in the search box (e.g. 12°N, 12°3'4,5"W).

Are the D M SS / D MM formats really found in practice? I guess it would not hurt to support it additionally for convenience (e.g. when copy-pasting from spreadsheets/csv files with dedicated columns for each coordinate part). I'd agree that it would be required to add some unit tests for these routines. And maybe also add support for it with N/S and E/W suffixes in that format (e.g. 45 0 18 N, 90 19 0 W)?

[tyrasd]

Thanks for the additional test cases!