fix(geometries): Fix stringifyFloat to correctly format number #73
Conversation
We missed the "." here and thus PHP formatted numbers with the default precision of 6 and prefixed it with whitespaces. Additionally the trims were adjusted, as we now do not need to trim any whitespaces. Also the trimming for the "." was made a rtrim instead to avoid wrongly stripping `.1` to `1`, even though this should never be a possible value that sprintf would produce. See PHP docs: https://www.php.net/manual/en/function.sprintf.php Thanks @ronnypolloqueri for reporting this.
|
@ahawlitschek I'm unsure whether we should fix it like this and get cases where the numbers are "more" precise, but for some is more imprecise, see the tests for example. Or we may fix this in a different way, maybe check out how postgis / geos does it under the hood. Also i just saw that maybe such imprecision could cause invalid geometries, at least according to ST_AsText, when setting precision there a warning exists about that: https://postgis.net/docs/ST_AsText.html And PostGis seems to handle the value 50.12345 from the test cases perfectly. |
|
Okay update: Seems like PostGIS handles them the same way internally: But it's still weird and we should adjust our WKT generator to try to output the same strings as PostGIS does. |
We missed the "." here and thus PHP formatted numbers with the default precision of 6 and prefixed it with whitespaces.
Additionally the trims were adjusted, as we now do not need to trim any whitespaces. Also the trimming for the "." was made a rtrim instead to avoid wrongly stripping
.1to1, even though this should never be a possible value that sprintf would produce.See PHP docs: https://www.php.net/manual/en/function.sprintf.php
Thanks @ronnypolloqueri for reporting this. (ref #72)