GIB contient 2 tables représentant les emprises d’images satellites ou de cartes. Ces tables sont nommées SCENE et MAP. Elles renseignent les 4 sommets du quadrilatère ainsi que le rectangle englobant de ce quadrilatère. Ensuite, deux tables, LOI et COLL_DATA, renseignent sur des lieux d’intérêts ou des données issues d’origines diverses (articles de presse en majorité).
Les types de géométries stockées sont de type point, polygone ou ellipse. Les structures de stockage sont les suivantes :
• Un point est stocké dans un enregistrement de la table de coordonnée (COORD_LAT, COORD_LON)
• Un polygone dans au minimum 4 enregistrements (le premier point étant également stocké en dernière position)
• Une ellipse dans 2 enregistrements (Coordonnées du rectangle englobant)
Rq : Les ellipses stockées dans GIB ont un axe principal obligatoirement horizontal ou vertical.
Le champ AREA_TYPE de la table LOI permet de connaître le type de géométrie (Point, Rectangle, Polygone, Ellipse ou Alpha14). Le type de la géométrie n’est donc pas connu avant la fin de la saisie utilisateur. Pour connaître le type de géométrie associé à un type alpha, il faut analyser le nombre de couple de coordonnées.
14 A noter que le type alpha correspond à une saisie manuelle des coordonnées dans l’application.
Pour réaliser la migration de ces données géographiques en objet de type MDSYS.SDO_GEOMETRY, un script PL/SQL a été réalisé (PL/SQL est un langage de programmation doté des fonctions SQL propre à Oracle).
b.Mécanisme de migration
Cette partie a pour but la présentation des principales étapes de la migration de GIB15. Seules les procédures principales seront exposées ici. Celle-ci permettront d’illustrer les méthodes d’accès à l’objet MDSYS.SDO_GEOMETRY dont la structure a été présentée dans la section 1.1.3.
Les étapes de la migration sont :
1.Ajout des colonnes de type MDSYS.SDO_GEOMETRY à la table
Alter table SCENE add (SHAPE MDSYS.SDO_GEOMETRY);
2.L’initialisation des colonnes de type MDSYS.SDO_GEOMETRY est nécessaire avant tous accès à l’objet. L’initialisation d’un tel objet est réalisée de la manière suivante :
-- Initialisation de l'objet SDO_GEOM pour ne pas violer le « NULL atomique » ORA-2309
update LOI set SHAPE = MDSYS.SDO_GEOMETRY(NULL,NULL,NULL,NULL,NULL);
3.Mise à jour des métadonnées pour permettre l’exploitation ultérieure des données géographiques
Delete USER_SDO_GEOM_METADATA where TABLE_NAME = 'SCENE';
Insert into USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO) values ('SCENE', 'SHAPE',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', -180.000000000, 180.000000000, 0.000000050),
MDSYS.SDO_DIM_ELEMENT('Y', -90.000000000, 90.000000000, 0.000000050) )
);
4.Recherche du type de géométrie dans le cas où le type de géométrie n’est pas défini c’est-à-dire AREA_TYPE = ALPHA (cf Annexe 11)
5.Insertion des coordonnées en fonction du type d’éléments
L’insertion des valeurs pour la table SCENE et MAP est réalisée à partir des coordonnées des sommets du quadrilatère. Les coordonnées du rectangle englobant chaque géométrie sont inutiles lors de l’utilisation du modèle objet-relationnel. En effet dans l’ancien modèle de GIB, le rectangle englobant permettait de réaliser des pré-requêtes spatiales sur les objets. En utilisant Oracle Spatial cette fonction sera assurée par l’index. De plus la fonction SDO_TUNE.EXTENT_OF permet d’obtenir ces informations.
-- Mise à jour de la colonne SHAPE
Update MAP map set (SHAPE) = (MDSYS.SDO_GEOMETRY ( 2003,
NULL, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY (1,1003,1), MDSYS.SDO_ORDINATE_ARRAY (
-- Récupération des coordonnées dans l’enregistrement courant map.coord_lon_ne, map.coord_lat_ne,
map.coord_lon_nw, map.coord_lat_nw, map.coord_lon_sw, map.coord_lat_sw, map.coord_lon_se, map.coord_lat_se,
map.coord_lon_ne, map.coord_lat_ne–-le dernier couple est répété
15 Pour plus de détail se référer au rapport « Migration de donnée sous Oracle Spatial : Apries2/GIB ».
) ) );
L’insertion des coordonnées réalisant l’insertion des coordonnées dans les tables LOI et COLL_DATA dépend du type de géométrie :
- Les points :
-- Point
-- Mise à jour du type de la géométrie
Update LOI loi16 set (loi.SHAPE.SDO_GTYPE) = (2001) where loi.SHAPE_TYPE = 'Point';
-- Mise à jour des coordonnées
Update LOI loi set (loi.SHAPE.SDO_POINT_TYPE) = MDSYS.SDO_POINT_TYPE(
-- X
(Select lc.COORD_lon from COORD_LOI lc, LOI lo
where lc.LOI_ID = lo.LOI_ID and lc.LOI_ID = lOI.LOI_ID), -- Y
(Select lc.COORD_lat from COORD_LOI lc, LOI lo
WHERE lc.LOI_ID = lo.LOI_ID and lc.LOI_ID = lOI.LOI_ID), NULL -- Z
)
where loi.SHAPE_TYPE = 'Point';
- Les Ellipses :
La géométrie de type Ellipse ne peut pas être stockée dans un objet SDO_GEOMETRY. Deux solutions sont alors possibles :
• Utiliser le type SDO_GTYPE 0 définissant une géométrie de type inconnu
• Stocker le rectangle représentant l’emprise de l’ellipse.
Cette dernière a été choisie car le dessin des ellipses dans GIB à partir d’Ilog Views Map repose sur ce rectangle d’emprise (cf. annexe 12).
- Polygone :
L’insertion des coordonnées des polygones repose sur deux fonctions :
• Une permettant de récupérer la liste des enregistrement contenant les coordonnées
• Une permettant l’insertion d’une ligne dans l’élément MDSYS.SDO_ORDINATES.
Le détail des scripts est présenté dans l’annexe 12. Ici sera présenté la méthodologie employée pour la réalisation de la migration ainsi que les principales manipulations réalisées sur l’élément MDSYS.SDO_ORDINATES. L’élément MDSYS.SDO_ORDINATES est de type VARRAY c’est-à-dire un tableau à taille variable. Un certain nombre de méthodes existe sur les VARRAY.
Les méthodes employées sur le VARRAY MDSYS.SDO_ORDINATES sont présentées dans le mécanisme d’insertion des géométries de type polygone.
16 Remarque sur les alias : l’utilisation d’alias est obligatoire pour l’accès aux éléments de l’objet SDO_GEOMETRY
Sélection des identifiants de la table dans un tableau Pour chaque identifiant
Initialisation de MDSYS.SDO_ORDINATES
Récupération de l’objet MDSYS.SDO_GEOMETRY (geom_copy)
Appel de la procédure PUT_ORDINATES : Insertion des coordonnées d’une géométrie (Annexe 13)
Fin de la boucle
Procédure PUT_ORDINATES
Récupération des coordonnées de l’ancien modèle Pour chaque couple de coordonnées XY
Appel de la procédure INSERT_COORD : Insertion d’un couple de points (Annexe 13)
Fin de la Procédure PUT_ORDINATES
Procédure INSERT_COORD
Calcul de la taille de MDSYS.SDO_ORDINATES geom_copy.SDO_ORDINATES.count;
Extension de la taille de MDSYS.SDO_ORDINATES geom_copy.sdo_ordinates.extend(2);
Insertion du couple de coordonnées geom_copy.sdo_ordinates(i) := x;
geom_copy.sdo_ordinates(j) := y;
Fin de la Procédure INSERT_COORD
Figure 28: Mécanisme d’insertion des géométries de type polygone
Ainsi la migration d’un modèle de données non normalisé vers un modèle objet-relationnel fait appel à des scripts de migration et de mise en forme de données. A partir de bonnes notions de SQL et des principes de bases de programmation (boucles essentiellement) l’intégration est rapide. Comme il a été signalé dans la section 2.1.1, le passage d’un modèle à l’autre peut être réalisé par le passage par un format de données SIG.
2.1.3Intégration des différents formats SIG dans Oracle Spatial
Cette méthode peut être utilisée dans le cas de l’intégration de donnée SIG mais également à partir de données issues d’un serveur spatial auxquelles un SIG est capable de se connecter. Par exemple dans le cadre d’Apries2, il aurait pu être envisagé d’utiliser Geomedia 4 capable de se connecter à Oracle Spatial selon le modèle relationnel et le modèle objet-relationnel.
Dans le domaine de la manipulation des données géographiques, un logiciel de référence FME (Feature Manipulating Engine) permet la m anipulation d’un grand nombre de format SIG (Shp, SDE, Oracle Spatial, Tab, Dxf, GML, …)17.. FME est distribué par Safe (www.safe.com). Il comprend des fonctions de conversion de format ainsi que des fonctions de reprojection. Il est par ailleurs capable de lire et écrire les formats Oracle Spatial modèle relationnel et modèle objet-relationnel. L’ensemble des tests d’intégration et de migration de données réalisées avec FME ont été concluant. Il est de plus possible de lancer FME en mode batch ce qui en fait un outil efficace pour la gestion des échanges de données géographiques. Il faut noter que ce produit est d’un coût assez élevé.
Une autre méthode d’intégration de données géographiques au sein des serveurs spatiaux est l’utilisation des logiciels SIG actuels qui présentent de plus en plus fréquemment
17 Voir en annexe 7 pour la liste complète des formats supportés par FME
une interface de connexion (en natif ou sous forme d’extension) à Oracle Spatial. Un bilan des relations entre Oracle Spatial et les SIG est réalisé dans la section 3.2.
Ainsi a été montré la faisabilité de la migration des bases de données vers le modèle objet-relationnel d’Oracle Spatial. Cependant la migration d’un modèle « personnalisé » (comme celui de GIB) reste plus délicate et demande l’appel à des fonctions SQL et de la programmation PL/SQL. De plus cette section permet d’avoir une idée de la manière d’accéder à l’objet SDO_GEOMETRY en utilisant le langage SQL.
Une autre possibilité de migration des données est de récupérer les données à l’aide d’un SIG, de les transformer au format natif de ce SIG puis de les réincorporer dans Oracle Spatial selon le modèle objet-relationnel. Cependant pour cela il faut que le SIG puisse se connecter à Oracle Spatial suivant les deux types de modèles ce qui est rarement le cas.
2.2 L’indexation spatiale
Afin d’optimiser l’accès aux données géographiques, l’indexation est nécessaire.
L’indexation consiste en une simplification de la recherche d’élément au sein des tables de bases de données. Dans le cas des données géographiques, l’indexation consiste en une simplification des données géographiques en se basant soit sur un quadrillage des données soit sur les rectangles englobants. Ceci est essentiel pour les manipulations des données. Les techniques d’indexation spatiales sont présentées dans cette section. Pour ce qui est du type modèle relationnel (type binaire), la section 1.1.2 a montré qu’en plus du stockage des coordonnées dans un champ binaire, étaient stockées les coordonnées du rectangle englobant dans des champs de type numérique. En effet, ceci est nécessaire car l’indexation repose sur cette emprise (n’ayant pas ainsi à accéder à la structure binaire).
Lors de la création des index, les étapes suivantes sont réalisées : 1.Création de l’index « logique »
2.Création de la table de l’index 3.Renseignement de la table (Tuilage)
4.Création de l’index B-tree 1 sur le code de la tuile (Tile codes) et sur l’identifiant (ie. rowid) puis création de l’index B-tree 2 sur l’identifiant (ie. rowid).
Rq : B-tree 1 et B-tree 2 sont deux sous-index
2.2.1Les différents types d’index
Les différentes familles d’index sont communes à l’ensemble des serveurs spatiaux.
Cependant les exemples et les paramètres peuvent différer d’un SGBD à l’autre. L’ensemble des exemples ici sont relatifs à l’utilisation d’Oracle Spatial. Le procédé réalisant l’indexation spatiale est appelé tuilage. Le résultat est stocké dans les index. Il existe 2 grandes familles d’index :
• le type Quad-Tree
• le type R-Tree
Paramètres des index Quad-Tree :
SDO_LEVEL définit la résolution (ou niveau) du tuilage. SDO_LEVEL > 0. Plus le SDO_LEVEL est grand, plus la taille des tuiles est petite.
SDO_NUMTILES définit le nombre de tuiles couvrant chaque géométrie.
Paramètre des index R-Tree :
SDO_FANOUT détermine la capacité du nœud de l’arbre.
SDO_INDX_DIMS définit la dimension du R-Tree.
SDO_RTR_PCTFREE définit le pourcentage d’espace libre dans chacun des nœuds de l’arbre. Cet espace libre sera utilisé par la suite dans le cas d’ajout de données.
Tableau 2 : Valeurs des paramètres d’indexation pour les différents index
Quad-tree hybride Quad-tree fixe R-tree (« Region tree ») SDO_LEVEL > 0 SDO_LEVEL > 0 SDO_FANOUT = 35 par défaut SDO_NUMTILES > 0 SDO_NUMTILES = 0 SDO_INDX_DIMS = 2 par défaut
SDO_RTR_PCTFREE = 10 par défaut
2.2.2Quad-tree
Lors de la réalisation d’une indexation de type Quad-tree, chaque géométrie est représentée par un ensemble de tuiles exclusives et exhaustives. En effet, aucune tuile ne se superpose à ces voisines (exclusif) et l’ensemble des tuiles couvre l’intégralité des géométries du calque (exhaustif) ; L’espace vide n’étant pas indexé.