It has always been possible to work with geospatial data in SQL Server using built-in geometric and trigonometric functions such as SIN(), COS(), and ACOS(). However, SQL Server 2008’s spatial data types made complex spatial queries a lot more accessible to those of us who don’t remember what a cosine actually is. In this article, I will show you how to use these built-in functions within a user-defined function (UDF) to illustrate the traditional method of calculating distances between geographic points. I will use both traditional T-SQL methods and the new spatial data types in SQL Server 2008 as examples. I will also compare the performance of the two methods.


For the purpose of this article, I will assume you recognize the terms latitude and longitude and know that the earth is sort of round. I will also assume you have a basic familiarity with reading and writing T-SQL code. To follow the examples, you will need SQL Server 2008 or later.

Complete coverage of all the complex issues surrounding geospatial data calculations would require a much longer article. Although a deep understanding of geospatial data is required for some types of applications, many business applications have relatively simple geospatial needs, such as calculating shipping charges based on the distance between two ZIP codes or displaying the location of your nearest retail outlets on a map on your website based on a ZIP code entered by a visitor to the site. These types of queries have a common goal: to find the distance between geographical points. In some cases, they return the distance between two specific points, and in other cases they return the identity of all points within a certain distance of a center point. By the end of this article, even the most geometry-challenged programmer will be able write queries like these, using both traditional methods and the new spatial data types.

Using Legacy T-SQL for Geospatial Calculations

Listing 1 contains the code for a conventional UDF that calculates linear distances between two points on the surface of a sphere. Functions like this one represent a method of working with geographical data that was typical before spatial data types were introduced in SQL Server 2008.

As you can see, this function takes the latitude and longitude values of two geographic points and returns the distance between them in miles. It’s a little easier to understand the calculation if you know the following things:

  • The latitude and longitude values we will work with are stated in decimal degrees. The T-SQL SIN() and COS() functions expect those values to be in radians, so we convert them using the RADIANS() function.
  • The subtraction in this function is necessary because lines of longitude are not parallel to each other as are the lines of latitude. Lines of longitude converge at the poles and are at their widest separation at the equator. The distance between them is a function of the latitude of the points.
  • The distance between degrees of latitude varies slightly from pole to equator, but the difference is small enough that it can be ignored for most purposes. A good compromise is 111,200 meters for latitudes in temperate zones. You don’t see this figure in this function, but it is used later in our optimization example.

We will use this function to compare the performance of legacy T-SQL methods to the new geospatial methods. You will notice some slight differences in results because of the differing precision of conversion factors in the two methods. However, the differences are trivial for most business applications. At any rate, you should not mix the computational methods in your applications, so your results should remain consistent.

Using SQL Server 2008’s Spatial Data Types

SQL Server 2008 introduced two spatial data types: Geometry and Geography. Both Geometry and Geography support a subset of the objects and functions prescribed by the Open Geospatial Consortium (OGC). I will not discuss the OGC standard here, but you can visit OGC website.

Geometry and Geography are complex data types, implemented as CLR assemblies. Because the assemblies are registered by default, you don’t need to do anything special to enable them. You will declare spatial types as you would any other data type.

By complex data types, I mean not only that these data types can contain multiple discrete values but also that they have methods and properties that can be accessed by your T-SQL code. In T-SQL, these methods are commonly referred to as functions, but they are accessed differently than normal T-SQL functions. Also, the function names are case-sensitive no matter what collation the database uses. The following is an example of a spatial function call:

  1. SELECT Point1.STDistance(Point2)

This statement returns the distance between two points on the earth’s surface. Point1 is a value of the Geography data type that holds latitude and longitude coordinates. This value is followed by a period and the case-sensitive name of the method. The method STDistance() takes a single parameter that represents another point value of the Geography data type. This seems to be a simple way to obtain the same result as the traditional T-SQL function in Listing 1.

