Re: [gdal-dev] Support for reading GDAL datasets in compressed archives (.gz and .zip)

[Lucena, Ivan]

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 <even.rouault at mines-paris.org>
>  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
>  
>  
>