[gdal-dev] Re: GDAL drivers written in Python

[Knut-Frode Dagestad]

Even,

Thank you. That clarifies, and motivates use of the MEM format.
I gradually start to understand that GDAL is generally more 
file-oriented than memory-oriented.

Then I have one last question for this thread:
As mentioned in another post, for some formats (e.g. Envisat) both the 
image data and GCP's are read by GDAL.
What is then the reason why reprojecting with API or gdalwarp does not 
work, and why this (and other) format is classified as "not 
georeferenced" in the table of supported raster formats?

My theory is that this is because polynomial fit between row/col and 
lon/lat does not work since there are errors (contradictions) in the 
list of GCP's (e.g.: http://trac.osgeo.org/gdal/ticket/3709).
Or is there another explanation?

Best regards from Knut-Frode




On 07.04.2011 13:31, Even Rouault wrote:
> Selon Knut-Frode Dagestad<knutfrodesoppel at hotmail.com>:
>
>> 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?
>
> Ok, I didn't understand well what you meant before. You could for example create
> a MEM dataset ( http://gdal.org/frmt_mem.html ) and feed it with matrix of data
> and georeferencing. If your data is too big and cannot fit entirely into RAM,
> then you'll have to go with a temporary file, such as geotiff.