Shapes don't have attributes, they ARE attributes

As they did at the Developer Summit, ESRI gave a talk a talk today on SQL in the Geodatabase. I left equally as excited from this talk as I did from the very similar talk at the Developer Summit. In that time, Microsoft has declared it will launch its own spatial type, and ESRI has clarified that it will be supporting it. And on the the PostgreSQL front, they will certainly be supporting the PostGIS spatial format, as well as their own implementation of ST_GEOMETRY on that platform. These developments, plus new 9.3 developments discussed today in the usual "road ahead" slides, are wonderful.

It has always seemed that "GIS" departments were about as silly as "MS Word" departments. GIS implies certain kinds of complexities—spatial references, spherical geometry, topology calculations—which certainly require expert guidance, but from an IT perspective something is wrong if doing GIS right means being forced to use systems which insist on being at the center of the universe. If we are dealing with document management, we recognize that while a particular word processing package (e.g. MS Word) aids us greatly in formatting, composing, editing and comparing individual documents, it shouldn't demand to archive and version all documents of interest in my company. After all, what about the pictures, faxes, well logs and credit card receipts? Similarly, just because a GIS data set should be in a database doesn't mean that I should be forced to go through the GIS system to talk to that database.

That is to say, a shape (or raster, or topology rule, etc.) shouldn't really be any more special than other data types in a database. (There is no VARCHAR department at any company that I'm aware of.) For the longest time, dealing with shapes as equal citizens wasn't practical: there was no widespread agreement on shape representations in a database. But now there is: the OGC ST_GEOMETRY specs, and it's wonderful to see ESRI implement it. Finally our shapes can be attributes, subject to the wonders of SQL and all the millions of tools out there for data processing. This is the direction GIS should be going. Scheduling software can read ST_GEOMETRY to understand location, not that you have to buy a GIS scheduling package just because you want to be location aware.

And for the happy conclusions from today...

...Confirmation that SDE is happy to deal with ST_GEOMETRY type SQL queries neutrally. You can do things ArcObjects doesn't like, like have multiple geometry types in a single column, or put multiple shape columns in a table. You can deal with that complexity as you like in SQL, and expose simplified views to ArcGIS. One presenter suggested that even restrictions like those were being reconsidered in the "post-9.3" nirvana. It will be a profound change: the shape becomes a simple attribute, amneable to simple analysis.

...Oracle's default geometry type in 9.3 will become ST_GEOMETRY. This is because Oracle is deprecating the LONG RAW on which SDE BINARY relies in Oracle 11. The SDE presenters were studiedly neutral on which of SDO_GEOMETRY or ST_GEOMETRY was the "better" choice, and I'll depart character for once and not speculate on that. But given that ST_GEOMETRY will be a lingua franca in several databases and appeared (in at least one slide) to be a more compact representation, that'd be my choice. (In today's network-bound world, it seems storage size matters more and more.)

... SDE 9.3 will assume Unicode (UTF-16) for all new feature classes unless told otherwise. That's sure to throw some for a loop, but it's also the right thing to do.

The slides from the talk will certainly contain much more detail at a better level of accuracy, so keep a sharp eye out. You know whenever Gudmundur Hafberg shows up at a talk it will be absolutely crammed with incredibly useful information backed by hard metrics.

And with that the UC is over. It's a shame to leave the beautiful sunshine here in San Diego, but 4 days in this cult, friendly though it is, is probably enough.