Following those findings, I assumed it is not quite correct, or I didn’t like the inconsistency, and I had reported it to Microsoft Connect as a bug: SqlGeometry reports invalid type of WKB of POINT EMPTY.

Recently, I have received a couple of comments from Microsoft to my report. The comments are attached to the report linked above, but I paste them below for completeness and archive:

Our development team for the spatial data types tells me that it is not possible to use a single value for the WKB format of any spatial data type. For the POINT EMPTY, the WKB format does not allow empty points, so we are outputting a MULTIPOINT with zero elements.
In a MULTIPOINT EMPTY, we are stripping out empty points.

The reasoning is technically correct. It’s just Microsoft does it differently. However, as second comment suggests, the current behaviour may change in future:

But we might consider changing it to get consistent behavior.

I checked Well-Known-Binary output as returned by the SqlGeometry method STAsBinary(). Here is a small test program written in C#:

using System;
using System.Linq;
using Microsoft.SqlServer.Types;
namespace SqlGeometryEmpty
{
  class Test
  {
    static void Main(string[] args)
    {
      foreach (string type in
         Enum.GetNames(typeof(OpenGisGeometryType)))
      {
        string wkt = type.ToUpper() + " EMPTY";
        SqlGeometry geom = SqlGeometry.Parse(wkt);
        byte[] wkb = geom.STAsBinary().Buffer;
        string wkbhex = string.Join("",
          wkb.Select(
            b => b.ToString("X2")).ToArray());

        Console.WriteLine("{0}\n{1} ({2} bytes)\n",
          wkt, wkbhex, wkb.Length);
      }
    }
  }
}

The first observation is that WKB of EMPTY geometry for all types is returned as a a slightly different binary. All the binary forms are truncated to nine bytes. The first byte indicates endianness as expected. The second chunk of four bytes indicate geometry type. It is exactly as defined in OGC specifications. The third chunk of remaining four bytes are set to Zero and seem to play a role of size specifier: number of points in LINESTRING or number of rings in POLYGON, number of points in MULTIPOINT, and so on. This makes another observation that WKB for EMPTY is reported as a collection of primitive components.

The difference in binary of WKB of EMPTY geometry I mentioned is in that the actual type of input geometry is preserved, so there seems to be no implicit translation to geometry of some other type.

So far so good but not for too long. In fact, SqlGeometry implicitly casts POINT EMPTY to MULTIPOINT EMPTY geometry with the WKB of the following form (in hex):

010400000000000000

Here is complete output of the test program above:

POINT EMPTY
010400000000000000 (9 bytes)

LINESTRING EMPTY
010200000000000000 (9 bytes)

POLYGON EMPTY
010300000000000000 (9 bytes)

MULTIPOINT EMPTY
010400000000000000 (9 bytes)

MULTILINESTRING EMPTY
010500000000000000 (9 bytes)

MULTIPOLYGON EMPTY
010600000000000000 (9 bytes)

GEOMETRYCOLLECTION EMPTY
010700000000000000 (9 bytes)

A word about how PostGIS behaves. PostGIS reports GEOMETRYCOLLECTION EMPTY, regardless of actual type of input EMPTY geometry. It is in hex form:

010700000000000000

Generally, there is not many choices of how to report EMPTY geometry in clear and usable way and a form of collection with size equal to Zero seems to be the most appropriate choice. POINT EMPTY reported with type set to POINT (010100000000000000) would be ambiguous as feels like truncated or invalid form of POINT(0 0), especially in programming languages like C where native dynamic allocated arrays do not carry information about their size. IOW, geometry type is not enough information to process binary form of POINT EMPTY properly.

Reporting EMPTY geometries as a collection is a useful convention that seems to work well. PostGIS behaves about it in the very consistent manner reporting one type for all empties. SqlGeometry, so SQL Server, forces programmers to write a few more lines of code to handle all the possible cases. Yet another original exotic solution from Microsoft.

Consistent API is a bless!

Update: consistent specification of interface is even better.

Apparently, there are situations in which PostGIS could be an affordable anti-GML vaccine jab. It seems there is a potential market for PostGIS to conquer. Perhaps it wouldn’t be estimated as profitable as the H1N1 but who knows what will happen if no one takes a brave stand and stop GML designers! Here I’d eagerly conclude with one of the famous Scottish sentences :-)

