[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