Bug #6110
KML export is generating decimal separators depending on system locale
| Status: | Feedback | Start Date: | 07/27/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | Vectors | |||
| Target version: | Version 2.0.0 | |||
| Platform: | Patch supplied: | No | ||
| Platform version: | Affected version: | master | ||
| Status info: | Causes crash or corruption: | No | ||
| Resolution: |
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.
History
Updated by Giovanni Manghi 10 months ago
- Category set to Vectors
- Status changed from New to Feedback
- Priority changed from Blocker 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.
Updated by Rodrigo Hjort 10 months 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
Updated by Giovanni Manghi 10 months ago
- Status changed from Feedback to New
- Target version set to Version 2.0.0
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@
Updated by Jürgen Fischer 10 months 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?
Updated by rouault - 10 months 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
Updated by Giovanni Manghi 10 months ago
- Status changed from New to Feedback