Bug report #6110

KML export is generating decimal separators depending on system locale

Added by Rodrigo Hjort over 11 years ago. Updated about 8 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Vectors
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:worksforme
Crashes QGIS or corrupts data:No Copied to github as #:15452

Description

I'm using Quantum GIS on Linux with locales set to pt-BR (Brazilian Portuguese).

When I export to KML, it produces coordinates using "," decimal separator (according to pt-BR regionalization rules):

<MultiGeometry><Polygon><outerBoundaryIs><LinearRing><coordinates>-51,09189516,0,01566702 -51,091517879999998,0,01681002 -51,090230267830101,0,01554286575332 -51,089511609343091,0,014835625502677 -51,089524844693898,0,014785154452175 -51,089621934159901,0,014414918150888 -51,089695920000004,0,01413396 -51,090616079999997,0,01472103 -51,091445940477001,0,015334783410788 -51,09189516,0,01566702</coordinates></LinearRing></outerBoundaryIs></Polygon></MultiGeometry>

When I call Quantum GIS setting locales to en-US (i.e., by issuing "LC_ALL=C qgis"), proper values are set on KML file (by using "." and not "," as decimal separators):

<MultiGeometry><Polygon><outerBoundaryIs><LinearRing><coordinates>-51.09189516,0.01566702 -51.091517879999998,0.01681002 -51.090230267830101,0.01554286575332 -51.089511609343091,0.014835625502677 -51.089524844693898,0.014785154452175 -51.089621934159901,0.014414918150888 -51.089695919999997,0.01413396 -51.090616079999997,0.01472103 -51.091445940477001,0.015334783410789 -51.09189516,0.01566702</coordinates></LinearRing></outerBoundaryIs></Polygon></MultiGeometry>

In order to generate KML files, current system locale should be ignored.

test_polygons.zip (3.47 KB) François-Xavier Thomas, 2014-05-28 02:29 AM

Related issues

Related to QGIS Application - Bug report #8332: QGIS uses comma as decimal separator for shapefile attrib... Closed 2013-07-20

History

#1 Updated by Giovanni Manghi over 11 years ago

  • Category set to Vectors
  • Status changed from Open to Feedback
  • Priority changed from Severe/Regression to Normal

Tickets are tagged as blockers only if are regressions. Is this a regression since 1.7.4 (are you using 1.8, right?)?

Did you tested make the conversion using the ogr2ogr cli tool? I'm not sure QGIS uses it to do this particular conversion, but if the issue surface also with ogr2ogr it may be not a qgis issue.

#2 Updated by Rodrigo Hjort over 11 years ago

Giovanni Manghi wrote:

Tickets are tagged as blockers only if are regressions. Is this a regression since 1.7.4 (are you using 1.8, right?)?

I don't know. Yes, I'm on 1.8.0.

Did you tested make the conversion using the ogr2ogr cli tool? I'm not sure QGIS uses it to do this particular conversion, but if the issue surface also with ogr2ogr it may be not a qgis issue.

I've just tested ogr2ogr as you suggested. It generates proper KML files regardless the locales I set. All instructions below give binarily the same KML files:

ogr2ogr -f KML censo-ap1.kml 16SEE250GC_SIR.shp
LC_ALL=C ogr2ogr -f KML censo-ap2.kml 16SEE250GC_SIR.shp
LC_ALL=pt_BR.UTF-8 ogr2ogr -f KML censo-ap3.kml 16SEE250GC_SIR.shp

#3 Updated by Giovanni Manghi over 11 years ago

  • Target version set to Version 2.0.0
  • Status changed from Feedback to Open

then is a qgis issue.

I've just tested ogr2ogr as you suggested. It generates proper KML files regardless the locales I set. All instructions below give binarily the same KML files:

ogr2ogr -f KML censo-ap1.kml 16SEE250GC_SIR.shp
LC_ALL=C ogr2ogr -f KML censo-ap2.kml 16SEE250GC_SIR.shp
LC_ALL=pt_BR.UTF-8 ogr2ogr -f KML censo-ap3.kml 16SEE250GC_SIR.shp

#4 Updated by Jürgen Fischer over 11 years ago

Rodrigo Hjort wrote:

I don't know. Yes, I'm on 1.8.0.

Not reproducable here. What's your platform and GDAL version?

