GETTING YOUR PROGRAMS READY FOR THE UPCOMING GEOGRAPHY COORDINATE ORDER SWAP

For those of you who have programs which work with November CTP (CTP-5) and February CTP (CTP-6) and use the Geography data type, you should already be aware of Isaac's posts on this subject: Latitude-Longitude Ordering and The Upcoming Geography Coordinate Order Swap---A FAQ.

The next CTP, most likely called the May CTP (CTP-6 Refresh), will contain the Geography data type coordinate order swap for WKT/WKB-based geographic coordinates. In order to make sure that your programs work correctly with all SQL Server 2008 CTP's and RTM, you will need a way of detecting the version of SQL Server after which the change was made.  The last publicly available SQL Server 2008 build was CTP-6, which had a product version number of 10.0.1300.13.  The next publicly available SQL Server 2008 build will contain the Geography coordinate order swap, so this product version number (10.0.1300.13) should be used as the switch point.

The product version string is constructed as follows: <Major Version>.<Minor Version>.<Build>.<Revision>

So, how do you retrieve the product version number? One way to do this would be to issue the SQL query:

 SELECT @@version

which will yield something like this:

Microsoft SQL Server code name "Katmai" (CTP) - 10.0.1300.13 (Intel X86)   Feb  8 2008 00:06:52   Copyright (c) 1988-2007 Microsoft Corporation  Developer Edition on Windows NT 6.0 <X86> (Build 6001: Service Pack 1, v.744)

from which you can extract the product version number. You can also use the ProductVersion SERVERPROPERTY value to avoid parsing the entire @@version string:

SELECT SERVERPROPERTY('ProductVersion')

which will yield something like the following:

10.0.1300.13

In previous releases, SQL Server has had 00's in the minor version number.  Consequently, you should not rely on string comparison to do a numeric sort as 10.00.1300.13 would cause a difference in sort order than 10.0.1300.13.

If you are using .NET code, you can reuse the System.Version class for this purpose and extract the product version components from there.  If you already have a check somewhere in your program to determine if you are running against SQL Server 2008, it might make sense to consolidate the version checks in one spot.

 

TRAVELING WITH SQL SERVER 2008 SPATIAL

I travel quite a bit and have the need to carry a bit of equipment with me. This includes a laptop with the latest version of SQL Server 2008 (spatially-enabled, of course) and a geospatial data capture device - a Nikon D300 equipped with a special GPS receiver (di-GPS, described later). As many of you may know, traveling with a digital SQL and a laptop can be a difficult proposition. I have been searching for a backpack which can hold a laptop, a digital SLR, a lot of ancillary "stuff" (power supplies, cables, books, etc.) and can fit under the seat of MD-80's, 737's, etc.

I recently purchased a Lowepro CompuTrekker AW and it fits my criteria almost perfectly:

IMG_0058

The backpack has 3 compartments.  One that holds the laptop (and a magazine or two), one that holds documents, pens, etc. and the main section which is designed to hold photo equipment.  The next photo show the backpack's main compartment loaded with my equipment:

IMG_0059 

To show how much stuff the backpack can hold, here it is unloaded:

OpenBag_ContentsExternal

Here is the backpack under the seat of a 737:

UnderSeat_1

It can even be stuffed into the incredibly tiny space under some 737 and MD-80 seats. Here is the backpack stuffed into the small space under a 737's isle seat:

 UnderSeat_2

For those of you with questions on the di-GPS unit, check out http://www.di-gps.com/di-GPS/n2.htm.  The unit only works on selected Nikon digital SLR's.  It draws power from the camera's internal battery and writes NMEA-based GPS data to the EXIF metadata of the Nikon's JPG, NEF (raw) or TIFF image files. A nice feature of the di-GPS unit is that it can be mounted on the camera strap:

 

