ograms would all have to be changed unless
you supplied the CPL_ANSI_FILENAMES=ON option, or something similar.
Best,
Jason
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Even Rouault
Sent: Monday, September 07, 2009 2:56 PM
To:
Selon Ivan :
> >
> > Folks,
> >
> > I wonder if we should implement some mechanism to support UTF-8 filenames
> > on windows (and generally) before GDAL 1.7 release?
That would be definitely a cool idea. Apart from Windows, I'm not sure if other
supported OSes need work. As far as Linux is concer
Frank Warmerdam wrote:
Even Rouault wrote:
Louis, Chaintanya,
I just wanted to mention that the topic of encoding for filenames
dealt by GDAL
or OGR is a known issue that has not been addressed yet. You can read
http://trac.osgeo.org/gdal/wiki/rfc5_unicode which was a proposal but
has not
be
Even Rouault wrote:
Louis, Chaintanya,
I just wanted to mention that the topic of encoding for filenames dealt by GDAL
or OGR is a known issue that has not been addressed yet. You can read
http://trac.osgeo.org/gdal/wiki/rfc5_unicode which was a proposal but has not
been implemented. Some infras
Selon Lodewijk Pool :
> Even,
>
> I think I've figured this out, in my particular example I had a filename
> which contained the character 'é' (U+00E9), which in UTF-8 encoding is the
> two byte sequence 0xC3 0xA9. However, this character is also in the ANSI
> character set (233 decimal), which e
Even,
I think I've figured this out, in my particular example I had a filename
which contained the character 'é' (U+00E9), which in UTF-8 encoding is the
two byte sequence 0xC3 0xA9. However, this character is also in the ANSI
character set (233 decimal), which explains why passing a "normal" ANSI
Louis, Chaintanya,
I just wanted to mention that the topic of encoding for filenames dealt by GDAL
or OGR is a known issue that has not been addressed yet. You can read
http://trac.osgeo.org/gdal/wiki/rfc5_unicode which was a proposal but has not
been implemented. Some infrastructure for re-encodi
Louis,
I tested this with
http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdalinfo.c
GDALOpen() function is called at
http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdalinfo.c#L149
Check if the gdal utility programs work with your data. Use ogrinfo on the
offending mapinfo file and gdalinf
Hi Chaitanya,
I appreciate you taking the time to check. The TAB extension is MapInfo's
vector file format. The odd thing is that I did exactly the same test as you
did, I renamed a GeoTiff file to the offending filename and tried the normal
Raster Driver and got the same problem. Still, as far as
Louis,
I couldn't reproduce the problem on my WinXP-32 system with vc8 with locale
set to uk english. However, I used the filename on a GeoTiff file. I
couldn't identify the .TAB extension. I am not sure that is a problem.
Some of the drivers may not handle non-ascii data but file names should no
Hi Chaitanya,
Yes, this is using the C/C++ API, the functions I am using are declared in *
gdal.h* and *ogrsf_frmts.h* respectively. I am using WinXP 32bit (UK English
locale) and a version of GDAL 1.6.2 that I compiled for Win32 using the
supplied nmake script files for VC8. The specific filename
Louis,
GDAL/OGR usually supports utf-8 encoding. I just don't know where it doesn't
support.
Can you provide the details of the OS you are working on? Also, some sample
file names that caused you problems will come handy.
I presume you are working in C/C++.
On Mon, Aug 31, 2009 at 6:37 PM, Lodewi
Hi All,
I'm having problems opening Raster and Vector Datasources that have
filenames and paths with special characters. I'm using GDALOpen for Raster
sources and OGRSFDriverRegistrar::Open() for Vector sources, the strings I
pass for the filenames are UTF-8 encoded. Does anyone know whether these
13 matches
Mail list logo
