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

Thu Oct 3 17:49:31 BST 2013

Hi WanMil,

I also prefer to make sure that a correct img file is written.
I have just managed to produce a routing error with
the trunk version which disappears when using the mergeroads 
branch, even if I comment the call of mergeroads() .
Next step is to find out what is changed...

Gerd

WanMil wrote
>> 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
>>
> 
> Hi Gerd,
> 
> interesting idea to increase the precision of coordinates. I sometimes 
> thought about using "real" coordinates but using doubles instead of int 
> seemed to be too much memory overhead. Increasing the precision to 30 
> bits seems to be a much better way.
> 
> The crucial point is: does the higher precision really help?
> In the end you also have to convert the high precision coordinates to 
> the garmin precision. At this point I guess you will have the short arcs 
> problem again?
> Of course the calculation of the bearings will be better. But this will 
> not fix an img format problem (if that exist).
> So what about a systematic check the encodeCurve() method first?
> Would it be possible to create an map where all possible headings are 
> encoded? In this case it might be possible to find out problematic
> values?!
> 
> WanMil
> 
> 
> 
> 
> 
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev at .org

> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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