In principle the idea sounds good.

How is it parsing the numbers? is it locale agnostic? I think it is not, because it is using "strtod". That means that if I have my locale in Spanish, French, German, ... it will expect "," as the decimal separator, right?
if running under a non-C locale, and without modification, yes
... well, how is GDAL expecting floating values?

Only if the utilities enables setlocale(LC_ALL, ""), which they don't by default. That said as the command line utility parsing is also used for the utility-as-C-function, we may run under a non-C locale (that is a Spanish/French/whatever locale) in some contexts.

Is GDAL locale agnostic?
Grep'ping I see that we use both CPLAtof() which is locale-agnostic and assume dot as decimal separator or CPLAtofM() which accept dot or comma as decimal separator. I don't think there is a particular reason in using any of them. Inconsistency likely due to doing the work manually and depending on the mood of the developer. Not totally sure of the behavior we want: should we always require dot as the decimal separator, or be lenient and accept both dot and comma (wondering if there wouldn't be situations where we would take a "a,b,c" string, with a, b, c being floating point numbers, in which case obviously we would have to require dot. But I'm not sure if that can happen)

Do you want to add it as a dependency, or just copy-paste the header file into gdal repo?

yes, copy-paste and potentially with a few changes for our needs, like using CPLAtof or CPLAtofM.


--
http://www.spatialys.com
My software is free, but my time generally not.

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to