[gdal-dev] GDAL drivers written in Python

[Even Rouault]

Le mercredi 06 avril 2011 09:51:42, Knut-Frode Dagestad a écrit :
> Hi,
> 
> Our group is looking at the possibility to use GDAL with Python bindings
> for our work with satellite data. One limitation seems however to be
> missing/incomplete drivers, as we have no capacity to implement new
> drivers in C.
> 
> It seems however to me that the Python API allows to create GDAL
> Datasets from data which in principle could be read by any non-GDAL
> functions, e.g. PyHDF or self-made Python readers.
> 
> My question is therefore: is there in principle any important
> differences or limitations with datasets created this way, compared to
> datasets read with native GDAL drivers?

You cannot write a regular GDAL driver in Python or in any other binding 
language (*). They have to be written in C++ 

You can certainly write a (non-GDAL) reader in Python, but of course, you 
won't be able to benefit from the GDAL API with the "dataset" returned by your 
reader, or using them in software that use the GDAL API.

There are possible workarounds if the base GDAL driver recognizes the imagery 
but not the georeferencing. In that case, you can try adding .aux.xml files 
(might not work in all cases. really depend if the driver fallbacks to the PAM 
mechanism), or wrapping the imagery into a VRT file to add the georeferencing 
(will work in all cases at the expense of a small overhead, generally 
unnoticeable)

Of course, the best for the good of the GDAL community and project would be to 
contribute (or contract someone) to improving the existing drivers if they 
have defects or need improvements.

Best regards,

Even

(*) It is not currently possible. Technically I imagine this could be possible 
since most languages have ways to invoke them from C/C++. I know for sure this 
is possible for Python and Java. But it would be quite involved to add the 
generic glue sufficient to write an arbitrary driver in Python/Java/etc.. The 
technical challenge aside, I'm also wondering if the project really wants to 
go into that direction (it would make the deployment of a GDAL installation 
quite complicated), although I've a bit crossed that line recently by adding 
the (optional) OGR MDB driver that relies on a Java lib for doing the "hard 
work" (see http://gdal.org/ogr/drv_mdb.html). But this still remains a regular 
OGR C++ driver which happens, as a detail of implementation, to invoke Java, 
to be opposed to a pure Java driver.

> 
> Best regards from Knut-Frode
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev