|
Posted by Paul Cooper on May 22, 2008, 9:22 am
Please log in for more thread options
On Thu, 22 May 2008 12:04:36 +0200, Luca Morandini
>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
>ring.>>
>
>This doesn't make sense to me... or there is something that I grossly
>ignore ?
>
>Regards,
>
>--------------------
> Luca Morandini
>www.lucamorandini.it
>--------------------
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
| 
XML Sitemap