fix(geometries): Fix missing precision in WKT coordinates

[saibotk]

We missed the "." here and thus PHP formatted numbers with the default precision of 6 and prefixed it with whitespaces.
See PHP docs: https://www.php.net/manual/en/function.sprintf.php

This has been addressed by using the json_encode function to print the
float. This function uses PHP's serialize_precision instead, which
by default uses a similar algorithm to the one PostGIS uses for
printing out the float in a minimal representation and also
allows to print out at the maximum precision, as long as the
user did not change the serialization precision config.

Thanks @ronnypolloqueri for reporting this. (ref #72)

[ahawlitschek]

LGTM

[saibotk]

@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.
So i'd love to mirror this behaviour.

[saibotk]

Okay update:

Seems like PostGIS handles them the same way internally:

Or TablePlus is rounding those idk

But it's still weird and we should adjust our WKT generator to try to output the same strings as PostGIS does.
This part might be useful form PostGIS codebase, which takes care of printing the decimal: https://github.com/postgis/postgis/blob/5560fb5cd14162a2d170a464f9e2b13e8998b1f7/deps/ryu/d2s.c#L537