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!.

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?

One of the major “issues” with OSGeo in particular is the open and slanderous at times propoganda that is communicated regarding “commercial” companies regarding software quality, maintenance schedule and delivery of bug fixes to their constituent markets.

I agree with propaganda but I do not agree with slanderous propaganda. I have never seen anybody talking or writing on behalf of OSGeo who would be spreading defamation about anyone or anything in the industry or outside.

Shawn, it’s just not right. Please, drop the heavy stones away and pick the facts.

A human nature pisses me off, sometimes. (I am a human being, in case of doubt.) The world is bloody relative but we love to sling absolutes around. Yeah, we love this game! We are not good in learning from mistakes, anyway. Thus, the only achievement of attempting to apply a patch to someone’s buggy ignorance is a waste of time and may be a bit of training in fast typing or boxing ;-)

Paul is right recommending don’t feed the troll!. But, what has been learned is going to be lost, naturally.