Hi Gerd Are you still planning to implement this patch. I've been using it for a while with some additional changes and I didn't have any problems. I think it is tidier and makes things more obvious. The addition changes I had were roughly as I listed in a follow-up: ... much clearer and have the same effect if imgFmt.Utils.toMapUnit new:Coord.toHighPrec were re-coded as return Math.round(degrees / 360.0D * (1 << resolution)) imgfmt.Utils.roundup()) change to rounding to nearest integer rather than being like ceiling(): public static int roundUp(int val, int shift) { if (shift <= 0) return val; return (((val >> (shift-1)) + 1) >> 1) << shift; } In the new versions of Coord.getLatitude/Longitude(), could have/use final int DELTA_HALF = 1 << (DELTA_SHIFT - 1); ... public int getLatitude() { int lat24 = (latHp + DELTA_HALF) >> DELTA_SHIFT; ... public int getLongitude() { int lon24; if (HIGH_PREC_BITS == 32 && lonHp == Integer.MAX_VALUE) lon24 = (lonHp >> DELTA_SHIFT) + 1; else lon24 = (lonHp + DELTA_HALF) >> DELTA_SHIFT; ... Ticker On Fri, 2017-02-24 at 15:27 +0000, Gerd Petermann wrote:
Hi programmers,
After writing my findings here http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026317.html I did some cycling and decided that I might still be better to use the attached patch.
It works better with 32 bits and is probably a bit easier to understand. The major difference is that it calculates the Garmin position of a point from the already rounded 30 (or 32 bit) value. In some cases this means that points in the map move by one, e.g. one with 52.2452629, 21.0833536
appears on the right grid point instead of the left (it is very close to the middle).
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev