[gdal-dev] Open source vector geoprocessing libraries?
Mateusz Loskot
mateusz at loskot.net
Sun Jan 17 16:02:52 EST 2010
Jan Hartmann wrote:
> On 16-1-2010 16:03, Mateusz Loskot wrote:
>> Jan Hartmann wrote:
>>
>>> 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?
>>>
>> The VSI layer is available to all parts of GDAL and OGR.
>> If you scan source code of OGR drivers, you'll find that this feature
>> is already used by, for example, GTM driver:
>>
>> http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/gtm/gtm.cpp?rev=17612#L339
>>
>>
>> IOW, VSI layer is available and not dependant on GDAL or OGR format,
>> it's a separate library of common functions.
>>
>> Best regards,
>>
>
> Does that mean that I can use ogrinfo on a gzipped archive, like
> gdalinfo (http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip)?
Yes, it does but...as long as OGR driver performs filesystem
operations using VSI*L API. The problem is that only few of them use VSI*L.
As an example, I just updated OGR GeoJSON driver to use VSI*L API:
http://trac.osgeo.org/gdal/changeset/18573
As you can see, it is not a complex task, but may be time consuming and
tedious, and requires quite a lot of testing.
After these changes are applied, it is possible to (un)gzip GeoJSON
datasets:
1) Translate Shapefile to GeoJSON file compressed using GZip:
$ ogr2ogr -f GeoJSON /vsigzip/./points.geojson.gz points.shp
2) Read GZip compressed GeoJSON dataset:
$ ogrinfo /vsigzip/./points.geojson.gz
$ ogrinfo /vsigzip/./points.geojson.gz OGRGeoJSON
> This page says:
>
> "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""
Apparently, the Wiki needs to be updated.
> It would be a nice archive functionality.
Yes, indeed.
The work requires to step in to each OGR driver directory,
grep .cpp files for VSI verify what VSI API is used.driver:
For example, OGR Shapefile driver would, in theory, need to get
updated VSI calls in about 50 places:
$ grep VSI *.cpp | wc -ls
47
I'm quite sure volunteers would be appreciated.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
More information about the gdal-dev
mailing list