Rouault,
Nice job!
Even Rouault wrote:
----------------------------------
To read from a .gz file,
----------------------------------
gdalinfo /vsigzip/path/to/the/file.gz were path/to/the/file.gz is relative or
absolute.
The first time that a .gz file is read, a small .gz.properties file will be
generated (if possible) to capture the uncompressed data size. This will make
following opening of that dataset much faster.
Suggestion:
Would be interesting to bring the content of "file.gz" as subdatasets:
Subdatasets:
SUBDATASET_1_NAME=/vsizip/myarchive.zip/subdir1/file1.tif
SUBDATASET_1_DESC=GeoTiff,100x110x1
SUBDATASET_2_NAME=/vsizip/myarchive.zip/subdir1/file2.tif
SUBDATASET_2_DESC=GeoTiff,100x110x1
SUBDATASET_3_NAME=/vsizip/myarchive.zip/subdir1/file3.tif
SUBDATASET_3_DESC=GeoTiff,100x110x1
What do you think?
Small syntaxic sugar : if the .zip file contains only one file located at its
root, just mentionning "/vsizip/path/to/the/file.zip" will work.
The same would apply to subdatasets, I guess.
The fact that this new capability is implemented as virtual file systems imply
that it will only work for GDAL drivers supporting the "large file API". A
list of such drivers is : PNG, JPEG, ILWIS, GTiff, GIF, JP2KAK, NITF, ADRG,
DTED, SRTMHGT, BMP, LCP, HFA (Erdas Imagine), AAIGRID. Other drivers may work
too (I just looked for those advertizing the GDAL_DCAP_VIRTUALIO capability)
That all we need? Nice!
Best regards,
Ivan
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
