[mkgmap-dev] [Patch v1] differet Coord implementation

Tue Mar 14 15:30:55 GMT 2017

Hi Ticker,

I waited for further feedback from you. Please post your modified version or a patch.

Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Dienstag, 14. März 2017 10:53:43
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] [Patch v1]  differet Coord implementation

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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev