Tag Info

Hot answers tagged

11

Assuming that you are on Linux and have access to a recent version of GDAL you can try the following (from this post) : export SHAPE_ENCODING="ISO-8859-1" ogr2ogr output.shp input -lco ENCODING=UTF-8 Note: LATIN1 should work too instead of ISO-8859-1. In Windows, do NOT set the SHAPE_ENCODING, ogr2ogr does not recognize ISO-8859-1, nor LATIN1.


11

You can do this with QGIS. First load your shapefiles then save as and coding select dropdown menu utf-8 and then save your file.


7

try opening the dbase-file with libreoffice (or openoffice) and try different encodings, if utf-8 doesnot work try iso-8859-1 and look if the chars öäüß are displayed correctly


6

As Jason pointed out you've got a mismatch between the character set of the data and the character set of locator. It's probably the geodb that doesn't match the data and vice versa. Make sure the geodb is in UTF-8. If you want to retain the accented characters and still get 100% match with the unaccented spellings, store unaccented versions of the names in ...


6

That isn't garbage, that's UTF-8 being displayed as CP1252. This Stackoverflow topic may help you on your way, as may this one (if you're in Python).


4

There is something fundamentally wrong with GDAL's shapefile encoding detection feature. In latest QGIS 1.9 builds, you can ignore GDAL's shapefile encoding by going into the Options window and checking the [ ] Ignore shapefile encoding. You can then set the correct encoding in the layer property window. See ...


4

Yes, you can use UTF-8 characters in shapefile attributes. The document (http://support.esri.com/en/knowledgebase/techarticles/detail/21106) explains it in detail.


3

87 (0x57) is the ANSI code page ID according to this reference. dat=open(dbf,'rb').read(30)[29:] id=struct.unpack('B',dat)[0] print id,hex(id),chr(id) This prints 87 0x57 W on some random dbf I tested. For '949' you should be looking for 78 0x4E. Edit: Below is a look up table (dict) for the code pages copied from the above reference: lut={ 1 ...


3

You might try creating a file with the same base name as the shapefile but with a .cpg extension, containing a single line of text identifying the encoding, be it UTF-8 or something else. I am not sure if this will resolve the problem with QGIS, but I have had some success with this method to force multi-byte characters in attribute data to be interpreted ...


3

There's the option -W for pgsql2shp that allows you to specify the encoding. You could also look into setting the PGCLIENTENCODING environment variable. Most data sets from either the Dutch CBS or the Dutch Kadaster come in the CP1252 encoding, not Latin1.


3

Your shapefile is most probably in UTF-8, but qgis 1.8.0 has a bug in correct encoding of shapefiles. Until this is solved, you can try this workaround in Windows: Browse to C:\Programs\Quantum GIS Lisboa\bin on Windows XP or C:\Programs (x86)\Quantum GIS Lisboa\bin on Windows 7. Look for qgis.bat and open it with a suitable editor (I have installed ...


2

Shapefiles get their codepage either from the .dbf or from the .cpg file. The .dbf file has a byte that represents DBF Language Driver ID. There's some discussion about these in an archived ArcGIS Desktop forum on forums.esri.com. There's a Microsoft Knowledge Base article Understanding Code Pages in Visual FoxPro which lists 19 DBF Language Driver IDs and ...


2

You are correct: the string "Bălți" would have been represented in UTF-8 format inside OpenSteetMap. If mis-interpreted as iso-8859-1 it comes out "BălÈ›i". You can verify this at my favorite unicode tool: http://www.ltg.ed.ac.uk/~richard/utf-8.cgi You can get proper XML dumps of OpenSteetMap data here: http://download.geofabrik.de/osm/europe/ And then ...


2

I solved this problem by adding 'set pgclientencoding=latin1' (without quotes) to the batch script.


2

Apparently, the issue has been fixed in the development build of QGIS. http://hub.qgis.org/projects/quantum-gis/repository/revisions/75dc85b4d652116814873bb7674cab15ce6cde66 Installed QGIS version 1.9.0-Master and tried it out, works fine.


2

Quoting from the GDAL documentation for the Esri Shapefile driver: An attempt is made to read the LDID/codepage setting from the .dbf file and use it to translate string fields to UTF-8 on read, and back when writing. LDID "87 / 0x57" is treated as ISO8859_1 which may not be appropriate. The SHAPE_ENCODING configuration option may be used to ...


2

The problem was because, originally data in *.dbf file for Russian langauge exactly are often saved in OEM-866 encoding format. QGIS seems to be are marking convertions to the Unicode. For e.g. if you want to get the normal text (in UTF-8 for e.g.) from *.dbf you can do the next (sorry, that I'm provding only C# code, but I think in other programming ...


2

Currently, you can use any encoding in Shapefiles and the most common is Unicode. (and OpenStreeMap data use Unicode) I have no problem to open the Moscow shapefiles in QGIS and the Cyrillic characters appears: If you look at the properties of the layer, you can see that the encoding is 'UTF-8' (Unicode) -> you know the encoding of your shapefile and ...


2

I found the solution for the problem: layer = self.vlayer provider = layer.dataProvider() layer.select(provider.attributeIndexes()) addA=[] for elem in layer: attrs_r = elem.attributeMap() for (k,attr) in attrs_r.iteritems(): unicodestr = unicode(attr.toString(), "utf-8") addA.append(unicodestr) Now it is possible to use for ...


2

To be able to see the Arabic names you may proceed like this: 1) Go to Layer > Add Vector Layer 2) Choose the corect Encoding for your layer (Windows-1256, otherwise you'll see artifacts): 3) Just label your streets with Arabicstre:


2

Make sure you know what is the source encoding of your data and choose it when creating a layer.QGIS by default exports vector data in system encoding which doesn't have to be necessarily utf-8.


2

Ok, found at least one working solution. After finding that on Linux everything is fine suspected the default encoding in Windows. So I opened the QGIS project file (*.qgs) in PSPad and found this in layer description: <provider encoding="System">ogr</provider> So probably QGIS uses CP1250 encoding as default in Windows while the database is ...


1

You should try with the following configuration option: --config SHAPE_ENCODING="ISO-8859-4" because ISO-8859-4 is the ISO alias of Latin 4. Latin 4 introduces letters for Estonian, Latvian, and Lithuanian.


1

As a workaround you may use .cpg-files with encoding as additions to .shp (more on it here). Or hard-write encoding to the .dbf-header using Libre Office: just open it in Calc (it will ask you for encoding) and save it.


1

SOLUTION A for utf-8 encoded shapefiles Supposed you are working on Windows, look for qgis.bat in bin directory, and open it with a text editor. after the first line, insert SET SHAPE_ENCODING=UTF-8 and save. Qgis 1.8.0 has some problems with encoding, using your computers default font instead of the one you specify. It is fixed in Qgis Master (1.9.0) by ...


1

Can confirm this in python console: >>> layer = qgis.utils.iface.activeLayer() >>> layer.dataProvider().encoding() PyQt4.QtCore.QString(u'UTF-8') >>> layer.setProviderEncoding(u'latin9') >>> layer.dataProvider().setEncoding(u'latin9') >>> layer.dataProvider().encoding() PyQt4.QtCore.QString(u'UTF-8')


1

Here here is my proposal: TimeStamp and TimeSpan elements are actually defined in the OGC KML version 2.2 XSD, hopefully a glimpse at it helps you to devise a quick fix or pick up a good XML validation tools and probe your KML files against (Google extensions to OGC) KML's XSD.


1

You might want to ask on the Geoserver mailingist for this. I've used Norwegian characters in Geoserver on a ubuntu machine, and never encountered trouble. The "Invalid byte 2 of 2-byte UTF-8 sequence" error may be related to some byte-order-mark error, but i am not sure. I guess the Geoserver devs haven't tested all kinds of "strange" characters, so ...


1

I got this error (Invalid byte 2 of 2-byte UTF-8 sequence) when validating the SLD in GeoServer 2.1.3, where the Danish charater Å was used as a ogc:Literal. Editing the SLD file in a text editor kind of fixed the problem. The SLD editor in Geoserver now writes Å as Ã…. But my styling is working.


1

You could try to run iconv on your file. Something like : iconv -f LATIN1 -t UTF-8 /ptah/to/yourosm.file



Only top voted, non community-wiki answers of a minimum length are eligible