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

[Martin Dobias]

On 11/5/07, Frank Warmerdam <warmerdam at pobox.com> wrote:
> 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.

Hi Frank,

the objective is that in future we'd like to possibly support other
providers than just GDAL. While still using GDAL as a primary data
provider, there's a need for more flexibility than using only GDAL as
a raster library:
- support for application-specific providers: to give users some easy
way to write a new data provider (in c++ or python)
- add GRASS raster provider - currently we depend on GRASS driver in
GDAL which produces some problems with packaging especially on
windows, e.g. you need to first compile GDAL, then GRASS and then GDAL
again with GRASS support
- we already have WMS raster provider which integrates into QGIS well


> > 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.

When looking at the SIP documentation, that conversion would be
probably done with some of this magic and SIP_PYOBJECT annotations. I
can imagine that this could work for layers with GDAL as underlying
data provider.


> 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.

QGIS API regarding raster handling isn't in a good shape or stable -
since the API has been used just internally and have been made
publicly available only recently. First we'd like to offer users at
least "something" (e.g. to render the layer) and then add more
functionality - like direct connection with GDAL bindings.


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

I hope that we're still far from doing duplication...

Regards
Martin