fix: prevent wrong formatting float values by locale

[gpedro]

resolves #84
that's the right-way fix. but to avoid install ext-intl, we can just replace comma by a dot.

[grimzy]

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 ?

[gpedro]

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

[gpedro]

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

[grimzy]

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.

[grimzy]

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.

[grimzy]

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

[monkeyphysics]

@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?