[Gdal-dev] Re: [Qgis-developer] GDAL Python Bindings

[Frank Warmerdam]

Martin Dobias wrote:
> Hi,
> this is not the biggest problem and I think we could live with it.
> But conceptually, why to connect GDAL and QGIS bindings? We want to
> provide API that doesn't make differences between different data
> providers: that's what is already done for vector data and what will
> be done at some point for raster data. This is the reason why I think
> that we should use our own data types, independent from underlying
> libraries.

Martin,

I'm not sure I understand your point here.  Is the objective to support
raster data providers other than GDAL in a way that is uniform?  Or to
achieve a maximum amount of similarity in API between raster and vector
data sources (ie. similar metadata, driver capabilities and so forth)?

If the objective is to support raster providers other than GDAL I'd like
to make an empassioned plea to avoid this, but I don't want to rail against
something you weren't even suggesting.

> I see problem in converting between C++ and Python types. If you
> instantiate a GDAL object in Python, how QGIS will get the pointer to
> the real C++ object? I don't know how to tell SIP to use a type from
> other library which isn't wrapped by SIP.

Given a PyObject from something like the Python gdal.Open() wrapper
the object looks like this in C:

typedef struct {
   PyObject_HEAD
   void *ptr;
   swig_type_info *ty;
   int own;
   PyObject *next;
} PySwigObject;

The "void *ptr" is the wrap C/C++ pointer and can be cast to
GDALDatasetH or GDALDataset * as desired.  This approach is
somewhat fragile it might be worth inserting externall C callable
functions into the Python bindings that will safely return the
corresponding C/C++ pointer from a Python object.  Basically this
would be a variation on the SWIG_Python_ConvertPtrAndOwn() function
produced in the existing SWIG bindings, but designed for external
use.

This is also a problem that OpenEV has using the GDAL SWIG bindings.
OpenEV uses "yet another" python wrapping C mechanism and needs to
be able to work with swig wrapped python objects in various places.
In the past I put the conversion logic in OpenEV but it makes things
fragile in the face of changes to how swig works which is why I suggest
we make this a supported thing from within GDAL.

Overall, I'm not adverse to QGIS providing some modest degree of
python wrapping for GDAL datasets *but* the GDAL API is quite rich,
and developing over time.  I would claim that you don't want to be
in the position of producing wrapper glue for all of this, and
documenting it just so that QGIS Python scripters can get at the
capabilities.  And of course, if it is distinct from the normal way
of doing python stuff with GDAL, there will be regular frustration
that the existing wealth of GDAL Python scripts won't work in the
QGIS environment.

So, lets see what we can do to avoid too much duplication.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org