Hi Even, On 06.04.2011 20:21, Even Rouault wrote:
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.
But if I use the GDAL API to create a GDAL Dataset and then insert a matrix of data (read with non-GDAL code), and further add some georeferencing or tie-points, it seems to me that I then can utilize GDAL API functionality for e.g. reprojecting, subsetting and exporting, just the same way as if it was read with a GDAL-driver?
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)
Thank you for useful suggestions, I will look into these features.
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.
I agree this is ideal. Since we must focus on downstream applications (geophysical algorithms) we cannot dig too deep into the core driver programming. But hopefully it is still manageable, it is anyway good to see that Antonio has very similar needs and interests as our group.
Best regards from Knut-Frode _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
