mardi 24 novembre 2009

Bref Aperçu sur les Bases de données Spatiales

Et Si l'on parlait des Bases de données spatiales !!
Suite au succès des bases de données relationnelles, qui gèrent des données "traditionnelles" style chaine de caractère, entier, réel, décimal, double, etc. La communauté des chercheurs et les éditeurs de SGBD ont tenté de faire pareil en essayant de trouver un moyen simple de gérer les données spatiales avec la même élégance que celle faite dans les bases de données relationnels, c'est à dire Gérer en natif les données spatiales: ajouter un autre type géométrie aux autres types présents dans la BDR.
Sauf ceci n'est évident, et il ne suffit pas de rajouter un type géométrie et puis c'est tout. Il faut avoir un langage déclaratif de type SQL pour définir les données, ensuite pour les interroger, et il faut également trouver un moyen pour indexer ces volumes de données spatiales.
La tâche n'est pas facile, et les éditeurs ont mis du temps pour s'approprier ce problème, et les recherches ont mis du temps pour essayer soit de d'étendre le langage standard des bases de données relationnelles SQL, soit de proposer de nouveaux langages déclaratifs pour cet objectif. Je rappele que le succès des BDR était d'avoir pu proposer un langage déclaratif SQL. L'avantage avec un langage déclaratif c'est l'utilisateur exprime par le langage ce qu'il veut obtenir, et laisse le soin au moteur de la base de données de chercher comment il recherche l'information dans la base de données.
Pour schématiser les données spatiales à stocker, on peut citer les points, les lignes, les polylignes, les polygones, etc. L'idée des BDS est de proposer un type de données spatiales que l'on peut définir pour ces données là.
Exp:
CREATE TABLE "nom de table"
("colonne 1" "long",
"colonne 2" "chaine de caractère",
"colonne spatiale" "type spatiale",
... )
Dans le cas d'Oracle Locator ou Spatial, le type spatial utilisé s'appelle SDO_GEOMETRY.
Une fois ces données spatiales sont stockées dans des tables, il faut les exploiter par, si possible un langage encore une fois déclaratif comme SQL. La principale différence avec le cas des données standards, c'est le filtre "Where" qui doit tenir compte de la spécificité spatiale, qui doit proposer des opérations spatiales : - mesures spatiales: trouver la distance entre des points, le calcul de surface, etc
- fonctions spatiales: modifier les couches spatiales pour en créer de nouvelles, par exemple, en dessinant un buffer, calcul des intersections, etc.
- Prédicats spatiaux: permettre des requêtes de style Vrai/faux comme 'Existe -t-il une résidence localisé à moins d'un KM de la zone industrielle'
- autre fonction et requêtes: pour plus d'informations, se référer aux spécifications de l'Open Geospatial Consortium.

Tout ceci est bien, sauf que pour pouvoir optimiser ces requêtes et le stockage de ces données, il nous faut autre chose. Imaginer que ma base de données spatiales contient des millions d'objets spatiaux et je demande dans ma requête de me récuperer un fragment de ces données. Naïvement, je dois parcourir tout les éléments de ma base pour récupérer les données qui m'interessent. C'est possible sauf que ca peut être couteux en terme de temps de réponse. Une des solutions perfomantes pour répondre à ce sujet, il y a l'utilisation des indexes. Dans les BDR le sujet d'indexation des données a été largement débattu et ce depuis le premier sytème relationnel System-R (le premier noyau de ce qu'a ramené la révolution relationnelle). Des indexes de style arbre binaire ont été largement adoptée par les SGBD comme le Btree, Btree+, Btree *, Hashage, les index Bitmap pour les données multidimentionnelles (Datawarehouse). Tout ceci c'est bien mais ne répond pas trop aux spécificités des données spatiales, et il a fallut essayer de trouver de nouveaux types d'indexes qui organisent les données spatiales en tenant compte de leur géométrie. Ainsi des indexes ont vu le jour comme le Rtree (Region Tree), QuadTree, KD-Tree, ainsi que d'autres indexes. je rappele que la recherche continue toujours de trouver d'autres adaptations de ces indexes pour mieux cerner les types de requêtes possibles spatiales. Je rappelle ici que le type le plus utilisé est celui du Rtree (utilisé par Oracle Spatial). Dans de prochains posts j'essayerais de présenter en détail chacun de ces indexes spatiaux, montrer leur particularités, à quoi ils servent, et comment se font les insertions, les modifications et les suppressions dans ces indexes et avec quelle complexité algorithmique. Un domaine qui a contribué beaucoup à l'élaboration des indexes spatiaux est la géométrie algorithmique ou ce que l'on a habitude d'appeler en anglais Computational geometry: A Very Exciting Domain. Sinon en attendant mes prochains posts: voir l'excellent livre de Hanane Samet :Foundations of Multidimensional And Metric Data Structures