The following are a couple of additional frequently used functions of the Geography data type:

  • Point1.Lat returns the latitude of Point1. Point1.Long returns the longitude.
  • Object1.STIntersection(Object2) returns the point at which lines or polygons represented by Object1 and Object2 intersect.

The basic difference between the Geometry and Geography types is that Geography deals with round-earth coordinates—latitude and longitude. Geometry deals with flat surfaces using arbitrary Cartesian coordinate systems. In this article and the examples, I will work only with Geography data, as that is the type most commonly used for business applications. My examples use point data, although the spatial data types also support complex lines and polygons.

Spatial data types let you code solutions such as those previously mentioned without wading through cosine and arctangent functions to calculate linear distances on the surface of a sphere. The methods contained in the data type itself can make this calculation automatically and very accurately, as well as a variety of other complex calculations.

In addition to the spatial data types, Microsoft introduced a spatial index. We will look at the performance of spatial indexes in the upcoming examples.

Loading the Sample Data

I used the ZIP code data from the US Census Bureau for the examples because it is a body of spatial data that is a reasonable size and free and simple to download. You can create a test database to run this project or download one of the Microsoft sample databases.

There are many ways to load this flat file into SQL Server. The code in Listing 2 begins by creating and populating the ZipCodes table using OPENROWSET with the bulk load option.

Listing 3 provides the code of the format file used by the OPENROWSET function. Save this file as a .xml file before you try to run the OPENROWSET function. The path and filename used in Listing 2 is C:\GEO\zcta5format.xml. If you use that name and location to save the file, be sure to change the file path in the OPENROWSET function.

After making some necessary changes to the table, the script then updates the table to load the same latitude and longitude values into the spatial column GEO. Note that the UPDATE statement imports the data from the latitude and longitude columns into the Geography data type. It uses the STPointFromText() spatial function to insert point data as a string formatted in the Well-Known Text (WKT) format that is supported by OGC. As you can see, the WKT string starts with the type of geography to be created, followed in this case by the longitude and latitude of the point. This string is followed by a comma and a numeric Spatial Reference ID (SRID). The SRID identifies the type of coordinates, the units of measurement, and the particular model of the earth represented by your geography data. (That is a gross over-simplification of a complex topic, but it will do for our purposes). All your spatial data should have the same SRID.

Until you get to the point in which you know why you might want to use another SRID, stick with SRID 4326. This is the SRID used by GPS devices and is the SRID you will encounter most often. Because SRID 4326 uses the meter as its distance unit, US users will typically need to use the following conversion values to convert function results into miles, and vice-versa:

  • Meters to miles: *0.000621371192
  • Miles to meters: *1609.344

Finally, Listing 2 creates three indexes: a clustered primary key on the latitude and longitude columns, a nonclustered index on the ZIP code, and a spatial index on GEO. At this point you should use Listing 1 to create the UDF that we previously examined.

Going Postal

Since our data is all about ZIP codes, our examples will be postal in nature. Let’s assume that the geographic coordinates of the ZIP code describe the physical location of the post office itself (which is not strictly true of this data).

Example 1: Finding the distance between ZIP codes. In our first example, an eCommerce site needs to find the distance between its warehouse and the delivery ZIP code to calculate shipping charges for an order. Listing 4 contains the code for two queries that accomplish this task. The first query uses spatial data types and the second query uses a more traditional T-SQL approach by calling the UDF to perform the calculations.

You might notice in Listing 4 is that there is substantially less code to write when you use spatial types. And both statements consume a very small amount of resources in using the traditional indexes. The resource usage, as captured by SQL Server Profiler, is essentially equal for both forms of the query.

Example 2: Finding all locations within a specified radius. Let’s assume that the US Postal Service wants to display a map on its website showing the location of all the nearby post offices based on the ZIP code you enter. Listing 5 contains two queries that accomplish this task. As in the previous example, the first query uses spatial data types, and the second uses our T-SQL UDF.

