A travers ce troisième article, nous allons nous intéresser à la création d’élément géographique en nous concentrant particulièrement sur leur représentation textuelle connue (Well-Known Text – WKT) afin de comprendre comment déclarer ces éléments géographiques.
Liens vers les articles liés
Cet article s’inscrit dans la série dédiée aux types géographiques et géométriques :
Introduction au Well-Known Text
La représentation textuelle permet de définir des entités géographiques ou géométriques de manière humainement lisible.
Ces entités géographiques et représentation textuelle associée sont étroitement liés aux standards établis par l’OGC (Open Geospatial Consortium).
De cette manière, un élément défini pourra être représenté textuellement de la même façon, quelque soit le système sous-jacent.
Cette représentation en Well-Known Text (WKT) est la représentation textuelle lisible de sa version binaire Well-Known Binary (WKB) qu’il est également possible d’utiliser sur le système SQL Server 2008 et versions supérieures parmi bien d’autres systèmes.
Il existe d’autres représentations des données avec notamment des formats tel que le Geographical Markup Language (GML).
Types d’éléments
Evidemment, il existe plusieurs types d’éléments géométriques correspondant respectivement à des représentations de différentes données.
Ces types sont utilisables tant dans un contexte géométrique que géographique comme ici présenté.
Parmi ces types, on retrouve :
- Les points : POINT
- ex: Point d’intérêt, bornes, utilisateur…
- Les lignes ou polylignes : LINESTRING
- Les polygones : POLYGON
- ex: Parcelles, zones vertes…
Et les ensembles associés :
- Les ensembles de points dits “multipoints” : MULTIPOINT
- Les ensembles de lignes dits “multilignes” : MULTILINESTRING
- Les ensembles de polygones dits “multipolygones” : MULTIPOLYGON
- Les ensembles d’éléments : COLLECTION
L’ensemble de ces éléments peut être matérialisé sous la représentation suivante en termes d’architecture :
Ces types sont définis dans le document fourni par l’OGC qui s’intitule “OpenGIS Simple Features Specification for SQL” disponible à travers ce lien : http://portal.opengeospatial.org/files/?artifact_id=829
La prochaine version de SQL Server, pour le moment connu sous le nom de SQL Server “Denali” ajoute, en plus d’améliorer les opérations sur le type géographique, le support des types d’éléments suivants par les types d’élément dits “simples” :
L’ensemble des nouveautés concernant le domaine spatial dans la prochaine version SQL Server “Denali” est présenté ici : http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/Spatial_Denali_CTP1.docx
Je reviendrai sur ces nouveautés dans un article dédié qui, je pense, fera sens à la suite de cette série.
Construction des coordonnées
Les coordonnées sont les éléments de base définissant les informations géographiques associées à un point dans l’espace.
Ces coordonnées inclut les informations suivantes :
- Latitude
- Longitude
- Optionnels et avec un support limité
- Altitude
- Mesure – référence linéaire
Dans la construction des autres éléments, ces coordonnées sont utilisées dans chacune des définitions comme présenté ci-dessous.
Construction d’un point
La représentation textuelle d’un point correspond à l’écriture suivante :
POINT(COORDINATES) ou POINT(LONGITUDE LATITUDE)
Avec un exemple comme :
POINT(2.75 47.5)
Et en implémentation SQL Server :
DECLARE @center as geography
SET @center = geography::STPointFromText('POINT(2.75 47.5)', 4326)
Ce qu’il est important de noter à travers cette représentation, c’est l’utilisation du mot clé standard ‘POINT’ et la construction qui suit le schéma définissant la longitude dans un premier temps, puis la latitude dans un second temps. Le dernier paramètre de cette représentation correspond au SRID associé à cet élément géographique.
Pour plus de détails concernant le SRID, il faut se référer à la partie 2 de cette série d’article et à travers ce lien.
Construction d’une polyligne géographique
Sur le même principe que le point, la définition d’une polyligne utilise le mot clé ‘LINESTRING’ et sa représentation correspond à l’écriture suivante :
LINESTRING(COORDINATES1,COORDINATES2,COORDINATES3)
Avec un exemple, comme :
LINESTRING(2.75 47.5,3 47.5,3 50)
Et ici, en implémentation SQL Server 2008 :
DECLARE @line as geography
SET @line = geography::STLineFromText('LINESTRING(2.75 47.5,3 47.5,3 50)',4326)
Le point particulier avec ce type d’élément que l’on pourrait, par abus de langage, qualifier de géométrie géoréférencée réside dans la construction de point de coordonnées et l’ordre associé qui établit l’élément en tant que tel.
Voici la géométrie obtenue (en projection Mercator) :
Construction d’un polygone géographique
Enfin, le polygone respecte le même principe d’écriture en utilisant le mot clé ‘POLYGON’ et présente quelques contraintes d’écriture et définition que l’on aborde juste sous cet ordre SQL :
POLYGON((COORDINATE1,COORDINATE2,COORDINATE3, COORDINATE1))
Attention : les parenthèses sont doublées dans l’écriture de ce type d’éléments géographiques et la fermeture du polygone en utilisant la même coordonnées géographiques pour le premier et le dernier point.
Avec un exemple comme suit :
POLYGON((2.75 47.5,3.5 47.5,3.5 50, 2.75 47.5))
Et ici l’implémentation SQL Server 2008 :
DECLARE @polygon as geography
SET @polygon = geography::STGeomFromText('POLYGON((2.75 47.5,3.5 47.5,3.5 50, 2.75 47.5))',4326)
A noter : l'utilisation possible de la méthode STPolyFromText() pour la composition du polygone, comme indiqué ici :
http://msdn.microsoft.com/fr-fr/library/bb933971.aspx
Ici le polygone en résultat :
Comme pour la polyligne, l’ordre des coordonnées importe.
Pour un polygone l’ordre est encore plus important car il est nécessaire de déclarer ces points selon un ordre spécifique dans le sens anti-horaire afin de valider l’orientation du polygone pour permettre l’utilisation au sein de SQL Server 2008.
La prochaine version de SQL Server sera plus souple concernant ces déclarations, mais je reviendrai dans le détails sur les améliorations apportées par la version 11.0 de SQL Server
SQL Server 2008 nécessite que ces géométries géoréférencées soient orientées sans quoi l’erreur suivante peut s’afficher :
Cela provient d’un souci de définition qui ne respecte pas les limitations et les contraintes de définition des éléments.
Ici le message d’erreur indique qu’il s’agit d’une définition de polygone erronée car celle-ci excède un simple hémisphère alors que l’on souhaitait définir la géométrie inverse en termes de définition.
Le message d’erreur constaté est le suivant :
A .NET Framework error occurred during execution of user-defined routine or aggregate "geography":
Microsoft.SqlServer.Types.GLArgumentException: 24205: The specified input does not represent a valid geography instance because it exceeds a single hemisphere. Each geography instance must fit inside a single hemisphere. A common reason for this error is that a polygon has the wrong ring orientation.
Les polygones doivent en effet être décrit dans le sens anti-horaire pour définir un polygone valide d’un point de vue SQL.
Le problème se répète et se complique lorsqu’on souhaite désigner un polygone avec plusieurs cercles, aussi appelés polygones complexes, déterminer l’orientation peut alors se révéler plus délicate.
Dans le prochain article, on traitera des géométries complexes et composites, avec quelques règles et astuces qui pourront vous aider dans les implémentations que vous en ferez dans vos applications.
Conclusions
Le modèle de déclaration des éléments reste la base de l’utilisation des types géographiques au sein de SQL Server 2008 et supérieur.
Enfin, il est à noter, que ces types géographiques et géométriques sont disponibles dans l’offre de Windows Azure dans SQL Azure depuis juin 2010.
L’utilisation des types géographiques se résume principalement à ces éléments et l’exploitation qui peut en être fait avec les méthodes standards (standard OGC) et étendues propres à SQL Server 2008 que l’on abordera dans la suite de cette série dédiée aux types géographiques.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
