Mateusz Loskot

Today hot news from GDAL mailing list:

The GDAL project is pleased to announce the GDAL/OGR 1.4.4 release.
This is a bug fix release in the 1.4.x stable release series and
adds no significant new features.

This release replaces the GDAL/OGR 1.4.3 release which has been retracted
by the project as it included an unexpected ABI (Application Binary
Interface) change from the earlier 1.4.x releases. This ABI change means
that applications using the GDAL/OGR C++ interface, and GDAL/OGR driver
plugins built against GDAL/OGR 1.4.0, 1.4.1 or 1.4.2 could not be safely
used with GDAL/OGR 1.4.3. All applications redistributing binaries are
encouraged to discard GDAL/OGR 1.4.3 and use 1.4.4 instead. The GDAL/OGR
1.4.4 release is ABI compatiable with all earlier 1.4.x releases except
for the disavowed 1.4.3.

GDAL/OGR 1.4.4 is available in source format at:

http://download.osgeo.org/gdal/gdal-1.4.4.tar.gz
http://download.osgeo.org/gdal/gdal144.zip

More detailed NEWS on fixes in the 1.4.4 release can be found at:

http://trac.osgeo.org/gdal/wiki/Release/1.4.4-News

GDAL 1.5.0, a major “new features” release, will be entering beta during
December, and it is hoped a GDAL 1.5.0 release will be available by the end
of year.

A few days ago, one of GEOS users reported that he is not able to build GEOS 3.0.0rc4 using Visual C++ compiler. The problem was caused by broken NMAKE makefile included in this package.

Here is package with two files included: makefile.vc and dirlist.mk: geos-3.0.0.rc4-makefile-fix.zip. In order to fix the problem, download this Zip, unpack and copy the two files to the source subdirectory of unpacked GEOS sources tree, overwriting existing makefile.vc. Now, make complete rebuild using Visual C++:

cd source
nmake /f makefile.vc clean
nmake /f makefile.vc

For Visual C++ 2005 (8.0), you it’s a good idea to call nmake as follows:

nmake /f makefile.vc MSVC_VER=1400

If you’ll encounter any GEOS issues, please report them to the brand new GEOS bug tracker: http://trac.osgeo.org/geos/.

This is a simple test I run to check how tree based spatial index for Shapefile influences size of index file (.qix). I used OGR and spatial index implementation available in Shapelib, in file shptree.c.

Tested Shapefile has following characteristics:

$ ogrinfo -so test.shp test
Layer name: test
Geometry: 3D Point
Feature Count: 932870
Extent: (440001.000000, 5652001.000000) - (441999.000000, 5653999.000000)
Layer SRS WKT:
(unknown)

Also, file size of test.dbf is 15M, test.shp is 33M and test.shx is 7.2M.

Next, I run a sequence of commands generating spatial index tree, using higher depth on each turn, from 2 to 16. This is the first iteration for depth of 2 levels:

$ ogrinfo -sql "CREATE SPATIAL INDEX ON test DEPTH 2" test.shp
SHAPE: Creating index file test.qix

I collected size of index files (.qix) and collated with corresponding depth value. Here is the result:

Using DEPTH of 16, produced index file is of size 213 MB, six time bigger than test.shp (33MB) file with geometries. Using that huge index files for shapefile will likely make the index exploitation inefficient due to memory use and heavy hard disk I/O operations. I’d use index depth of 8 or 10 for this shapefile.

In fact, due to some problems with memory allocation while generating huge indexes, default depth value estimated by SHPTree implementation has been limited to 12 levels. Certainly, users still have the liberty to explicitly request depth higher than 12 levels, for example:

$ ogrinfo -sql "CREATE SPATIAL INDEX ON test DEPTH 100" test.shp

Certainly, it’s always a good idea to make a few simple tests and observe performance of querying shapefile features using indexes of different depth.

How to set svn:keywords property recursively on a set of files?

It’s easy using a couple of GNU and OpenSource utilities. Following example presents how to set the Id keyword on all C/C++ header files in sample project.

$ cd myproject

Set svn:keywords to all .h and .hpp files

$ find . -regex '.*\.h' -o -regex '.*\.hpp' | xargs svn propset svn:keywords "Id"

Commit submit property changes back to the repository

$ cvs commit -m "Set svn:keywords property on all header files."

Here is a post explaining how to set the svn:keywords property automatically using private SVN configuration file: Subversion and keyword substitution (at fixlinux.com)

Following this link to the Starving Dog as Art- The Utter Outrage you can read a shocking story about pseudo-art exhibition given by pseudo-artist Guillermo Habacuc Vargas with starving dog as the subject.

The Petition

Boicot a la presencia de Guillermo Habacuc Vargas en la Bienal Centroamericana Honduras 2008

In my today announcement of the OGR GeoJSON Driver, I stated as follows:

Unfortunately, OGR objects model does not allow to have geometries of different types in single layer.

Actually, this is not true or imprecise enough. The OGR model does support mixed geometry types in single layer. Such layer is defined as of type of wkbUnknown and it behaves similarly as, for instance, PostGIS layer (table) with geometry column defined as GEOMETRY type. The wkbUnknown means that a layer is ust fine and all geometry types are allowed in this layer.

(more…)

Update on Nov 6th, 2007 at 3:23 pm: GeoJSON Driver Errata

During last couple of days I was trying to run away in fear of Halloween monsters, so I locked myself with laptop in my wardrobe and decided to spent this time on programming a new driver for OGR. I ended up with usable implementation of GeoJSON driver for OGR and I’d like to introduce it here and now.

Motivation was simple…to avoid zombies but not only. In the MOSS4G project, we need a way to talk to remote geospatial data services. from mobile devices. We’ve started development of WFS client but it’s not a trivial task and we don’t want to hurry with that. Also, WFS and parsing GML seems to be a heavy task for mobile solutions, but we will check it later :-). In the meantime, we have something light and fast - GeoJSON.

(more…)