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

Tue Feb 21 19:01:06 GMT 2017

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