Pour terminer, je rappelle ici les quelques SGBD commerciaux et OpenSource qui propose la gestion en natif des données spatiales: Oracle Spatial, DB2 Spatial Extender, Informix Spatial Datablade, MySQL Spatial, PostGres/PostGIS, et le tout nouveau dans la famille SQL Server 2008.


lundi 23 novembre 2009

Oracle Spatial- Suite

Oracle Spatial vs Oracle Locator

Le tableau ci-dessous récapitule les principales fonctionnalités des deux extensions Oracle : Spatial et Locator.





En général, Oracle Locator offre les fonctionnalités de base de la technologie spatiale. Pour des applications SIG plus avancés, exploitant des données raster par exemple, et utilisant des opérations de traitements géospatiales avancées, l’utilisation d’Oracle Spatial devient nécessaire.
Dans le reste de cette partie, nous présentons les principales caractéristiques d’Oracle Spatial.

La dimension spatiale dans Oracle Spatial


Comme tout SGBD gérant la dimension spatiale, Oracle propose un type natif de données spatiales appelé SDO_Geometry. Ainsi, les données géographiques et de localisation sont manipulées en utilisant la même sémantique utilisée pour les types CHAR, DATE, INTEGER, familiers à tous les utilisateurs SQL.



Le type SDO_Geometry


Le type SDO_Geometry peut stocker une variété de données spatiales, comme:
- un point, qui peut être utilisé pour stocker les coordonnées d’une localisation, comme un site client, une adresse, etc.
- un polyligne, qui peut être utilisé pour stocker la localisation et la forme d’un segment de route. Un polyligne peut connecter plusieurs points.
- un polygone, qui peut être utilisé pour stocker les limites des parcelles, des bâtiments, des villes, etc.
- des géométries complexes, comme des multiples polygones, qui peuvent être utilisés pour stocker des limites pour zones particuliers.



Figure 1 Diagramme de classe conceptuel du type SDO_Geometry
dénote une relation est-un
dénote une relation n-à-1
CSurface représente Composite Surface
CSolid représente Composite Solid
SSolid représente Simple Solid

D’un point de vue logique, le type SDO_Geometry a deux composantes logiques : le système de référence spatial (aussi appelé le système de coordonnées) de la géométrie, et l’objet ElementArray. Ce ElementArray, ou collections d’éléments, décrit la forme et la localisation de l’objet SDO_Geometry


Le type SDO_Geometry et les standards de données


Oracle Spatial supporte explicitement le type ST_Geometry qui est spécifié par le standard SQL/MM pour stocker les données spatiales à 2 dimensions, ainsi que ses sous-types : ST_CircularString, ST_CompoundCurve, ST_Curve, ST_CurvePolygon, ST_LineString, ST_GeomCollection, ST_MultiCurve, ST_MultiLineString, ST_MultiPoint, ST_Point, ST_MultiPolygon, ST_MultiSurface, and ST_Polygon. Ces types et SDO_Geometry sont essentiellement interopérables. En d’autres termes, on peut créer du ST_Geometry à partir d’un objet SDO_Geometry et vice versa. En plus Oracle Spatial implémente des fonctions de relations définies dans ST_Geometry et ses sous types. Sur un autre plan, Oracle Spatial est conforme aussi aux spécifications du consortium OGC et son Simple Features Specification for Object Model (l’implémentation ST_Geometry est conforme avec le OGC Simple Features Specification for Object Model).

Pour la 3ème dimension, Oracle peut stocker et modéliser la majorité des types dans les spécifications GML 3.0 à l’exception des types courbes paramétriques (arcs, splines, etc.). Il fournit aussi des constructeurs pour convertir les données entre le type SDO_Geometry et les notations WKT (Well-Known Text) et WKB (Well-Known Binary) de SQL/MM pour les données 2D, et entre SDO_Geometry et GML 3.0 pour les données 3D.

