microsoft

First I'd like to say if you haven't tried GIS Stack Exchange, give it a try. It's a good resource to ask GIS questions of all kind and get answers.

We haven't had a chance to try out the new Denali CTP1, and probably won't be able to get to it for another month or so. It does seem to have some new exciting features for both Spatial as well as the basic database features. We are also looking to do another compare shoot-out between SQL Server, PostGIS, and Oracle. Since PostGIS and SQL Server are the ones we are most familiar with, we'll do a bit of contrast and compare here

Spatial compares of the top 3 commonly used spatial databases

Last time we did a survey such as this Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6 we had in our mix MySQL instead of Oracle. Many people wanted to see Oracle in that comparison, so this time, we have replaced MySQL with Oracle.

In our new compare, Compare SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5 Spatial Features, we focus mostly on the feature sets as documented by each offering in their manuals. Given the breadth of functionality we were comparing, its quite possible we missed something. Please let us know if we made any erroneous statements or missed a critical function, and we will be happy to correct. Part of the point of this compare is also for migration purposes. If you are using a feature in databasse X and want to know if you can still do the same or if there is a comparable function in database Y, we hope this will be helpful in ascertaining that.

We really wanted to include SpatiaLite in there, but SpatiaLite fills a slightly different niche from the aforementioned 3 that I think in most cases is complimentary to the 3 rather than direct competition. The fact that SpatiaLite is built on SQLite and much of the same plumbing that PostGIS is built on (GEOS/Proj), means it lacks some of the enterprise features we have come to expect from an enterprise database -- e.g strong aggregation functions, stored procedures/functions, but on the plus side is much more portable (suitable for in the field work) and still has a lot of spatial power under its toolbelt.

PostGIS in Action status

We have received our final set of reviews as well as blog reviews of our book PostGIS in Action and are still making revisions to the chapters based on them and prior reviews. The reviews were very positive. The last set of reviews, we got perfect scores. However there were noted areas of improvement. For one, I guess people are really into real examples rather than made up ones. As a result, we have rewritten chapter 1 to be more of a 60 minute quick course in loading geometry/geography, viewing, and writing spatial queries against which will be filled in with greater and greater depth in later chapters.

We've also tried to sprinkle along the way in the book, non-US examples. This is tricky though since US data is the data set we have most access to and can esily package in without licensing issues. Any thoughts on Non-US datasets we can use would be welcome. There are some things we will have a harder time with such as adding more pictures and more polished pictures. Those unfortunately just add a lot of overhead. We will try our best to improve on that where it doesn't considerably impact cost.

As far as blog reviews, we thank Bill Dollins and Mark Leslie for their great blog reviews. It is nice to know that we are hitting the audience and level of depth we had hoped to.

I've been whining a lot lately about how SQL Server 2008 (and none of the other SQL Server's) have a generate_series() function that I have grown to love in PostgreSQL. Admittedly I've just been too lazy to create one even though its not that difficult of a task.

Simon Greener over at Spatial DBAdvisor heard my whining and I guess got fed up enough to create a generate_series() function for SQL Server 2008. He also has a generate_series function for Oracle too by the way.

Now there are a couple of differences between the way you use it in the 3 databases which are caused by fundamental differences between the architectures of the 3 databases.