Closed Fischerfredl closed 2 months ago
The thing is: You cannot produce floating point numbers of a specific precision, there is always some addition inaccuracies guaranteed by the representation (even without additions). E.g. it is impossible to represent 0.3 with or without additions. The only way to get rid of that is converting to fixed-point / integers.
That being said: The implementation should actually delay the division after it has added up the delta. The delta-sum should not contain accumulated/addition division error.
A PR is created to fix the precision loss and/or accumulated division error by delaying the devision after sum of coordinates as suggested by @VeaaC https://github.com/heremaps/flexible-polyline/pull/84
Hi all,
we use a copied version of https://github.com/heremaps/flexible-polyline/blob/master/javascript/index.js in our codebase and I just noticed that the decode function returns higher precision values than expected (more decimal places). I guess this happens due to the assumption that adding two numbers of a certain order won't generate a lower order. But this is not true for IEEE 754 Floating-Point Arithmetic. Classic example:
I stumbled upon this as another library (polygon-clipping) was generating erroneous MultiPolygons when it was fed Polygons with the high precision. The following patch fixed this for us:
This works for us as we only read Polylines from a third party API (HERE Isoline API) but I don't know if this is sufficient for a encoding/decoding setting. Maybe one should truncate the lastLat/lastLng/lastZ as you go for performance.
I just wanted to leave this here for a heads up if anyone stumbles upon a similar error.