This allows the GPS receiver to be exposed outside of the Lowepro backpack, while the camera is safely ensconced inside. This can be done placing the GPS receiver between the two zippers securing the main compartment holding the Nikon camera. The picture below shows the GPS receiver on the outside of the pack, if you look carefully (I've placed a red circle around the unit):

External_GPS

CHANGING THE BLOG NAME...

By popular request (well, at least the request of Abe on Spatially Adjusted...), I've changed the name of the blog from "Ed on Spatial" to "Spatial Ed". 

This should cause some interesting confusion...
SQL SERVER SPATIAL BUGS...

As part of the Microsoft SQL Server 2008 February CTP Bug Bash Contest, we are looking for spatial bugs!  The entrant with the largest number of reproducible non-duplicate SQL Server 2008 Spatial bugs submitted during the entry period will win an Xbox Elite.  At last check, we had 1 entrant with 1 bug - surely there must be more...  Hurry, the Bug Bash ends at 11:59PM PT on March 15, 2008.

Please go to:
https://connect.microsoft.com/SQLServer/content/content.aspx?ContentID=7734
to get started.

Make sure that you select the checkbox “This entry is for the SQL Server 2008 February CTP Bug Bash Contest.”  If your entry does not include this option, it will automatically not be counted. 

The Xbox is coming out of my budget and I want my money's worth - let’s see those bugs!

 

Introduction

Welcome to my first blog effort. Many of you in the spatial world may already know me.  For everyone else, I am the Spatial Program Manager for SQL Server.  I’ve been working in the spatial/GIS field much longer than I wish to admit, with prior engagements at Informix Software and IBM in the recent past.

Between Isaac (http://blogs.msdn.com/isaac/) and myself, we should have SQL Server Spatial and related areas of interest pretty well covered.

 

Thanks,

Ed Katibah
Microsoft SQL Server Spatial

NEW SPATIAL FEATURES IN The SQL SERVER 2008 FEBRUARY CTP

Now that the February CTP (CTP-6) for SQL Server 2008 is available, it's time to let folks know what new spatial features have been added or updated since the November CTP (CTP-5).

Before I get into the new and updated features, I want to make sure that it is clear that the latitude-longitude coordinate ordering switch, which we will be making for the Geography type, is not in CTP-6. Please see http://blogs.msdn.com/isaac/archive/2007/12/27/latitude-longitude-ordering.aspx for more information

Here are the new and updated features:

Degenerate Polygons are now collapsed to LineStrings or Points instead of to Empty.  Previously, if you had a Polygon with a very thin spike and ran an operation on it, there was a good chance that the spike would disappear entirely.  Additionally, in some cases, STIntersects between two Polygons would return 1, however the STIntersection would return GeometryCollection Empty because the resultant intersection was considered to be a degenerate Polygon.  Another example of this behavior is seen in the following post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2709103&SiteID=1 where a small buffer on a large LineString produced a MultiPolygon which looked like a dashed-line as portions of the resultant very thin Polygon were considered degenerate and collapsed to empty.  In CTP-6, this will return a GeometryCollection with LineString segments connecting all of the original MultiPolygon segments together.

Reduce (Douglas-Peucker -based Generalization).  Because of the above change, we were able to remove the exception that would occur when you ran Reduce on a Geometry that would produce an invalid output.  Instead, we call MakeValid on the result, which, although it may alter the type or structure of the original Geometry, will not collapse it to Empty. For example, in CTP-5 the call:

SELECT geometry::Parse('POLYGON ((0 0, 0 10, 10 10, 10 0, 0 0))').Reduce(10).ToString()

would throw an exception saying that the method could not be completed  because the result would be Invalid.  In CTP-6, it will return:

LINESTRING(10 10, 0 0)

In addition, the Reduce method was added to the Geography type.  Given a tolerance in the units of the SRID defining the Geography, Reduce will apply the Douglas-Peucker algorithm to return a simplified version of the Geography data.  Since the Reduce method is intended for scenarios where speed and simplicity is more important than accuracy, determining if a vertex is within tolerance to the line will not be computed by using the precise geodetic distance.  Instead, the distance will be computed as the great circle distance on the sphere defined by the average of the ellipsoid's semi-major and semi-minor radii.  While this is less accurate, it is significantly faster to compute.

Filter. Filter is a new method added to both types that provides a fast index-only intersects method that may produce false-positives (a.k.a. a primary filter). It does this by returning all objects in the cells of the index which contain the parameter object, without running the full spatial STIntersects test to determine whether they actually intersect.   If no index is defined on the table or the index is not used in the query or the method is used on the client directly, then the method behavior maps exactly to that of STIntersects. This method is useful for scenarios where it is important to quickly determine whether there are any candidate intersections, or to quickly return the candidate objects to a specialized client, such as a graphics canvas, which does not care if there is a true intersection at the edges of the display.

EnvelopeCenter and EnvelopeAngle (Geography data type). The methods EnvelopeCenter and EnvelopeAngle were added to the Geography type.  These two methods allow users to fetch a simple description for the bounds of a geodetic object.  The corresponding operation (STEnvelope) on Geometry does not make sense on the earth, as it returns a bounding box with straight lines that cannot be represented on the ellipsoid.  We instead return a bounding circle, which is not guaranteed to be the minimal possible bounding circle.  This is the same bounding circle we use to determine if a Geography fits inside a hemisphere.

EnvelopeCenter(): Returns the point described by the vector sum of the points in the Geography.  For closed loops, either in a Polygon or a LineString, the duplicate first/last point is used only once.  This point will not correspond to the true Centroid of the Geography.

EnvelopeAngle():  Returns the maximum angle between the point returned by EnvelopeCenter and a point in the Geography in degrees.  The maximum value for this method is 90, as otherwise the Geography would be considered to exceed a hemisphere.

STDistance (GEOGRAPHY data type). In CTP-5, STDistance could only be calculated on Geography instances if one of the inputs was a Point object.  This restriction has now been removed, and STDistance can be calculated on any pair of Geography objects.

We will have a few more changes to Spatial coming in the next CTP (including the aforementioned latitude-longitude coordinate order switch). These changes will be discussed when we are closer to release.

 

Search

Go

This Blog

Syndication

Page view tracker