Back to the subject matter. Today, I spotted an interesting question on the StackOverflow archives: Is it possible to export spatial data from Sql Server 2008 in gml2 format?. Natively? No, there is no such solution. Presumably, Microsoft thinks forward and thinks GML 2 is a legacy standard. Fair enough, someone has to draw a line between prehistoric and modern, somewhere. Why Microsoft? Again?

Facing such a tremendous suffer Microsoft exposed SQL Server users to, I suggested to visit the “underworld” for a while and hire PostGIS to do the dirty job.

Paraphrasing Andrei Alexan­dres­cu‘s, hysterically famous recently, sentence: SQL Server should go!.

This is the first major new release since the 1.6.0 release approximately one year ago

This new version brings quite a nice collection of new drivers for raster and vector data formats:

• New Raster Drivers: BAG, EPSILON, Northwood/VerticalMapper, R, Rasterlite, SAGA GIS Binary, SRP (USRP/ASRP), EarthWatch .TIL, WKT Raster
• GDAL PCIDSK driver using the new PCIDSK SDK by default
• New Vector drivers : DXF, GeoRSS, GTM, PCIDSK and VFK
• New utilities: gdaldem, gdalbuildvrt now compiled by default
• Add support for Python 3.X. Compatibility with Python 2.X preserved
• Remove old-generation Python bindings
• Significantly improved raster drivers: GeoRaster, GeoTIFF, HFA, JPEG2000 JasPer, JPEG2000 Kakadu, NITF
• Significantly improved vector drivers: CSV, KML, SQLite/SpataiLite, VRT

The upcoming release of PostGIS 1.5.0 (available as beta1 beta2) will require GEOS in version 3.1.0 or later.

The beta1 testing results suggested to bump the minimum GEOS version to 3.1.0. The GEOS requirement issue was one of the heavily discussed topics on the postgis-devel this month.

The PostGIS team is going to give GEOS a nice present for its 10th round month birthday.

Kevin Neufeld delivered a very well written chapter about Dimensionally Extended 9 Intersection Model (DE-9IM) with series of excellent visualisations of the non-trivial mathematics.

Moreover, Kevin started completing the PostGIS Functions Reference with visual presentation of geometric problems together with SQL commands using various PostGIS functions that can be applied to solve particular situations. For example, what does the ST_Buffer function, how boolean predicates like ST_Contains check spatial relation of two geometries or what’s the difference between ST_Difference and ST_SymDifference.

Clearly, I’ve got way way more than I asked for or I expected. On behalf of myself and users who are about to start their adventure with PostGIS, I’d like to give big kudos to Kevin for this fantastic work!

Together with the recently documented PostgreSQL PostGIS Types and Function Support Matrix, PostGIS team is making abrupt manual a pleasant reading book.

By the way, here is a bunch of references about DE-9IM I found very useful myself:

• Dimensionally Extended Nine-Intersection Model (DE-9IM) by Christian Strobl
• Encyclopedia of GIS by Hui Xiong, page 242

The PostGIS 1.5 documentation is available under the manual-svn node and here is the PostGIS Function Support Matrix.

Regina, great job!

By the way, there is an interesting problem with check marks. does anyone know how to define check marks based on Unicode and make them visible in IE8?

Paul Ramsey has started wrapping up a proper article on PostGIS Wiki explaining most of the issues related to understanding of emptiness of geometries bothering the community of PostGIS users, and OGC standards users in general.

Check it like it’s hot DevWikiEmptyGeometry. Thanks Paul!

Interestingly, Bartosz proposes to understand the battle with data races as a discipline-driven programming that helps, mostly C+ programmers, to avoid all this horrible pitfalls. Moreover, Bartosz presents programmers with a well-designed methodology based on types system as a tool that may guard programs against injury from data races problem and with success.

Basically (and not surprisingly) Bartosz recommends think first, act later kind of approach based on detailed analysis of what might be causing data races in your program, on identification of potential sources of data race problems. This approach is a contrary to spending hours searching for data races conditions using debugger.

The data race problem is a complex subject, but – in my opinion – Bartosz explains it in a very accessible step-by-step form. Three words summary of Bartosz’ lecture and the presented methodology is: sharing + mutability + no synchronisation = data race