Both of the queries in Listing 5 return the location of the same 149 post offices. However, when you look at the cost of the two queries, you find that the query that uses spatial data types is far more expensive in terms of disk I/O. The legacy T-SQL method finished with 119 page reads on a partial scan of the clustered index. There were 3,300 page reads required for the spatial version—far more than the 476 pages that exist in the table itself. The spatial query performed slightly better than the UDF version in terms of duration and CPU usage.

The problem with spatial data is that there is often a lot of it. Multimillion-row tables are the rule rather than the exception when dealing with geographic points. Because our sample data contains only about 33,000 rows, we do not see the full effect of the potentially critical problem that can be posed by a table of several million rows.

Many common data retrieval operations, such as the previous radius query, involve calculations to filter the data. Calculations or function calls in a WHERE clause often prevent indexes from being used. The problem is that the database engine doesn’t know the distance to any ZIP code in the table until it takes that row and runs the function, using the row values. This means that the database engine must run the function for every row in the table before it can determine which rows to return. The result is a full table scan on a huge table.

Example 3: Squaring the circle. A practical way to optimize a radius query is to limit the number of rows on which the distance calculation must be performed. Consider our radius query. It is obvious that all the points within that circle with a 50-mile radius must also lie within a 100-mile square that has the same center point.

You can use the coordinates of the center point and the length of the radius to calculate the latitude and longitude of four points that define the corners of the square. Ninety-nine percent of the rows in the table can be eliminated by a preliminary index seek that passes only the few points in the square to the distance function. This makes the query orders of magnitude faster on large data sets. However, you will see in this example that spatial data types and spatial functions do not take advantage of this kind of optimization. Listing 6 contains both forms of the query.

After running both versions of the query, you will find that the query using spatial data types to filter the latitude and longitude columns is significantly more expensive than the filter using normal indexes. Traditional T-SQL filtering on the latitude and longitude columns performs 26 page reads to return the data. But the spatial query requires 3,274 page reads because it performs a full scan of the full spatial index and also a full scan of the clustered index. The execution time of the two versions is not significantly different in this relatively small table, but full table scans on much larger collections of spatial data could be a show-stopper.

As a further optimization, I included a distance function in both forms of the query to exclude all points outside the radius to confirm that we would get the same results as the previous radius query. However, if you are placing the retrieved points on a square map on a website, it might make more sense to eliminate the distance function altogether and display all points found within the square.

Query Performance

Logical I/O is arguably the most dependable measurement of query performance. By that metric, traditional methods seem to provide much better performance than spatial data types. However, the two forms of the query are much closer in terms of other measures such as CPU usage and duration. In some cases, the spatial function actually performs better than the UDF by those metrics.

In searching for a reason for the big disparity in page reads, I speculated that indexing on the table, particularly the clustered index on latitude and longitude, might promote artificially efficient range queries on those values. In the real world, that might not be the most efficient overall indexing plan. Perhaps spatial data types might compare more favorably in a different indexing scheme. I tested this theory with a couple of different indexing schemes that I thought might be appropriate for a table like this. The numbers changed somewhat, but the huge disparity in logical reads remained in all the indexing schemes I tried.

Still, you must remember that this was not an exhaustive performance analysis. I tested performance on only a single aspect of spatial data types. It would be wrong to conclude that spatial data types and functions are inherently less efficient.

The primary benefit of spatial data types is their ease of use in manipulating geospatial data in various complex ways. The simple examples in this article did not fully display this enhanced functionality. If spatial types provide adequate performance, their functionality should make up for a slight degree of inefficiency (if, in fact, there is one).

Other Spatial Data Functionality

I explored only a small part of the functionality available through spatial data types. Querying geographical point data might be the most common application, but spatial data types are capable of doing much more. Spatial data types support points, linestrings, and polygons, as well as collections of those types. SQL Server supplies about two dozen functions to work with those shapes in various ways. For example, you can define a polygon of virtually any shape and then calculate its area with a simple function call.

