SQL Server Spatial Support: An Introduction

isaac — Thu, 17 May 2007 01:28:00 GMT

I’ve been pretty quiet around here, and at least part of the reason is that we’ve been pretty tight-lipped about what we’ve been up to. We’ve now gone public—we’re providing support for geospatial data in our next version of SQL Server, codenamed Katmai. The Virtual Earth folks mentioned this in their blog (others, too) but now I can make a little more noise.

What I’d like to do first is try to explain to the folks out there who aren’t experts in the field what this all means and give a very high-level tour of what we’re providing.

First, what is geospatial data? For starters, we mean locations on the Earth. It’s more than location, though: we mean the location and shape of objects on the Earth. Think of the description of roads, states, lakes, etc. For example, think of something like Live Maps:

In addition to the normal objects, I’ve added a polygon that shows Microsoft’s main campus. We want to be able to store all of the data on this map—the roads, the parks, and user-generated polygon—in SQL Server. Being a database, we want to be able to ask questions about the data. For example, “What are the roads that intersect Microsoft’s main campus?” A more complex example would be “What is the area of all parks within 1 kilometer of Microsoft’s main campus?”

How do we do this? First, we need new data types to be able to store this information. Toward this end, we are introducing two new types in Katmai:

· The first type, “geography”, will store points, lines, polygons, and collections of these in latitude/longitude coordinates using a round-Earth model. Most commonly-available data is given in latitude/longitude coordinates, so we expect that most people will want to use this type. Furthermore, this type will give correct computations on a true ellipsoidal model of the planet. What is the area of Indonesia? Will my flight from Seattle to Beijing take me over North Korea? Where can I store my GPS readings? This is the type for you.

· A “geometry” type to support flat-earth data. For those of you who are familiar with such things, this type is our OGC-compliant offering. In some ways, this is a more specialty offering for people who need to work in projected map coordinates either for legacy or legal reasons, but this type can be used for things like interior spaces as well, e.g., “Where in this warehouse is my book?”

If we take our roads data above—perhaps all of the roads for the United States—we could store them in a table Roads:

Roads(name varchar(30), location geography)

I.e., geography is a column type just like any other. We expose a pretty comprehensive set of operations on these type through a method-based interface. For example, if we have a geometry variable @microsoft that represents Microsoft’s main campus, we can find out which roads intersect it with the query:

SELECT name
FROM Roads
WHERE location.STIntersects(@microsoft) = 1

Given a similar Parks table containing all US parks, we can ask our parks question from above:

SELECT SUM(location.STArea())
FROM Parks
WHERE location.STDistance(@microsoft) < 1.0

Of course, beyond answering this query, we need to be able to answer the query quickly. Since my data may be very large, speed is going to mean having a good spatial index. Perhaps that will be the subject of my next post. Watch this space for more.

Cheers,
-Isaac

Isaac @ MSDN : live maps

SQL Server Spatial Support: An Introduction