[Qgis-developer] GDAL Python Bindings

[Christopher Barker]

Martin Dobias wrote:
> On 10/31/07, Christopher Barker <Chris.Barker at noaa.gov> wrote:
>> In particular, thinking about a raster band, it could be a pretty good
>> sized bock of data, so we'd want a way to get a GDAL raster band into
>> whatever type you need for QGIS without a whole lot of data copying. By
>> default, we might end up with:
>>
>> gdal generates a raster band. (first copy)
>> it is converted to a Python string (two copies)
>> it is converted to a QGIS raster band equivalent (three copies)
> 
> But the vision is that you will use only QGIS interface to do
> anything, so the will be no need to do copies.

You can use the QGIS interface, but if the QGIS raster classes are not 
the same as GDAL classes (type), then you have to transfer the data 
somehow. If they are the same, then you'll have the same issue with 
other data providers.

But I suppose you mean that in Python, you'll only be using the QGIS 
interface. I guess the question is where it happens. If you have the 
QGIS/GDAL connection all at the C++ level, then I suppose you're right, 
that in python, you'd just use that interface.

However, take Frank's point seriously: GDAL is already a general purpose 
abstraction of raster data, and it already has python bindings. Is it 
really necessary to create another abstraction on top of an abstraction, 
and then create bindings for that?

Maybe it is, but do consider carefully.

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.

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

> - we already have WMS raster provider which integrates into QGIS well

How well does GDAL support MWS? could that be improved?









-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov