Microsot SQLServer 2008 data types

Folks,

yesterday have talked to a Microsoft representative, and learned about
the two spatial data types of SQLServer 2008; AFAIK, this would be the
only implementation having two different data types to store spatial data.

Today I dug a little deeper, and was rather surprised by reading on the
MSDN site:
<<The two types of spatial data often behave quite similarly, but there
are some key differences in how the data is stored and manipulated.
Measurements in Spatial Data Types

In the planar, or flat-earth, system, measurements of distances and
areas are given in the same unit of measurement as coordinates. Using
the geometry data type, the distance between (2, 2) and (5, 6) is 5
units, regardless of the units used.

In the ellipsoidal, or round-earth system, coordinates are given in
degrees of latitude and longitude. However, lengths and areas are
usually measured in meters and square meters, though the measurement may
depend on the spatial reference identifier (SRID) of the geography
instance. The most common unit of measurement for the geography data
type is meters.
Orientation of Spatial Data

In the planar system, the ring orientation of a polygon is not an
important factor. For example, a polygon described by ((0, 0), (10, 0),
(0, 20), (0, 0)) is the same as a polygon described by ((0, 0), (0, 20),
(10, 0), (0, 0)). The OGC Simple Features for SQL Specification does not
dictate a ring ordering, and SQL Server does not enforce ring ordering.

In an ellipsoidal system, a polygon has no meaning, or is ambiguous,
without an orientation. For example, does a ring around the equator
describe the northern or southern hemisphere? If we use the geography
data type to store the spatial instance, we must specify the orientation
of the ring and accurately describe the location of the instance.

SQL Server 2008 places the following restrictions on using the geography
data type:

* Each geography instance must fit inside a single hemisphere. No
spatial objects larger than a hemisphere can be stored.
* Any geography instance from an Open Geospatial Consortium (OGC)
Well-Known Text (WKT) or Well-Known Binary (WKB) representation that
produces an object larger than a hemisphere throws an ArgumentException.
* The geography data type methods that require the input of two
geography instances, such as STIntersection(), STUnion(),
STDifference(), and STSymDifference(), will return null if the results
from the methods do not fit inside a single hemisphere. STBuffer() will
also return null if the output exceeds a single hemisphere.

Outer and Inner Rings Not Important in geography Data Type

The OGC Simple Features for SQL Specification discusses outer rings and
inner rings, but this distinction makes little sense for the SQL Server
geography data type: any ring of a polygon can be taken to be the outer

This doesn't make sense to me... or there is something that I grossly
ignore ?

Regards,

--------------------
Luca Morandini
www.lucamorandini.it
--------------------

On Thu, 22 May 2008 12:04:36 +0200, Luca Morandini



It means that Microsoft are doing their usual thing of ignoring well
established standards. The OGC Simple Feature specification is
paralleled by the ISO TC211 standards, including the standard for
spatial extensions to SQL, is embedded in GML and is a fundamental
standard. It is apparent from your description that Microsoft a re
(being charitable) ignorant of the strength of standards in this area.

Use PostGIS/Postgresql; it is an industrial strength database with
full support for the relevant standards. It is also open-source and
free at point of use!

Paul

Paul Cooper wrote:

Two things:
1) It is not my description, it is what is written on the MSDN site [1].
2) They claim to respect Simple Features for SQL, but only for their
"geometry" type, not for the "geography" one, since:
<<The OGC Simple Features for SQL Specification discusses outer rings
and inner rings, but this distinction makes little sense for the SQL
Server geography data type: any ring of a polygon can be taken to be the



Thanks, I'm aware of it: I've used many a spatially-enabled DBMS.

Regards,

[1] http://msdn.microsoft.com/en-us/library/bb964711 (SQL.100).aspx

--------------------
Luca Morandini
www.lucamorandini.it
--------------------

This is very unusual. Normally the restriction would by that objects can not
cross the dateline.