[Qgis-developer] GDAL Python Bindings

[Frank Warmerdam]

Christopher Barker wrote:
> Martin Dobias wrote:
>> 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)
> 
> Could that be accomplished by adding an easier way for users to write a 
> new GDAL driver? There's no theoretical difference.

Martin,

I agree with Chris on this.  Writing GDAL drivers is already quite
easy.  For normal raster formats, I don't see why it would be valuable
to have a QGIS specific mechanism to implement raster layers.

One thing I would acknowledge is that you can't currently implement a
raster format for GDAL in Python.  I'm not sure how useful it would be
to be able to do so, but if it is it could be added.  I know this is
something that Howard is interested in.

>> - 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
> 
> I'd say figure out a way to make the packaging easier, in either case 
> you need QGIS, GDAL, and GRASS, so it wouldn't lessen your dependencies 
> (unless you want just grass, and not GDAL, I suppose)

Right, lets just make this easier.

Maintain a good GRASS driver is not trivial, and it would be nice to
focus the effort on the GDAL implementation which already has some
warts rather than disperse effort over more versions (IMHO).

>> - we already have WMS raster provider which integrates into QGIS well
> 
> How well does GDAL support MWS? could that be improved?

Is this treated strictly as a raster format?  If so, perhaps you would
find the GDAL WMS driver is also suitable.  If however you treat this
as a custom sort of layer with special layer properties and interactions
(for GetFeatureInfo for instance) then why conceptionalize it as a "raster"
layer.

So, while I'd admit I don't know QGIS that well, I'd suggest you leave
yourself open to "custom layer implementations", but focus on GDAL for
the standard QGIS raster layer.  Provide QGIS Python bindings for
setting up and interacting with raster layers but when deeper interaction
is needed with the raster datasource have people move over to the GDAL
Python bindings.

Chris, Mateusz, myself and others are willing to help out as needed.

By way of comparison a few very brief case studies.

1) MapServer: has a few historical non-GDAL raster drivers, but uses
GDAL for all new raster datasources though it is possible for folks to
implement custom layers types for rasters if they want.  But if they do
it will lack many of the features of the real raster layer.

2) MapGuide: Uses FDO for rasters.  FDO has it's own raster data model
which is adequate for visualization but I would claim is weak compared
to GDAL.  The only OpenSource MapGuide raster driver is the GDAL based
one.

3) OpenEV: Has a GvRasterLayer abstraction for raster layers, but there
is only the GDAL based implementation.  This means it is easy within an
OpenEV tool to grab the underlying GDAL dataset for a raster layer, and
do analysis of various sorts based on it without worrying about a weak
intermediate layer with various implementations under it.

4) GRASS: Essentially rasters need to be in GRASS format and are accessed
by the libgis from the internal formats.  GDAL is now used for most import
and export, though other custom programs exist for particular products
(mostly historical).  I would claim that if GRASS were being implemented
from scratch now, it would be much better to treat GDAL's data model as the
GRASS raster data model, and just add some supporting stuff around it to
hold GRASS classifications, etc.

<EmpassionedExhortation>
 From a raster point of view QGIS is essentially a "green field" (no
offence I hope) so why not parter closely with the GDAL team, and
maximize the synergy available instead of duplicating too much.

 From my point of view, I imagine OpenEV continuing to fade away and I
see QGIS as the most obvious Open Source "C++ GIS Desktop" application.
I'd like to make it a convenient place to exploit GDAL's capabilities,
and an environment in which GDAL based modelling and other operations can
be done.  I'd like the GDAL community to think of it as their default
desktop app, and I'd like the QGIS community to think of GDAL as "their"
raster library.
</EmpassionedExhortation>

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