[Patch v1] differet Coord implementation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Patch v1] differet Coord implementation

Gerd Petermann
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

diff_coord_v1.patch (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch v1] differet Coord implementation

Ticker Berkin
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch v1] differet Coord implementation

Gerd Petermann
Hi Ticker,

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

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Dienstag, 14. März 2017 10:53:43
An: [hidden email]
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch v1] differet Coord implementation

Ticker Berkin-2
Hi Gerd

Here is combined patch based on current trunk.

I haven't been through WrongAngleFixer in any detail yet.

Ticker


On Tue, 2017-03-14 at 15:30 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I waited for further feedback from you. Please post your modified
> version or a patch.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Dienstag, 14. März 2017 10:53:43
> An: [hidden email]
> 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
> > [hidden email]
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

diff_coord_v3.patch (19K) Download Attachment
Loading...