[mkgmap-dev] RE Commit r3801: merge split-shape branch

Sun Feb 26 08:31:29 GMT 2017

Hi Ticker,

good to see that the code in WrongAngleFixer is reviewed. I am sure it can be improved.
Just keep in mind that it sometimes finds out that it is better to place the "moved" point
on top of another. If this happens with routing nodes you need a way to calculate the bearing
values "between" these points. If you decide to remove the information from the coords
you probably have to store it in the way.

Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Samstag, 25. Februar 2017 18:17:37
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi Gerd

Sorry about the delay in replying. Thoughts on some of this.

Assuming the MapRes and highRes are related by powers of 2, and all the
rounding is done consistently, there should never be any difference
between going via highRes to get from the original doubleFloat value to
a MapRes value.

The most consistent rounding in mkgmap code is to the closest whole
number with x.50000 rounding up towards plus infinity.
This is also the definition of Math.round().

So, it would be much clearer and have the same effect if
 old:imgFmt.Utils.toMapUnit
 new:Coord.toHighPrec
were re-coded as
  return Math.round(degrees / 360.0D * (1 << resolution))

Other cases of rounding should be checked - esp. Utils.roundup()),
which I thought was wrong, but looking again seems OK.
This effects how the base Lat/Lon for a subdivision is held - should be
a correctly rounded value.

In the new versions of Coord.getLatitude/Longitude(), could have/use
final int DELTA_HALF = 1 << (DELTA_SHIFT - 1);

I'm still studying the wrongAngleFixer/AlternativePos/DisplayedCoord
stuff, but getting a little bit lost as to when need to keep the all
the flags in the copy of the Coord and when not (ie getDisplayedCoord
loses all the flags and highPrec info) and what is taken into account
for the distance() function

I have this feeling that Coord shouldn't have all this INC/DEC_LAT/LON
stuff but wrongAngleFixer just make up an adjacent Coord if it does a
better job

Ticker

On Fri, 2017-02-24 at 10:54 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> okay, here are my findings so far:
> 1) We assume that the double values read from OSM or polist (*.mp)
> format are precise
> 2) The code in the Coord class tries to reduce rounding errors. It
> calculates both the 24 values AND the high prec values
> from the given doubles. An alternative would be to calculate only the
> high prec values from the doubles and then
> calculate the 24 bit values by shifting, but that would in fact mean
> that the value is rounded two times. In some edge cases
> you will get different 24 values doing this. The delta values are
> stored in the Coord instance and for 30 bits precision
> they are -32 <= delta < 32.
> The picture grid1 shows some OSM elements and the Garmin Grid (24 bit
> resolution):
> http://files.mkgmap.org.uk/download/335/grid1.png
> and what the "normal" rounding does (note the zig-zagging rails)
> http://files.mkgmap.org.uk/download/336/grid2.png
>
> 3) The method Coord.getAlternativePositions() called by
> WrongAngleFixer introduces some additional problems:
> It creates Coord instances where the delta values can be up to 63 (
> -63 <= delta < 63). This sounds much, but it only happens for OSM
> nodes
> which are far from any Garmin grid point. Imagine that an OSM node
> lies exactly in the center of four Garmin grid points.
> All four would have the same rounding error, but the distance between
> them can be ~2.3 m.
> Which of the four Garmin points should be returned by the
> Coord.getDisplayedCoord() method?
> For a single POI like a natural=peak it doesn't really matter, but
> for a node which is part of a roundabout or a railway=rail
> you want to get the point which "looks" better. A human knows by
> experience that rails are not zig-zagging, so
> the goal of the WrongAngleFixer is find the Garmin point which causes
> the smallest errors in the angles.
> This is not only done for points which lie exactly in the center of
> Garmin grid points, but for all which are not close to one such
> point.
> The WrongAngleFixer uses a iterative try-error approach to find those
> nodes which should be "moved", and it needs to know the
> "original" position. I found no performant way to implement that with
> hashmaps, so I decided to code what we have now.
> The improved result looks like this:
> http://files.mkgmap.org.uk/download/337/grid3.png
>
> Later in the data flow the routines for the road network also need to
> know the real positions when they calculate the bearing values.
>
> In short: I found no better solution, it works quite well but one has
> to think twice if he needs the Garmin position or the high prec (OSM)
> position.
>
> Worth noting is that the WrongAngleFixer is called for lines and
> shapes, but at different stages.
> For lines (and roads), it is called  before MapLine instances are
> created. For shapes, it is called by the ShapeMergeFilter
> which is called after all the sub division splitting happened.
> That means In the current code (r3820), the ShapeSplitter doesn't
> have to care about "moved" points in shapes.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Gerd Petermann <GPetermann_muenchen at hotmail.com>
> Gesendet: Dienstag, 21. Februar 2017 20:01:06
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Ticker,
>
> okay, I'll try to find out (again) why I decided to do the move only
> in low-prec. I know that I was not happy with that, but I forgot the
> reason. I think one was that the WrongAngleFixer started to move
> points too far. Anyway, I should fix this first.
>
> I started to go for 32 bits because some algos which I coded for JOSM
> use this res. It seemed easier to change mkgmap to
> also use 32 bits, but I am no longer sure about that.
>
> 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, 21. Februar 2017 18:44:35
> An: mkgmap-dev at lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi
>
> According to my calcs, full 32 bit integers give a resolution of
> about
> 10mm at the equator. Why do you need better than existing high-res
> (30
> bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem.
>
> Not to have the resolution as a powerOfTwo of the garmin map unit
> would
> require a lot of changes throughout the code and a run-time cost.
>
> Manipulating high-res deltas such that the rounded values diverges
> from
> the the std lat/long value seems very wrong (is this what it does, or
> does it simply change one but not the other). Maybe wrong-angle stuff
> should be looked at to see if there is a better way. This is an area
> I've never been near.
>
> Would be great if Area/bounds and Coord used the same (high-prec)
> units
> and there was no ambiguity about contains().
>
> Ticker
>
>
>
>
> _______________________________________________
> 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
> _______________________________________________
> 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