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