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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 21. Februar 2017 18:44:35 An: mkgmap-dev@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev