[gdal-dev] Open source vector geoprocessing libraries?
Even Rouault
even.rouault at mines-paris.org
Sat Jan 16 07:52:10 EST 2010
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.
>>
>>
>
>
>
More information about the gdal-dev
mailing list