Enhancement/Complexity reduction: Shorten lat/lon values written to URLs and files

[GoogleCodeExporter]

A precision of 6 decimal places (DPs) in degree values corresponds to a 
location uncertainty of less than 0.1 meter (or 1/3 foot). (360 degrees = Earth 
circumference ~ 40000 km.)

Some output formats already use 5 DPs (<%out.(lon|lat)datapad5%>), 
corresponding to less than 1 meter which is still below GPS accuracy limits.

GeoToad currently writes 15 (!) DPs to e.g. GPX files, suggesting a higher 
accuracy than initially entered, as in lon="13.073550000000001".
This might result in similar issues as the over-precise timestamps caused to 
c:geo when importing GeoToad GPX.
It should be sufficient to limit coordinate values to 6 DPs, and prehaps even 
strip off trailing 0's, so the example above would become lon="13.073550" or 
even lon="13.07355".
I'd recommend at least one remaining DP, i.e. not shortening "13.00000000..." 
to "13." but "13.0".

The same procedure might be applied to the values inserted into gc search URLs, 
resulting in shorter file names in the GeoToad cache (see issue 200 why this 
matters).
Example: A search in Dublin (53.375,-6.250) currently does:
( o ) Coordinates "53.375 -6.250" parsed as latitude 53.3750000, longitude 
-6.2500000
( - ) 
http://www.geocaching.com/seek/nearest.aspx?lat=53.3750000&lng=-6.2500000&dist=4
.66
- The URL would become
      http://www.geocaching.com/seek/nearest.aspx?lat=53.375&lng=-6.25&dist=4.66
- do the character counting yourself.

Original issue reported on code.google.com by Steve8x8 on 4 Mar 2012 at 8:58

[GoogleCodeExporter]

As one can check easily, search tolerates coordinate values ending in a decimal 
point (dot). Nevertheless it won't harm to leave a ".0".
I'm hesitant wrt/ shortening coordinates for e.g. GPX files. At least my Oregon 
always writes 6 decimal places (the Nüvi does 8!). No stripping of trailing 0s.
geo-html2gpx apparently drops trailing 0s though, and I haven't heard of any 
complaints.
To play sufficiently safe:
- all <%wp.???data%> become <%out.???datapad6%>
- search arguments are cropped
but
- ???datapad6 doesn't get shortened
that's what now is in my branch.

I'd love to get more input concerning precisions in files, in particular in 
GPX, output or accepted by various programs and devices.

Original comment by Steve8x8 on 5 Mar 2012 at 2:01

• Changed state: Started

[GoogleCodeExporter]

Coordinates now have max. 6 decimal places (corresponding to sub-meter 
precision), and trailing 0's are safely removed in search URLs.

Original comment by Steve8x8 on 14 Mar 2012 at 1:52

• Changed state: Fixed