La validation des données spatiales


Etant donné qu’il y a plusieurs manières de stocker des données dans Oracle Spatial (insertion directe dans une table, import de fichier, conversion de format propriétaire), le type SDO_Geometry une fois dans les tables Oracle, a besoin d’être vérifié s’il est dans un format spatial valide, sinon des erreurs et de faux résultats peuvent survenir lors de l’exploitation des données. Oracle Spatial fournit deux fonctions de validations : Validate_Geometry_With_Context qui opère sur une seule géométrie, et Validate_Layer_With_Context, qui fonctionne sur une table de géométries. Les deux fonctions opèrent aussi bien sur des données 2D que 3D et retournent un message d’erreur si la géométrie est invalide. Ces fonctions de validations (appelées aussi fonctions de débogage) utilise des valeurs modifiables appelées tolérance pour déterminer si la géométrie est valide.


L’architecture Oracle Spatial

La technologie Oracle Spatial est distribuée sur deux couches: le serveur de base de données et le serveur d’application. La figure 2 indique les différentes composantes de la solution Oracle Spatiale ainsi que la distribution de ces composantes à travers le serveur de base de données et d’application. Les composantes de bases qui sont fournit par Oracle Database Server 11g incluent le modèle de donnée, les outils de requêtes et d’analyses, et les outils de chargement des données et de localisation. Le composant MapViewer est fourni dans Oracle Application Server 10 g.




Figure 2 Architecture Fonctionnelle d'Oracle Spatial

- Le modèle de données : Oracle Spatial utilise le type de données SQL, SDO_Geometry, pour stocker les données spatiales dans la base de données.
- Possibilité de localisation/ Location Enabling : Les utilisateurs peuvent ajouter des colonnes SDO_Geometry à leurs tables d’application en utilisant les utilitaires standards d’Oracle comme SQL*Loader, Import, Export. Alternativement, ils peuvent convertir des informations sur les adresses en information spatiale en utilisant le composant GeoCoder dans Oracle Spatial.
- Requête et Analyse Spatiale : Les utilisateurs peuvent interroger et manipuler les données SDO_Geometry en utilisant le composant de requête et d’analyse spatiale, comprenant le moteur d’indexation (Index Engine) et le moteur de géométrie (Geometry Engine).
- Moteur Spatial avancé (Advanced Spatial Engine): Ce composant comprend plusieurs sous-composants qui peuvent servir à des applications SIG sophistiquées. Ceci implique l’analyse du réseau et le moteur de routage. Il inclue aussi des composants du style GeoRaster qui permet le stockage des objets spatiaux utilisant des images plutôt que des points, lignes ou vertexs.
- Visualisation : les composants Serveur d’application de la technologie Oracle Spatiale permettent de visualiser les données via l’outil MapViewer. Ce dernier traduit les données spatiales stockées sous la forme de SDO_Geometry en des cartes.


Géocodage

Le géocodage sert deux objectifs. Le principal est d’associer des coordonnées géographiques à une adresse en utilisant la fonction GEOCODE_AS_GEOMETRY qui retourne un objet point SDO_Geometry. Cet objet contient les coordonnées géographiques que le géocodeur associe à l’adresse. Le deuxième objectif se produit une fois l’adresse est mal écrite. Le géocodeur essaye donc de corriger les erreurs dans les adresses dans un processus appelé normalisation des adresses, qui impliquent la structuration et le nettoyage des adresses. La normalisation des adresses est importante : elle corrige les erreurs et assure que toutes les informations sur les adresses soient complètes, bien structurées et valides. Un ensemble valide des adresses normalisées est nécessaires pour extraire des informations correctes sur la localisation et supprime les doublons.



Figure 3 Architecture du géocodeur Oracle


Indexes et opérateurs spatiaux

