The March 20th, 2008 brought us new patch release of GDAL library. It doesn’t include any new features but a very tidy set of 65 bug fixes. Great Job GDAL Team!
The source code packages with GDAL/OGR 1.5.1 are available from the OSGeo download server.
Yesterday, Frank announced another milestone hit by GDAL:
Santa and the GDAL/OGR Project Team are pleased to announce the release of GDAL/OGR 1.5.0. This is the first “new feature” release since the GDAL 1.4.0 release approximately one year ago.
The new release brings a lot of new features and bug fixes. Just give some statistics:
The complete and long list of changes can be found in the 1.5.0 Release News.
The new GDAL/OGR 1.5.0 sources and a couple of additional packages can be found at Download Source website. There are also Windows 32-bit binaries available: http://download.osgeo.org/gdal/win32/1.5/
On behalf of the GDAL/OGR Project Team, I’d like to send a big thanks to all developers, contributors and users involved in development of the 1.5.0 release for their great work and support, invaluable bug reports and testing. And thanks to Santa too!
Here is the official GDAL/OGR 1.5.0 announcement posted on the OSGeo News.
Continuing my adventures with Visual C++ 2008, I’d like to share some observations about new WinSock2 features. The Visual C++ 2008 uses new incarnation of Microsoft Platform SDK called Windows SDK (New Windows SDK Available to Download). This SDK is named as for Windows Vista what’s quite misinforming because it also supports development for Windows XP, Windows Server 2003 SP1, and Windows Server 2003 R2.
One of new feature in Winsock API is WSAPoll function. As the MSDN says, this function is is defined on Windows Vista and later. However, if the Windows SDK is used on Windows XP this function is also available when building software but it’s not usable in run-time.
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.zipMore 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.
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.
You are currently browsing the archives for the gdal category.
