[gdal-dev] Open source vector geoprocessing libraries?

[Jan Hartmann]

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.
>>>
>>>
>>
>>
>>
>
>