Oracle Spatial utilise l’information stockée dans le type SDO_Geometry pour réaliser des analyses de proximité. Pour réaliser une analyse de proximité efficace, Oracle utilise trois éléments basiques :
- Les opérateurs spatiaux : de la même manière que d’utiliser des opérateurs relationnels dans des expressions SQL, comme < (inférieur à), > (supérieur à), ou = (égal à), etc, Oracle permet d’utiliser des opérateurs spatiaux pour chercher dans la colonne de localisation SDO_Geometry pour une proximité par rapport à une requête de localisation. Par exemple, l’opérateur SDO_WITHIN_DISTANCE permet de chercher, dans une requête donnée, une information dans un périmètre donné.
- Les indexes spatiaux : analogues aux traditionnels indexes B-Tree, les indexes spatiaux accélèrent l’exécution des opérateurs spatiaux sur les colonnes SDO_Geometry.
- Les fonctions de traitement de la géométrie : ces fonctions réalisent un ensemble d’opérations, comme le calcul des interactions spatiales entre deux ou plusieurs objets SDO_Geometry. Les fonctions spatiales n’utilisent pas les indexes spatiaux, et permettent une analyse plus rigoureuse des données spatiales que ce que permet les opérateurs spatiaux.
Le référencement linéaire
Les coordonnées spatiales ne sont pas la seule manière de localiser un objet. Certains objets sont mieux identifiés par leurs positions selon une caractéristique linéaire : leurs localisations peuvent être décrites par une valeur de mesure (comme la distance de trajet) par rapport à un point connu (comme un point de départ). Ce type de référencement géographique utilisant une valeur de mesure (au lieu de valeurs longitudes/latitudes) est appelé Système de Référencement Linéaire (Linear Referencing System) ou LRS.
Oracle permet à travers le package SDO_LRS d’associer des mesures avec un thème linéaire stocké dans un objet SDO_Geometry. Il permet également de réaliser des opérations sur des géométries LRS :
- Projeter un point 2D sur un thème linéaire, et en identifier la mesure correspondante.
- Localiser un point en utilisant une valeur de mesure, et identifier les coordonnées 2D correspondantes.
- Délimiter (opération de Clip) un thème linéaire en utilisant des valeurs de mesure de départ et d’arrivée.


Le modèle de données topologique dans Oracle

Le modèle de données topologique d’Oracle stocke les thèmes individuels en utilisant trois primitives topologiques : les nœuds, les arcs, et les faces. Ces éléments sont stockés en interne comme des objets SDO_Geometry:
- Un nœud : C’est un point géométrique qui est partagé par un ou plusieurs thèmes. Un nœud peut être isolé (c.à.d ne pas être connecté à aucun autre nœud), ou connecté à un ou plusieurs nœuds.
- Un arc : c’est une ligne qui connecte deux nœuds dans une topologie. Il peut contenir plusieurs vertexes qui ne sont pas considérés comme des nœuds individuels.
- Une face : c’est une zone polygonale entourée par un ensemble d’arcs
Il faut noter que les thèmes topologiques ne sont pas stockés comme des objets SDO_Geometry, mais comme des objets SDO_TOPO_Geometry. Ces objets indiquent la liste des éléments topologiques formant le thème. L’avantage d’utiliser cette structure c’est qu’elle permet d’éliminer la redondance dans le stockage des données en assurant la consistance des données, et puisque la topologie est précalculée, l’identification de tous les thèmes qui satisfont des relations topologiques dans une requête devient facile et rapide. Les types de relations topologiques qui peuvent être spécifiées sont TOUCH, ANYINTERACT, OVERLAPBDYDISJOINT, OVERLAPBDYINTERSECT, CONTAINS, INSIDE, COVERS, COVEREDBY, et EQUALS. Il faut noter aussi que les relations topologiques sont préservées même si l’espace des coordonnées est modifié (étiré ou déformé)


Le stockage des données RASTER dans Oracle

Oracle fournit le type de données SDO_GEORASTER pour stocker les données spatiales sous format Raster. Conceptuellement, un objet SDO_GEORASTER est une matrice de cellules à N dimensions. Les dimensions incluent une dimension ligne, une dimension colonne, et d’autres dimensions optionnelles. Ces dimensions optionnelles peuvent contenir une dimension de bandes pour représenter des images multibandes ou hyperspectrales, et /ou une dimension temporelle.
Les valeurs des cellules dans un objet GEORASTER sont stockées dans une table de données raster. En plus des informations Raster, SDO_GEORASTER peut aussi capturer des informations sur quelle partie de la surface de la terre est représentée l’objet raster.


