[gdal-dev] Proposed UTF-8 SWIG Changes

Even Rouault even.rouault at mines-paris.org
Mon Sep 27 15:24:53 EDT 2010


you'd likely need to also define the following typemap

%typemap(freearg) (const char *utf8_path) { 

to avoid memory leaks with Python3.

Hum, and on Python2, GDALPythonObjectToCStr() doesn't seem to accept unicode 
strings. Did you make a change in it ? or did I miss something ? I think that 
the part that deals with Unicode for Python3 currently should be generalized 
for Python2 too

For example, currently feat.SetField(0, u'a') throws :

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/dist-packages/GDAL-1.7.0-py2.6-linux-
x86_64.egg/osgeo/ogr.py", line 2179, in SetField
    return _ogr.Feature_SetField(self, *args)
NotImplementedError: Wrong number of arguments for overloaded function 
  Possible C/C++ prototypes are:
    SetField(OGRFeatureShadow *,int,char const *)
    SetField(OGRFeatureShadow *,char const *,char const *)
    SetField(OGRFeatureShadow *,int,int)
    SetField(OGRFeatureShadow *,char const *,int)
    SetField(OGRFeatureShadow *,int,double)
    SetField(OGRFeatureShadow *,char const *,double)
    SetField(OGRFeatureShadow *,int,int,int,int,int,int,int,int)
    SetField(OGRFeatureShadow *,char const *,int,int,int,int,int,int,int)

whereas the same with feat.SetField(0, 'a') works.

Also it seems that the %typemap(in) (tostring argin) typemap is essentially 
the same as the new one you propose. So perhaps tostring use should be 
generalized instead ?

> Even, Tamas, Ari, Howard, and other SWIG wise men,
> I got lost last night in the SWIG typemaps we use for GDAL, but eventually
> I came up with a minimal patch that seems to make sense and work.  I would
> appreciate it if you guys could skim it and let me know if I'm doing things
> in a really wrong or dangerous way.
>   http://trac.osgeo.org/gdal/attachment/ticket/3766/utf8_swig.patch
> I am attempting to treat any const char * parameter named utf8_path via
> a custom typemap that uses the preexisting GDALPythonObjectToCStr() to
> convert it.  This appears to take regular strings, and unicode strings
> properly in Python.
> In other languages there is no special processing except that I have also
> globally applied the NONNULL typemap to such parameters.
> If I got ahead with this, should I add utf8_path in the README.typemaps?
> Best regards,

More information about the gdal-dev mailing list