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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