La modélisation Réseau et le moteur de routage dans Oracle

Oracle 10g supporte la modélisation réseau en se basant sur les éléments suivants :
- un modèle de données pour stocker les réseaux à l’intérieur de la base de données sous forme d’un ensemble de tables, représentant ainsi une copie persistance du réseau.
- des fonctions SQL pour définir et maintenir le réseau (le package SDO_NET)
- des fonctions d’analyses réseau : la bibliothèque API s’exécute sur une copie du réseau chargée à partir de la base de données. Elle représente la copie volatile du réseau. Les résultats des analyses (en d’autres termes, les chemins réseau calculés) et les changements du réseau peuvent être réécris vers la base.
- Des fonctions d’analyses réseau en PL/SQL (le package SDO_NET_MEM).
Le moteur de routage, contrairement au modèle de données réseau qui fournit une API qui peut être utilisée au sein d’une application, est un service web : l’utilisateur envoie sa requête exprimé en XML, et Oracle retourne le meilleur chemin, aussi en XML.


Possibilité Cartographique d’Oracle MapViewer

Comme solution cartographique, Oracle propose l’outil MapViewer pour visualiser les données spatiales gérées par Oracle Spatial. Les cartes générées par MapViewer peuvent être personnalisées avec un ensemble de métadonnées cartographiques comme les symboles et les règles de styles qui sont stockés dans une base de données et gérés par une interface utilisateur. Il permet aussi la création de cartes thématiques dont le style peut être modifié dynamiquement.

Oracle Spatial

C’est une option d’Oracle Database Entreprise Edition. Il étend Oracle Locator, et fournit une fondation robuste pour des applications SIG robuste qui nécessitent plus d’analyse spatiales et de traitement dans la base de données Oracle. Oracle Spatial supporte pratiquement les principaux types et modèles de données.
Les principales caractéristiques d’Oracle Spatial incluent :
- Un système de référencement linéaire puissant
- Plus de 400 fonctions spatiales comme la génération des buffers, centroïdes, calcul des surfaces et longueurs, et les fonctions d’agrégats (comme Union)
- Le type GeoRaster qui gère en natif les images raster géo-référencées
- Un modèle de données qui stocke et met à jour la topologie
- Un moteur de géocodage et des fonctions d’analyses spatiales
- Le partitionnement des données avec les possibilités de réplication
- Prise en compte des standards ouvert tel que : OpenGIS

Oracle Locator

C’est un package gratuit d’Oracle Database (Edition Standard, Edition Entreprise), qui fournit les fonctionnalités principales de localisation nécessaires pour certaines applications spatiales. Oracle Locator ne peut pas être considéré comme une solution à part entière pour des applications SIG complexes.
Les caractéristiques de base présentes dans Oracle Locator sont :
- Une prise en compte des types de données spatiaux 2D, 3D, 4D
- Une indexation R-Tree pour accélérer la recherche d’information dans la base.
- Accès SQL standard et ouvert aux opérations spatiales
- Des fonctions basées sur l’utilisation des index spatiales
- Le support des transactions longues
- Intégration avec Oracle Application Server
- Transformation explicite des coordonnées
Les applications utilisant Locator, peuvent avoir besoin de services tiers de géocodage pour convertir les adresses dans des tables d’application. Une fois les localisations spatiales sont stockées sous forme de colonne SDO_GEOMETRY, Oracle Locator permet de réaliser un ensemble de requêtes spatiales, comme l’identification de parcelles se trouvant à l’intérieur d’un périmètre donné, ou l’immeuble le plus proche par rapport à un repère donné.

A Spatial Database Welcome

Bienvenu sur mon Blog dédié aux technos autour des Bases de données spatiales.
vous y trouveriez des posts sur les bases de données spatiales (architecture, concepts, fondements, Index, Requêtes spatiales, Analyses), mais aussi des produits BD spatiales style Oracle Spatial, PostGIS, SQL Server.
Ce blog se veut un lieu où je peux partager mon expérience avec les gens et lancer des discussions sur des thématiques assez variées liées aux BDS.
Je reste ouvert à vos suggestions et remarques.
Feel Free to contact me if you want!
Hicham Hajji