Looks good and tests are passing on my machine. Any idea why they're failing on Travis: https://travis-ci.org/grimzy/laravel-mysql-spatial/builds/657630242 ?

i have changed MAX_FRACTION_DIGITS from -1 to 12. reason to choose twelve:

Captura de Tela 2020年03月03日 às 07 20 31

all green! cc @grimzy
https://travis-ci.org/grimzy/laravel-mysql-spatial/builds/657701072

I've delayed merging this PR because adding ext-intl would most likely break builds if I release a minor. I also want to avoid releasing a major and replacing a comma felt like a quick-fix (i18n-wise).

I'm going to test this out real quick: https://github.com/symfony/polyfill-intl-icu. It's already loaded when you build Laravel. This package adds ext-intl in composer's suggest and will use the PHP extension if it's already installed on the server.

Thanks for fixing the tests.
I'm wondering if we're losing accuracy. Easy to test.
In any case, it doesn't seem that PHP compares floats past the 11th decimal either: https://github.com/grimzy/laravel-mysql-spatial/blob/2.2.0/tests/Integration/SpatialTest.php#L351 so we should be safe with 12 numbers after the decimal separator.

With symfony/polyfill-intl-icu: https://github.com/grimzy/laravel-mysql-spatial/tree/fix/locale-polyfill

Edit: easier to see the changes in a PR: #126

@grimzy This week I came across a MySQL error "Invalid GIS data provided" and ultimately tracked it down to my locale rendering floats with a comma when converted to strings. Then I just saw this issue, where the bug was presumably fixed. I am on version 4.0.0.

Is the fix still pending merge? Or is this a new issue?