It is this additional functionality that differentiates spatial data types from traditional T-SQL. Although a good programmer or geometrician can reproduce the same complex functionality using pure T-SQL, this requires a huge amount of work, and the number of programmers with the necessary mathematical background is relatively small. Spatial functions give you the capability to do extraordinarily complex things with geographic or geometric data, without coding complex formulas. If you would like to dive a little deeper into working with spatial data, see Alistair Aitchison’s book Beginning Spatial with SQL Server 2008 (Apress).

  1. CREATE FUNCTION dbo.DistanceInMiles
  2. (@LatA FLOAT = NULL,
  3. @LongA FLOAT = NULL,
  4. @LatB FLOAT = NULL,
  5. @LongB FLOAT = NULL
  6. )
  8. AS
  9. BEGIN
  10. DECLARE @Distance FLOAT
  11. SET @Distance = (SIN(RADIANS(@LatA)) *
  12. SIN(RADIANS(@LatB)) +
  13. COS(RADIANS(@LatA)) *
  14. COS(RADIANS(@LatB)) *
  15. COS(RADIANS(@LongA - @LongB)))
  16. -- Convert to miles
  17. SET @Distance = CAST( (DEGREES(ACOS(@Distance))) * 69.09 AS DECIMAL(9,1))
  18. RETURN @Distance
  19. END
  20. GO

  1. -- Load data and prepare table
  3. GO
  4. IF OBJECT_ID('ZipCodes', 'U') IS NOT NULL
  5. DROP TABLE ZipCodes
  6. GO
  7. -- openrowset creates table and loads data
  8. SELECT *
  9. INTO Zipcodes
  10. FROM OPENROWSET(BULK 'C:\GEO\zcta5.txt',FORMATFILE = 'C:\GEO\zcta5format.xml') AS Z
  11. ALTER TABLE ZipCodes DROP COLUMN deleteme;
  12. ALTER TABLE ZipCodes ADD GEO geography;
  17. -- copy data into spatial data type
  18. UPDATE \\[dbo\\].\\[ZipCodes\\]
  19. SET \\[GEO\\] =
  20. geography::STPointFromText('POINT('
  21. + CAST(\\[Longitude\\] AS VARCHAR(20)) + ' ' +
  22. CAST(\\[Latitude\\] AS VARCHAR(20)) + ')', 4326)
  23. GO
  24. -- add indexes
  25. ALTER TABLE ZipCodes ADD PRIMARY KEY (latitude, longitude);
  28. GO
  29. -- create udf for legacy examples
  30. CREATE FUNCTION dbo.DistanceInMiles
  31. (@LatA FLOAT = NULL,
  32. @LongA FLOAT = NULL,
  33. @LatB FLOAT = NULL,
  34. @LongB FLOAT = NULL
  35. )
  37. AS
  38. BEGIN
  39. DECLARE @Distance FLOAT
  40. SET @Distance = (SIN(RADIANS(@LatA)) *
  41. SIN(RADIANS(@LatB)) +
  42. COS(RADIANS(@LatA)) *
  43. COS(RADIANS(@LatB)) *
  44. COS(RADIANS(@LongA - @LongB)))
  45. -- Convert to miles
  46. SET @Distance =
  47. CAST( (DEGREES(ACOS(@Distance))) * 69.09 AS DECIMAL(9,1))
  48. RETURN @Distance
  49. END
  50. GO

  1. <?xml version="1.0" ?>
  2. - <BCPFORMAT xmlns="" xmlns:xsi="">
  3. - <RECORD>
  4. <FIELD ID="f01" xsi:TYPE="CharFixed" LENGTH="2" />
  5. <FIELD ID="f02" xsi:TYPE="CharFixed" LENGTH="5" />
  6. <FIELD ID="f03" xsi:TYPE="CharFixed" LENGTH="59" />
  7. <FIELD ID="f04" xsi:TYPE="CharFixed" LENGTH="9" />
  8. <FIELD ID="f05" xsi:TYPE="CharFixed" LENGTH="9" />
  9. <FIELD ID="f06" xsi:TYPE="CharFixed" LENGTH="14" />
  10. <FIELD ID="f07" xsi:TYPE="CharFixed" LENGTH="14" />
  11. <FIELD ID="f08" xsi:TYPE="CharFixed" LENGTH="12" />
  12. <FIELD ID="f09" xsi:TYPE="CharFixed" LENGTH="12" />
  13. <FIELD ID="f10" xsi:TYPE="CharFixed" LENGTH="10" />
  14. <FIELD ID="f11" xsi:TYPE="CharFixed" LENGTH="11" />
  15. <FIELD ID="f99" xsi:TYPE="CharTerm" TERMINATOR="\r\n" />
  16. RECORD>
  17. - <ROW>
  18. <COLUMN SOURCE="f01" xsi:TYPE="SQLCHAR" LENGTH="2" NAME="state" />
  20. <COLUMN SOURCE="f03" xsi:TYPE="SQLVARYCHAR" LENGTH="100" NAME="deleteme" />
  21. <COLUMN SOURCE="f04" xsi:TYPE="SQLBIGINT" NAME="population_tot" />
  22. <COLUMN SOURCE="f05" xsi:TYPE="SQLBIGINT" NAME="housing_tot" />
  23. <COLUMN SOURCE="f06" xsi:TYPE="SQLFLT8" NAME="water_area_meter" />
  24. <COLUMN SOURCE="f07" xsi:TYPE="SQLFLT8" NAME="land_area_meter" />
  25. <COLUMN SOURCE="f08" xsi:TYPE="SQLFLT8" NAME="water_area_mile" />
  26. <COLUMN SOURCE="f09" xsi:TYPE="SQLFLT8" />
  27. <COLUMN SOURCE="f10" xsi:TYPE="SQLFLT8" />
  28. <COLUMN SOURCE="f11" xsi:TYPE="SQLFLT8" />
  29. ROW>

  2. DECLARE @Geo1 geography;
  3. DECLARE @Geo2 geography;
  4. -- get coordinates for warehouse
  5. SELECT @Geo1 = GEO
  6. FROM Zipcodes
  7. WHERE ZIP = '97219';
  8. -- get coordinates for delivery location
  9. SELECT @Geo2 = GEO
  10. FROM Zipcodes
  11. WHERE ZIP = '55437';
  12. -- return result as miles
  13. SELECT CAST((@Geo1.STDistance(@Geo2) * 0.000621371192) AS DECIMAL(9,1));
  15. DECLARE @WarehouseZip VARCHAR(5);
  16. DECLARE @DeliveryZip VARCHAR(5);
  17. DECLARE @LatWhs FLOAT;
  18. DECLARE @LongWhs FLOAT;
  19. DECLARE @LatDel FLOAT;
  20. DECLARE @LongDel FLOAT;
  21. SET @WarehouseZip = '97219';
  22. SET @DeliveryZip = '55437';
  23. -- get coordinates for warehouse
  24. SELECT @LatWhs = latitude,
  25. @LongWhs = longitude
  26. FROM Zipcodes
  27. WHERE ZIP = @WarehouseZip;
  28. -- get coordinates for delivery location
  29. SELECT @LatDel = latitude,
  30. @LongDel = longitude
  31. FROM Zipcodes
  32. WHERE ZIP = @DeliveryZip;
  33. -- return result as miles
  34. SELECT dbo.DistanceInMiles(@LatWhs, @LongWhs, @LatDel, @LongDel);

  2. DECLARE @geo1 geography
  3. , @RadMiles INT
  4. , @MaxMeters DECIMAL (12,2);
  5. SET @RadMiles = 50; -- radius of area searched
  6. SET @MaxMeters = @RadMiles *1609.344;
  7. -- get coordinates of entered zipcode
  8. SELECT @geo1 = GEO
  9. FROM \\[Zipcodes\\]
  10. WHERE ZIP = '97219';
  11. SELECT ZIP, GEO.Lat, GEO.Long
  12. FROM \\[ZipCodes\\]
  13. WHERE @geo1.STDistance(GEO) <= @MaxMeters;
  15. DECLARE @RadMiles FLOAT
  16. , @Lat_in FLOAT
  17. , @Long_in FLOAT;
  18. SET @RadMiles = 50; -- radius of area searched
  19. -- get coordinates of entered zipcode
  20. SELECT @Lat_in = latitude,
  21. @Long_in = longitude
  22. FROM Zipcodes
  23. WHERE ZIP = '97219';
  24. SELECT ZIP, latitude, longitude
  25. FROM ZipCodes
  26. WHERE dbo.DistanceinMiles
  27. (@Lat_in
  28. , @Long_in
  29. , latitude
  30. , longitude) <= @RadMiles;

  2. DECLARE @Center geography
  3. , @RadiusMile FLOAT
  4. , @RadiusMeter FLOAT
  5. , @OffsetLat FLOAT
  6. , @OffsetLong FLOAT
  7. , @latN FLOAT
  8. , @latS FLOAT
  9. , @longE FLOAT
  10. , @longW FLOAT;
  11. -- input the radius
  12. SET @RadiusMile = 50;
  13. SELECT @Center= GEO
  14. FROM Zipcodes
  15. WHERE ZIP = '97219';
  16. -- convert miles to meters
  17. SELECT @RadiusMeter = (@RadiusMile * 1609.344);
  18. -- Get offset of corners from center in degrees
  19. SELECT @OffsetLat = @RadiusMeter/111200;
  20. SELECT @OffsetLong = @RadiusMeter/(111200 * COS(radians(@Center.Lat)));
  21. -- calculate lat and long of corners
  22. SELECT @longW = (@OffsetLong - @Center.Long) * -1;
  23. SELECT @longE = @OffsetLong + @Center.Long;
  24. SELECT @latN = (@OffsetLat + @Center.Lat);
  25. SELECT @latS = (@Center.Lat - @OffsetLat);
  26. -- get all points within the square
  27. SELECT ZIP, GEO.Lat, GEO.Long
  28. FROM Zipcodes
  29. WHERE geo.Long < @longE AND geo.Long > @longW
  30. AND Geo.Lat < @latN AND Geo.Lat > @latS
  31. AND @Center.STDistance(GEO) <@RadiusMeter;
  33. DECLARE @CntrLat FLOAT
  34. , @CntrLong FLOAT
  35. , @RadiusMile FLOAT
  36. , @RadiusMeter FLOAT
  37. , @OffsetLat FLOAT
  38. , @OffsetLong FLOAT
  39. , @latN FLOAT
  40. , @latS FLOAT
  41. , @longE FLOAT
  42. , @longW FLOAT;
  43. -- input the radius
  44. SET @RadiusMile = 50;
  45. SELECT @CntrLat= latitude
  46. ,@CntrLong = longitude
  47. FROM Zipcodes
  48. WHERE ZIP = '97219';
  49. -- convert miles to meters
  50. SELECT @RadiusMeter = (@RadiusMile * 1609.344);
  51. -- Get coordinates of corners in degrees
  52. SELECT @OffsetLat = @RadiusMeter/111200;
  53. SELECT @OffsetLong = @RadiusMeter/(111200 * COS(radians(@CntrLat)));
  54. -- calculate lat and long of corners
  55. SELECT @longW = (@OffsetLong - @CntrLong) * -1;
  56. SELECT @longE = @OffsetLong + @CntrLong;
  57. SELECT @latN = (@OffsetLat + @CntrLat);
  58. SELECT @latS = (@CntrLat - @OffsetLat);
  59. -- get all points within the square
  60. SELECT ZIP, GEO.Lat, GEO.Long
  61. FROM Zipcodes
  62. -- this filter uses comparisons and standard indexes
  63. WHERE longitude < @longE AND longitude > @longW
  64. AND latitude < @latN AND latitude > @latS
  65. AND dbo.DistanceinMiles
  66. (@CntrLat
  67. , @CntrLong
  68. , latitude
  69. , longitude) <= @RadiusMile;