Types de données spatiales
Il existe deux types de données spatiales. Le type de données geometry prend en charge les données planaires, ou Euclidiennes (monde en deux dimensions). Le type de données geometry est conforme à la spécification Open Geospatial Consortium (OGC) Simple Features for SQL version 1.1.0.
De plus, SQL Server prend en charge le type de données geography, qui stocke des données ellipsoïdes (monde sphérique), telles que des coordonnées GPS de latitude et de longitude.
Les types de données geometry et geography prennent en charge onze objets de données spatiaux, ou types d'instances. Toutefois, seuls sept de ces types d'instances sont instanciables ; vous pouvez créer et travailler avec ces instances (ou les instancier) dans une base de données. Ces instances dérivent certaines propriétés de leurs types de données parents qui les distinguent comme Points, LineStrings, Polygons, ou comme instances geometry ou geography multiples dans une GeometryCollection.
La figure ci-dessous représente la hiérarchie geometry sur laquelle les types de données geometry et geography sont basés. Les types instanciables de geometry et geography sont indiqués en bleu.
.gif "Hiérarchie du type geometry")
Comme la figure l'indique, les sept types instanciables des types de données geometry et geography sont Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon et GeometryCollection. Les types geometry et geography peuvent reconnaître une instance comme spécifique du moment qu'il s'agit d'une instance bien formée, même si l'instance n'est pas définie de manière explicite. Par exemple, si vous définissez explicitement une instance Point à l'aide de la méthode STPointFromText(), geometry et geography reconnaissent l'instance comme un Point, du moment que l'entrée de méthode est de forme correcte. Si vous définissez la même instance à l'aide de la méthode STGeomFromText(), les types de données geometry et geography reconnaissent l'instance comme un Point.
Pour plus d'informations sur ces instances, consultez les rubriques suivantes :
Différences entre les deux types de données
Les deux types de données spatiales se comportent souvent à peu près de la même façon, mais il existe des différences clés dans la façon dont les données sont stockées et manipulées.
Comment sont définies les arêtes de connexion
Les données de définition concernant les types LineString et Polygon sont uniquement des sommets. L'arête reliant deux sommets dans un type geometry forme une ligne droite. Toutefois, l'arête reliant deux sommets dans un type geography est un grand arc elliptique court entre les deux sommets. Une grande ellipse correspond à l'intersection de l'ellipsoïde avec un plan passant par son centre tandis qu'un grand arc elliptique est un segment d'arc sur la grande ellipse.
Mesures dans les types de données spatiales
Dans le système planaire, ou monde en deux dimensions, les mesures de distances et de surfaces sont données dans la même unité de mesure que les coordonnées. Avec le type de données geometry, la distance entre (2, 2) et (5, 6) est 5 unités, quelles que soient les unités utilisées.
Dans le système ellipsoïdal, ou monde sphérique, les coordonnées sont données en degrés de latitude et de longitude. Toutefois, les longueurs et surfaces sont généralement mesurées en mètres et en mètres carrés, bien que la mesure puisse dépendre de l'identificateur de référence spatiale (SRID) de l'instance geography. L'unité de mesure la plus courante pour le type de données geography est le mètre.
Orientation des données spatiales
Dans le système planaire, l'orientation d'anneau d'un polygone n'est pas un facteur important. Par exemple, un polygone décrit par ((0, 0), (10, 0), (0, 20), (0, 0)) est le même qu'un polygone décrit par ((0, 0), (0, 20), (10, 0), (0, 0)). La spécification OGC Simple Features for SQL ne stipule pas d'ordonnancement d'anneau et SQL Server n'applique pas d'ordonnancement d'anneau.
Dans un système ellipsoïdal, un polygone n'a aucune signification, ou est ambigu, sans orientation. Par exemple, un anneau autour de l'équateur décrit-il l'hémisphère Nord ou Sud ? Si nous utilisons le type de données geography pour stocker l'instance spatiale, nous devons spécifier l'orientation de l'anneau et décrire précisément l'emplacement de l'instance.
SQL Server 2008 impose les restrictions suivantes sur l'utilisation du type de données geography :
Chaque instance geography doit être contenue à l'intérieur d'un seul hémisphère. Aucun objet spatial plus grand qu'un hémisphère ne peut être stocké.
Toute instance geography d'une représentation WKB (Well-Known Binary) ou WKT (Well-Known Text) OGC (Open Geospatial Consortium) qui produit un objet plus grand qu'un hémisphère lève une ArgumentException.
Les méthodes de type de données geography qui requièrent l'entrée de deux instances geography, telles que STIntersection(), STUnion(), STDifference() et STSymDifference(), retournent Null si les résultats des méthodes ne s'ajustent pas à l'intérieur d'un seul hémisphère. STBuffer() retourne également Null si la sortie dépasse un seul hémisphère.
Les anneaux internes et externes ne sont pas importants dans le type de données geography
La spécification OGC Simple Features for SQL discutent des anneaux externes et internes, mais cette distinction n'a que peu de sens pour le type de données SQL Servergeography : tout anneau d'un polygone peut être pris comme étant l'anneau externe.
Pour plus d'informations sur les spécifications OGC, reportez-vous aux sites Web suivants :
OGC Specifications, Simple Feature Access Part 1 - Common Architecture (en anglais)
OGC Specifications, Simple Feature Access Part 2 – SQL Options (en anglais)