Unexpected values with "geocoding: mapbox"

[marcomezzavilla]

First of all thank you for this wonderful plugin.

I'm not sure this is really an issue, but by setting geocoding: mapbox the latitude and longitude values are returned by the toLocation method with a comma and not with a dot.

Nominatim: <?= $location->lat() ?> // 41.894802

Mapbox: <?= $location->lat() ?> // 41,894802

This difference can cause some problems in the frontend implementation of the map.

—

In the content folder the values lat and lon are stored differently between mapbox and nominatim.

Nominatim geocoding:

Map: 

lat: "41.894802"
lon: "12.4853384"
city: Roma
country: Italia

Mapbox geocoding:

Map: 

lat: 41.894802
lon: 12.4853384
city: Roma
country: Italia

[iskrisis]

Hi @marcomezzavilla so the issue you are getting has to do with you language settings. You probably have set language that uses with comma "," instead of period "." in floats - php is trying to be smart here and echoes your localized float string.

In Nomatim the lat/lon are stored as a string and php believes it is a string where as in Mapbox they are stored as number and kirby converts it to php float type. I am not sure what is right approach here i think the mapbox way (let kirby cast the yaml string to number so you can do php calculation straight away). But this should be same and is probably a bug.

Going from string -> cast the "41.894802" to float like (float) "41.894802";

Other way around -> change language for numbers. Globally you would do it https://getkirby.com/docs/guide/languages/introduction#detailed-locale-settings here and set LC_NUMERIC to something like 'en_US.utf8' (unfortunately you need to update kirby to have that work https://github.com/getkirby/kirby/pull/1668).

Other solution is locally use number_format() - https://www.php.net/manual/en/function.number-format.php which is probably what you want if you just need for the mapservice.

[marcomezzavilla]

Thank you very much for your detailed reply!

[iskrisis]

I would not close this yet. There is indeed mismatch in how those two options save the coordinates differently wich @sylvainjule im sure does not want (i am also sure it is very small bugfix).