Yes, that is clear, thanks. I see that at the moment only raster files
are supported. Would it make sense to do this for vector formats too? I
am thinking of a dump from a large PostGIS database I had to upgrade
from a 32 to a 64 bits server. I didn't like the pgdump format, as I got
in all sorts of trouble with system tables and libraries, and the
dumpfile got really big. If I had thought about it, I would have
extracted all schemas with OGR, and I am certainly going to archive and
gzip my PostGIS vector files that way. It would be nice if ogrinfo could
give information about vector files within a (g)zip archive, and, of
course, it would be ideal if the files within that archive would be in
some sort of GML that could be translated back to a binary OGR format.
That would make a perfect data storage and archive medium, but
meanwhile, thanks to this conversation, I already have found a nice way
to backup and archive my maps. Thanks.
Jan
On 16-1-2010 13:52, Even Rouault wrote:
Jan,
Some GDAL and OGR drivers use a specific API, the VSI File Large API,
to access files. That API mimics the semantics of standard C library
IO API :
fopen -> VSIFOpenL
fread -> VSIFReadL
fseek -> VSIFSeekL
....
Usually that API enables access to large files (> 4 GB) on Unix and
Windows. But there are a few 'plugins' for specific purposes. For
example, if you pass /vsigzip/pass/to/your/file.gz to VSIFOpenL, the
calls will go through a plug-in that will do on-the-fly decompression
of a GZip compressed file (compression support added by Frank in
1.7.0). This is used internally by the GDAL R driver, or by the OGR
GTM driver. We can also use the /vsimem/ prefix to read or write into
in-memory files (used internally in GDAL in some drivers and
algorithms, used by MapServer to generate the output image and avoid
creating a temporary file on the file system, etc...). Or /vsisubfile/
to access to a file embedded within another file (used to decompress
JPEG2000 or JPEG streams in some formats like NITF).
Here are a few links for further reading on the subject :
http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip
http://gdal.org/cpl__vsi_8h.html
Best regards,
Even
Oh, that makes a difference indeed! When I read Frank's long answer,
this was the only point I didn't like. How does this mechanism work?
Jan
On 16-1-2010 12:33, Even Rouault wrote:
I think Frank meant
With Even's work, it is *now* possible for many drivers to to
transparently access compressed files using the /vsigzip/ mechanism.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
