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
> [email protected]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