#5 Updated by Even Rouault over 11 years ago

LC_ALL=C ogr2ogr -f KML censo-ap2.kml 16SEE250GC_SIR.shp
LC_ALL=pt_BR.UTF-8 ogr2ogr -f KML censo-ap3.kml 16SEE250GC_SIR.shp@

Setting LC_ALL isn't sufficient, as by default GDAL utilities will not call setlocale(), so it will not be taken into account.

So you should try : "ogr2ogr -f KML censo-ap3.kml 16SEE250GC_SIR.shp --locale pt_BR.UTF-8"

With recent GDAL versions (1.9 at least, perhaps older too), the code that exports the coordinates for KML, GML, WKT will replace the comma by decimal point.

Note: there might be still issues with decimal points and non-C locale in other parts of GDAL/OGR however. Export of real values in DBF for example is known to be broken with non-C locale ( http://trac.osgeo.org/gdal/ticket/4713 )

Note 2: I've just discovered that a bug in in proj 4.7 hides some locale related problems, because it installs the C locale temporarily, but fails to restore the original locale properly. This has been fixed in proj 4.8 that restores properly the original locale, and now some locale related problems surface again

#6 Updated by Giovanni Manghi over 11 years ago

  • Status changed from Open to Feedback

#7 Updated by Jürgen Fischer almost 11 years ago

  • Resolution set to worksforme
  • Status changed from Feedback to Closed

closed for the lack of feedback.

#8 Updated by François-Xavier Thomas almost 10 years ago

  • File test_polygons.zip added
  • Status changed from Closed to Reopened
  • Target version changed from Version 2.0.0 to Version 2.2

I'm facing the exact same issue with QGIS 2.2 under Ubuntu 12.04. locale output on my system :

LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE=fr_FR.UTF-8
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

Attached is a sample shapefile created from QGIS under the system locale, and its KML conversion from :

  • QGIS using the system locale
  • QGIS started using the LC_NUMERIC="C" /usr/bin/qgis command
  • The ogr2ogr command from GDAL

Both GDAL and QGIS under the C locale output a valid KML file, but QGIS using the system locale does not and uses comma as decimal separators.

Additionally, for some reason which might be related, QGIS is unable to display the shapefile (not the KML file!) if opened under the system locale, but displays it perfectly well under the C locale. As far as I can tell, even though it was created under a french locale, the shapefile is valid, i.e. GDAL can open it under any locale.

(It's the first time I'm around here, so forgive me if I shouldn't have reopened the ticket but created a new one instead)

#9 Updated by Jürgen Fischer almost 10 years ago

  • Target version changed from Version 2.2 to Future Release - Lower Priority

#10 Updated by Andrey Isakov over 9 years ago

Same issue for me under Debian testing.
QGIS 2.4.0-Chugiak
Compiled against GDAL/OGR 1.10.1 Running against GDAL/OGR 1.10.1

andrey@crt-s1:~$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8" 
LC_NUMERIC=ru_RU.utf8
LC_TIME=ru_RU.utf8
LC_COLLATE="en_US.UTF-8" 
LC_MONETARY=ru_RU.utf8
LC_MESSAGES="en_US.UTF-8" 
LC_PAPER=ru_RU.utf8
LC_NAME="en_US.UTF-8" 
LC_ADDRESS="en_US.UTF-8" 
LC_TELEPHONE="en_US.UTF-8" 
LC_MEASUREMENT=ru_RU.utf8
LC_IDENTIFICATION="en_US.UTF-8" 
LC_ALL=

Related issue #8332

#11 Updated by Jürgen Fischer about 8 years ago

  • Status changed from Reopened to Feedback

Andrey Isakov wrote:

Same issue for me under Debian testing.
QGIS 2.4.0-Chugiak
Compiled against GDAL/OGR 1.10.1 Running against GDAL/OGR 1.10.1
[...]

Related issue #8332

odd, still doesn't happen for me. fr_Fr, lv_LV, de_DE - all fine on unstable using GDAL/OGR 1.11.3.

#12 Updated by Giovanni Manghi about 8 years ago

  • Status changed from Feedback to Closed

odd, still doesn't happen for me. fr_Fr, lv_LV, de_DE - all fine on unstable using GDAL/OGR 1.11.3.

closing for lack of feedback. Please reopen if necessary.

Also available in: Atom PDF