Bug report #10876
Broken non-latin text attributes when doing Shapefile import in GRASS (v.in.ogr)
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | GRASS | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | wontfix |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 19244 |
Description
When doing Shapefile import in GRASS (module v.in.ogr), all non-latin (cyrillic) text attributes appear to be broken.
Further export using v.out.ogr produces shapefile with broken attribute text due to the already broken import.
This kind of behavior seems to be introduced in QGIS 2.2.0 and persists in QGIS 2.4.0.
The same behavior is NOT observed in QGIS-OSGeo4W-1.8.0-1.
A temporary workaround is to install QGIS-OSGeo4W-1.8.0-1 and use this one just to import the shapefile in DB as further processing can be done using the latter versions.
Issue classified as 'Blocker' because shapefile workflow with non-latin data seems to be completely compromised.
History
#1
Updated by Giovanni Manghi over 10 years ago
- Target version deleted (
Future Release - High Priority) - Category changed from GDAL Tools to GRASS
#2
Updated by Giovanni Manghi about 10 years ago
- Status changed from Open to Feedback
- Priority changed from Severe/Regression to Normal
- Affected QGIS version changed from 2.4.0 to master
I cannot confirm that qgis 1.8 wasn't affected, I just tested on it and I see the same behavior.
I'm on an en_EN operating system and steps to make things work are pretty easy:
open the shape, give it the proper encoding (I used "Cyrillic") and re-save it giving the copy the UTF8 encoding. Then importing the utf8 copy into a GRASS location/mapset is ok.
#3
Updated by Giovanni Manghi almost 9 years ago
- Resolution set to wontfix
- Status changed from Feedback to Closed
closing this because anyway there is no evidence that importing the same vector with native GRASS you get a better result. Anyway the suggested workaround is ok, and will lead you to correctly encoded attributes in the GRASS vector layer.