[mkgmap-dev] higher precision instead of short-arc-removal?

Thu Oct 3 10:18:04 BST 2013

Hi programmers, 

I am still working on the improved short-arc-removal routines.
I found a few more special cases, and many of them are
related to the fact that we are using the rounded
lat/lon values (Garmin map units).

Short excurse:
A map unit is a 24bit integer value, means we can separate 2^24 = 16777216
different
positions on the equator.
By the way, the comment in Utils.toMapUnit
"A map unit is an integer value that is 1/(2^24) degrees of latitude or
longitue"
is wrong, we store 1/(2^23) of a value that goes from -180.0 to 180.0.

Means  ~ 2.39m (40075 km / 16777216) near the equator.
In Berlin, the value is ~ 1.45m for lon (lat is of course the same).
So, the rounding error is 0.75 to 1.2m in this area.
While these errors are not important when
it comes to rendering a map, they might be important
when it comes to routing.

In some cases I find segments of ways with two points that are very close.
Imagine a nearly vertical short segment. The rounding might move
one point to the left, the other to the right, so that (in map units)
with deltaLat = 1 and deltaLon = 1 the calculated bearing of ~ 148
is nonsense, as the real value is e.g 178.

If I got this right, the Garmin routing algo uses the
bearing value. We store it (heavily rounded to 8 or fewer bits),
and the comments in RouteArc.encodeCurve()
say that we are not sure about the img format.

I think this might also explain
why short arcs cause trouble, maybe it is not the
short arc itself, maybe we simply write wrong
data to the img when we store roads with
points that are very close to each other?

If that is true, we might better try to find 
out what we have to write to the img
instead of messing around with short arcs?

If only precision is the problem:
Maybe we can Coord to store the
lat/lon values with 30 bits precision?

Gerd

--
View this message in context: http://gis.19327.n5.nabble.com/higher-precision-instead-of-short-arc-removal-tp5779886.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.