Even, Yes, ".gz" doesn't make sense. Copy&Paste error. I meant ".zip".
Imagine that you are a user and you want to know what is in the ZIP file, what if you could browse through the ZIP directory, like that: % gdalinfo /vsizip/myarchive.zip Subdatasets: SUBDATASET_1_NAME=/vsizip/myarchive.zip/subdir1 SUBDATASET_1_DESC=directory: subdir1 SUBDATASET_2_NAME=/vsizip/myarchive.zip/subdir1 SUBDATASET_2_DESC=directory: subdir2 % gdalinfo /vsizip/myarchive.zip/subdir1 Subdatasets: SUBDATASET_1_NAME=/vsizip/myarchive.zip/subdir1/scene1.tif SUBDATASET_1_DESC=file: scene1.tif SUBDATASET_2_NAME=/vsizip/myarchive.zip/subdir1/scene2.tif SUBDATASET_2_DESC=file: scene2.tif You could go up and down the directories this way. Now, Imagine that you are a GUI developer and you what your specialized version of a "FileSelectionBox" to load any GDAL supported format by following the logic: if GDALOpen() returned a valid GDALDataset but there are subdatasets: then re-load the dialog box with the list of dataset descriptions. Keep doing that until you got a real GDALDataset. Just like what ESRI applications does for multi-band images. Anyway, I believe that beavering like that the driver would help command like users and GUI developers to use sub-datasets in the same way for all GDAL formats that supports it. Semantically, I would not be ashamed of calling a "folder" a "dataset-container", with "sub-datasets" inside. Just an idea, too much coffee :) Best regards, Ivan > -------Original Message------- > From: Even Rouault <[EMAIL PROTECTED]> > Subject: Re: [gdal-dev] Support for reading GDAL datasets in compressed > archives (.gz and .zip) > Sent: Aug 27 '08 18:34 > > Le Wednesday 27 August 2008 15:58:54 Lucena, Ivan, vous avez écrit : > > 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? > > In fact a .gz file is just one single compressed file (I do not > handle .tar.gz), so it does not make sense for that format. > > It could make more sense for .zip files. But what you propose is not directly > linked to zip files. It would be true of regular directories on > the "classical" file system. And I'm not sure that all GDAL files under a > directory can be considered as subdatasets of that directory. That behaviour > should be clearly specified, and I think it belongs to the application level, > not to the library one. > > > > > > 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 gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
