Mise en place des serveurs spatiaux au sein des systèmes d information

Ministère de l Agriculture et de la Pêche ÉCOLE NATIONALE d INGÉNIEURS des TRAVAUX AGRICOLES de BORDEAUX Mise en place des serveurs spatiaux au sein des systèmes d information François-Xavier Prunayre Organisation des structures et flux de données sous serveur spatial - 2oo1 -

Ministère de l Agriculture et de la Pêche ÉCOLE NATIONALE d INGÉNIEURS des TRAVAUX AGRICOLES de BORDEAUX 1, cours du Général de Gaulle 33170 GRADIGNAN MEMOIRE de fin d études pour l obtention du titre d Ingénieur des Techniques Agricoles Mise en place des serveurs spatiaux au sein des systèmes d information Organisation des structures et flux de données sous serveur spatial Prunayre, François-Xavier Maître de Stage : Matthieu Castagnet Option : AgroTIC (Technologie de l Information et de la Communication en Agronomie) Étude réalisée à : Générale d Infographie - 2oo1 -

Remerciements : Je tiens à remercier tout d abord mon maître de stage Matthieu pour son aide tout au long de ces 6 mois de stage. son ambiance agréable. Également merci à toute l équipe de la Générale d Infographie pour son soutien et Par ailleurs, j aimerai remercier l ensemble des personnes rencontrées sur le forum d Oracle Spatial et plus particulièrement David Miller et Dan Abugov pour leur aide et leurs nombreux conseils ainsi qu André Winter et Andréas Neuman de l université de Vienne pour leurs précieuses remarques et exemples concernant la technologie SVG. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 3

Résumé : Au cours des 5 dernière années, les Systèmes de Gestion de Base de Données ont montré de nombreux avantages dans le stockage des données géographiques tant au niveau de la consultation que du traitement et de l analyse. Après de nombreuses évolutions au niveau des structures de stockage des données définies par l OGC, le TC211 et le SQL/MM, le modèle objetrelationnel tant à s imposer pour le stockage de données vecteurs et RASTER. Les échanges de données entre serveurs spatiaux et applications s orientent vers des formats basés sur le XML : le GML pour les échanges et le SVG pour le rendu graphique de données vecteurs. Le stockage des données géographiques a conduit à l implémentation de nouvelles fonctions d indexation et d interrogation au niveau du langage SQL (SQL3/MM). Les opérateurs spatiaux mis en place viennent concurrencer les fonctions SIG en facilitant la liaison entre données sémantiques et données géographiques. L intégrité et l accès aux données sont assurés au sein des serveurs spatiaux par les fonctions classiques des SGBD (rôle, utilisateur, ) mais aussi par l apparition de la gestion des versions et la notion d espace de travail. Au niveau système, l architecture client-serveur est de plus en plus fréquemment remplacée par une architecture multi-tiers où la logique d application est répartie entre les différents services (visualisation, communication, traitement, donnée ). Du fait de leurs capacités, les serveurs spatiaux deviendront, dans les années à venir, la clé de voûte des systèmes d information géomatiques dans des environnements interopérables. Mots clés : Cartographie, Données géographiques, Échange de données, Géoservices, GML, Interopérabilité, Modèle objet-relationnel, Open GIS Consortium, Oracle Spatial, RASTER, Serveur spatial, SGBD, SIG, SQL/MM, SVG, TC211, Vecteurs, XML Titre en Anglais : Spatial data server implementation in Information System (structure and workflow managment characteristics) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 4

Table des matières : 1. Structure de stockage des informations géographiques sous serveur spatial12 1.1 Du modèle relationnel au modèle objet-relationnel 14 1.1.1 Structure des types géométriques selon l Open GIS Consortium Geometry Model 14 1.1.2 Le modèle relationnel : Premier modèle utilisé dans les bases de données géographiques 15 1.1.3 Stockage au format binaire propriétaire : «Well Known Binary Format» 18 1.1.4 Le modèle objet-relationnel : Amélioration des performances et des structures de stockage 20 1.2 Comparaison des formats SIG classiques par rapport à celui d un serveur spatial (Oracle Spatial) 23 1.3 Les promesses du modèle objet-relationnel pour le stockage des données RASTER 25 1.3.1 Les problèmes liés aux données RASTER 25 1.3.2 Quelles sont les capacités actuelles des SGBD pour l exploitation des données RASTER? 25 1.3.3 Réalisation: Mise en place d une application de tuilage automatique d images géoréférencées sous Oracle 27 1.4 Les nouveaux formats d échange de données : Standard de l Open GIS Consortium 29 1.4.1 L échange de données géographiques et le GML : Geographic Markup Language 29 1.4.2 La cartographie vectorielle sur Internet et le SVG : Scalable Vector Graphics 35 2. Intégration, Manipulation et Analyse des données spatiales 42 2.1 Réalisation : Intégration de données vers le modèle objet-relationnel 44 2.1.1 Du modèle relationnel au modèle objet-relationnel : Catalogue d images satellites Apries2 44 2.1.2 D un modèle de données non normalisé vers le modèle objetrelationnel : Catalogue d images satellites GIB de l UEO 46 2.1.3 Intégration des différents formats SIG dans Oracle Spatial 49 2.2 L indexation spatiale 50 2.2.1 Les différents types d index 50 2.2.2 Quad-tree 51 2.2.3 R-tree (RTR) 53 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 5

2.2.4 Choix du type d index selon les données 53 2.3 Relation spatiale et analyse spatiale 55 2.3.1 Analyse des relations spatiales grâce aux modèles des 9 intersections55 2.3.2 Principe de fonctionnement des opérateurs spatiaux SQL sous Oracle Spatial 58 2.3.3 Influence du type d index sur les performances des requêtes spatiales 59 2.3.4 Présentation des différents opérateurs géographiques sous serveur spatial 62 3. Mise en place des serveurs spatiaux en environnement Multi-Utilisateurs 69 3.1 Concept d espace de travail et de gestion des versions 71 3.1.1 Princ ipes 71 3.2 Interactions SIG / Serveurs Spatiaux 73 3.3 Interopérabilité et organisation des échanges de données spatiales 75 3.3.1 Interopérabilité entre les systèmes 75 3.3.2 De l architecture client-serveur à l architecture multi-tiers 75 3.3.3 Liaisons entre services 77 3.4 Architecture des Géoservices 81 3.4.1 EOSE modèle pour l information géographique 81 3.4.2 Recherche de données : les catalogues 82 3.4.3 Web mapping Testbed : exemple d applications basées sur les standards (SCOTS) en environnement Internet 82 3.5 Réalisations 84 3.5.1 SDO Viewer : Module de visualisation de données au format Oracle Spatial dans une architecture client-serveur 84 3.5.2 SVGib : Mise en place d un système de consultation d un catalogue basé sur une architecture multi-tiers 87 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 6

Table des figures : Figure 1: Relation entre les efforts de normalisation ISO et OGC...13 Figure 2: Hiérarchie entre les différents types de géométrie...15 Figure 3: Les types de géométries primitives...16 Figure 4: Modèle pour le stockage des tables selon SQL92 (Type numérique)...16 Figure 5: Modèle de données pour le modèle relationnel sous Oracle...17 Figure 6: Modèle pour le stockage des tables selon SQL92 utilisant le format binaire...18 Figure 7: Représentation selon le Well-known Binary format selon le standard NDR (B=1) pour une géométrie de type polygone (T=3) ayant deux anneaux (NR=2) de trois points chacun (NP=3)...19 Figure 8: Principe de fonctionnement d ArcSDE...19 Figure 9: Les différents types de géométrie complexe supportés...20 Figure 10: Ordre des coordonnées d une géométrie au sein de l objet SDO_ORDINATES...22 Figure 11: Comparaison du format shapefile avec les différents structures de stockages sous Oracle Spatial...24 Figure 12: Structure du stockage des images géoréférencées avec GEOIMAGE...27 Figure 13: Interface de l application de tuilage en ligne...28 Figure 14: Module de visualisation...28 Figure 15: Contenu, Forme & Structure pour le format GML...30 Figure 16: Schéma de la balise <coord>...31 Figure 17: Schéma de la balise <coordinates>...32 Figure 18: Exemple de schéma d application : schfoo...33 Figure 19: Exemple d utilisation du schéma d application...34 Figure 20: Organisation d un document SVG...35 Figure 21: Exemple de structure SVG...36 Figure 22: Parcours d un fichier SVG du serveur au client...37 Figure 23: Fonctions natives du plugin d Adobe...37 Figure 24: Données Raster et SVG...38 Figure 25: Interface de SVGib...39 Figure 26: Processus de migration de données depuis le modèle relationnel...45 Figure 27: Données APRIES2...45 Figure 28: Mécanisme d insertion des géométries de type polygone...49 Figure 29: Quad-tree Hybride...51 Figure 30: Quad-tree Fixe...51 Figure 31: Visualisation des index avec Spatial Advisor...52 Figure 32: Concept de l indexation de type R-tree...53 Figure 33: Matrice des intersections selon le DE-9IM...57 Figure 34: Exemple : La matrice correspondant à deux polygones se chevauchant est de la forme «212101212»...57 Figure 35: Fonctionnement des requêtes...58 Figure 36: Temps d exécution de requête fonction du niveau de tuilage pour 2 calques de type ligne (1 & 2)...59 Figure 37: Effet de SDO_LEVEL sur les performances de SDO_RELATE...59 Figure 38: Comparaison des vitesses des requêtes RELATE et FILTER pour le calque COUNTRIES (Polygones) en fonction des différents types d index...60 Figure 39: Comparaison des vitesses des requêtes RELATE et FILTER pour le calque CITIES (Point) en fonction des différents types d index...60 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 7

Figure 40: Comparaison entre index QTF et QTH...61 Figure 41: Comparaison entre index QTF et QTH pour de petite taille de fenêtre...61 Figure 42: Interface de recherche par pays...62 Figure 43: Comparaison des relations topologiques...63 Figure 44: Résultats des trois types de relations topologiques...63 Figure 45: Interface de recherche des plus proches voisins d une emprise...64 Figure 46: Recherche des 9 voisins les plus proches d une emprise sélectionnée...64 Figure 47: Reprojection avec Oracle Spatial (version 8 ou supérieure)...65 Figure 48: Buffer réalisé autour de la France...66 Figure 49: Résultat de la fonction SDO_CONVEXHULL pour l Europe...66 Figure 50: Opération d union, d intersection et de différence...67 Figure 51: Hiérarchie des espaces de travail...71 Figure 52: Point de sauvegarde au sein des espaces de travail...72 Figure 53: Interopérabilité...75 Figure 54: D une architecture 2-tiers à une architecture 3-tiers...76 Figure 55: Liaisons transparentes...77 Figure 56: Liaisons translucides...78 Figure 57: Liaisons opaques...78 Figure 58: Mise en place de systèmes interopérables d un point de vue technologique...79 Figure 59: Architecture des géoservices...80 Figure 60: Décomposition d un serveur de carte et définition des différents types de client...... 83 Figure 61: Interface de SDOViewer...85 Figure 62: Architecture du système Client-Serveur de SDOviewer...86 Figure 63: Architecture de SVGib...88 Figure 64: Structure de la table CS_SRS...99 Figure 65: Description du Lambert III...99 Figure 66: Modèle pour le stockage des tables selon SQL92 (Type binaire)...100 Figure 67: Exemple de polygones...101 Figure 68: Exemple de polygone violant les règles de l OGS Geometry Model...101 Figure 69: Exemple de multipolygone...101 Figure 70: Exemple de géométrie non représentable comme une seule instance d un multipolygone...101 Figure 71: Exemple de Modèle d'objet de Document (DOM) d une page web simple...105 Figure 72: Script PL/SQL d union de deux polygones...114 Figure 73: Script PL/SQL d intersection entre deux polygones...114 Figure 74: Script PL/SQL XOR (Ou exclusif) entre deux polygones...115 Figure 75: Script PL/SQL de différence entre deux polygones...115 Figure 76: Syntaxe pour la création des polygones convexes de Hull (plus petit polygone convexe englobant la géométrie)...115 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 8

Table des tableaux : TABLEAU 1 : ELEMENT TYPE et INTERPRETATION associée...22 Tableau 2 : Valeurs des paramètres d indexation pour les différents index...51 Tableau 3 : Comparaison des deux grands types d index:...54 Tableau 4 : Bilan des connexions entre les logiciels SIG et Oracle Spatial...74 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 9

Sur Internet, de plus en plus de serveurs et de services en lignes utilisés à des fins de visualisation et de partage de données géographiques se mettent en place. Cette mise en place ne se fait pas de manière anarchique car 3 organismes : l Open GIS Consortium (OGC), le comité technique pour la géomatique TC211 de l ISO et le SQL/MM déterminent les standards utilisés dans le domaine de la géomatique depuis une dizaine d années maintenant. Ces standards ont pour vocation d aider à la structuration et à l accès des données géospatiales contenues dans les serveurs spatiaux mais aussi à la confection des Systèmes d Information reposant sur ces serveurs de données particuliers. En effet, les serveurs spatiaux permettent de simplifier l architecture des systèmes en éliminant l architecture hybride des SIG actuel (données attributaires / données géographiques). Les Système de Gestion de Fichiers (SGF) aussi bien dans le domaine des données vecteurs que RASTER vont probablement connaître de fortes évolutions dans les années à venir. En effet, au sein des serveurs spatiaux l intégrité des données (partage données sémantiques et spatiales) est assurée via l utilisation de module de gestion des versions et de création d espace utilisateur. De tels modules sont nécessaires car les données géographiques sont par nature encombrantes et les transactions longues ; tout le contraire des données financières! Le serveur spatial n est pas simplement un système de stockage de données. Un grand nombre d opérateurs spatiaux permettent, via le langage SQL, d augmenter les capacités d analyse et d interrogation des données spatiales et attributaires. Mais outre cette meilleure organisation des données, le serveur spatial devient la clé de voûte des systèmes d information géomatiques et assure le partage des données entre les applications. Les serveurs spatiaux tout comme les Systèmes d Information Géographique (SIG) deviennent conformes aux standards. Désormais le nom, le format et la technologie du serveur de données n intéressent plus personne. C est l information qui transite et le (Géo)service offert Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 10

qui ont de la valeur. C est pour cela que la mise en place d un serveur de données spatiales doit respecter les règles lui permettant d être interopérable avec l ensemble des serveurs jalonnant le réseau. Ce respect des standards sera de plus en plus demandé dans les cahiers des charges des projet SIG. Comme pour les autres types de données, ce sont les protocoles de communication et les interfaces d accès et de traitement qui sont maintenant standardisées. Le présent mémoire s emploie à définir les différentes étapes de la mise en place d un serveur spatial au sein d un système d information à toutes les échelles : de la structure des données à l architecture du système opérant final. Il repose sur l expérience acquise à la Générale d Infographie où pour le moment aucun projet ne repose sur Oracle Spatial. Ce stage de fin d étude avait donc pour objectif la mise en place du serveur spatial Oracle Spatial 1 dans différents systèmes cartographiques basés aussi bien sur des architectures client-serveur classique que des architectures multi-tiers en réseaux Intranet ou Internet. Les exemples présentés tout au long de cet exposé reposent tant que faire ce peut sur les différentes réalisations de ce stage (Paragraphe appelé «Réalisation :»). Ainsi le lecteur découvrira tout d abord les différents modèles de données apparus depuis le début des années 90 ainsi que les tendances de ces dernières années aussi bien pour le stockage de données vecteurs que les données RASTER à des fins de stockage, d échange et de visualisation de données. Ensuite est abordé l ensemble des aspects d utilisation des données au sein des serveurs spatiaux (Intégration, Indexation spatiale, Interrogation des données). Enfin sont présentées les interactions entre les serveurs spatiaux et les autres composants des systèmes d information (SIG, Serveur de carte, Catalogue) dans la mise en place de Géoservices. 1 Oracle et Oracle Spatial sont des marques déposées de la société Oracle Corporation. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 11

1.STRUCTURE DE STOCKAGE DES INFORMATIONS GÉOGRAPHIQUES SOUS SERVEUR SPATIAL Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 12/12

La mise en place des modèles de stockage repose sur les travaux de l ISO (TC211 et SQL/MM) et de l OGC présentés dans la figure 1. Le comité technique TC211 de l ISO créé en 1994 a pour mission l instauration d un ensemble de normes de base dans le domaine de la géomatique. Les activités du TC211 sont davantage centrées sur les aspects conceptuels de l assemblage des bases de données. Le SQL/MM est axé sur la nécessité d une meilleure intégration des applications géospatiales au courant principal de la technologie des bases de données. Il traite de l interrogation, de l utilisation et de l extraction des données. L OGC constitué d environ 240 entreprises d origines différentes (Oracle, ESRI, Geoconcept, Sun Microsystem ) s occupe de l interopérabilité des données géospatiales c est-à-dire la synchronisation des technologies SIG avec les standards informatiques. ISO SQL/MM Langage commun Fonctions spatiales communes Organe d'archivage dictionnaire API (OGDI) Niveau Conceptuel Niveau Logique Niveau Physique Niveau Application TC211 de l'iso: Méthodes de modèlisation Entités spatiales et opérateurs Métadonnées Définition des services OGC Procédures communes Interfaces de services Conformité COM/CORBA Java et OLE Figure 1: Relation entre les efforts de normalisation ISO et OGC L objectif de cette section est de présenter les différents modèles de stockage et d échange de données vecteurs 2 et RASTER. Seront abordés aussi bien le stockage des données au sein des serveurs spatiaux que les formats d échanges basés sur le XML entre les serveurs et les applications. De plus, seront comparés ces modèles de stockages par rapport aux formats SIG classiques en terme de taille. présentés. 2 Les formats de stockage non conforme aux normes OpenGIS tel que celui de Sybase ne seront pas Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 13

1.1 Du modèle relationnel au modèle objet-relationnel Depuis 1996, les travaux réalisés par l OGC, le TC211 et le SQL/MM ont défini les normes capables d assurer le stockage, l accès, l interrogation et la mise à jour de données spatiales par l intermédiaire de l interface ODBC. En Mai 1999, 2 standards SQL ont été définis par l OGC dans le document Open GIS Simple Features Specification For SQL Revision 1.1 : la norme appelée SQL 92 : o stockant les géométries en utilisant le format numérique SQL (using numeric types) o stockant les géométries en utilisant le format binaire SQL (using binary types) la norme appelée SQL 92 reposant sur des types géométriques (SQL 92 with geometry types) Au sein de l environnement SQL 92, une colonne contenant des valeurs géométriques est mise en place comme clé étrangère dans une table. Une géométrie est stockée dans un ou plusieurs enregistrements de cette table en utilisant soit des données de type numérique, soit des données de type binaire. Le modèle de donnée utilisé dans ce cas est de type relationnel. La notion SQL 92 avec type géométrique s explique car elle étend les capacités de l environnement SQL 92. En effet les géométries sont stockées dans une colonne dont le type est issu d un groupe de géométrie de référence. Ce groupe de géométrie standard repose sur l OGC Geometry Model présenté ci-dessous. Dans ce cas, le modèle de données mis en place est de type objet-relationnel. 1.1.1 Structure des types géométriques selon l Open GIS Consortium Geometry Model Ce modèle définit les relations entre les différents types géométriques ainsi que les fonctions d interrogations SQL applicables sur ces géométries. Dans cette section, seront décrits les différents types de géométrie. Dans sa conception, ce modèle se veut indépendant de la plateforme d utilisation. Il décrit les caractéristiques des différentes entités géographiques. Une entité géographique est définie comme «un phénomène du monde réel possédant une position sur la Terre». La classe représentant l entité géographique de référence est appelée «geometry». Elle n est pas instanciable et possède une sous-classe pour chaque type de géométrie (points, courbes, surfaces et collections). Elle est associée avec un Système à Référence Spatiale (SRS) décrivant l espace des coordonnées dans lequel l objet géométrique est défini. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 14

Figure 2: Source :(OpenGIS Simple Features Specification For SQL Revision 1.1) Hiérarchie entre les différents types de géométrie Un certain nombre de méthodes (cf. annexe 1) a été défini afin d être capable de déterminer les propriétés de chaque géométrie. Il faut noter également que pour le moment l OGC Geometry Model ne définit pas les caractéristiques des objets 3D. A partir de l OGC Geometry Model, 3 modèles de stockage de données spatiales au sein des SGBD ont été implémentés : le modèle relationnel stockant les données en utilisant le format numérique le modèle relationnel stockant les données en utilisant le format binaire le modèle objet-relationnel stockant les données géographiques en utilisant le format SQL 92 utilisant des types géométriques. La description de ces modèles présente l organisation des données géographiques au sein des serveurs spatiaux et permet de comprendre pourquoi aujourd hui le modèle objetrelationnel tend à s imposer. 1.1.2Le modèle relationnel : Premier modèle utilisé dans les bases de données géographiques La principale raison de l apparition des serveurs spatiaux est le besoin d améliorer la liaison entre données géographiques et sémantiques. Pour réaliser cela, le modèle relationnel a été le premier modèle utilisé ; celui-ci reposant uniquement sur des types de données numériques. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 15

a.support des «types primitifs» de géométrie Ce modèle permet le stockage des géométries nommées «géométries de type primitif», c est-à-dire les points, les lignes et les polygones. Point Ligne Polygone Figure 3: Les types de géométries primitives b.description du modèle de stockage pour la norme SQL 92 utilisant le format SQL numérique L environnement, défini par la norme SQL 92, détermine un modèle de stockage des données géographiques et son système de référence mais ne définit aucune fonction SQL pour l accès, la mise à jour et l indexation des géométries. Chaque enregistrement de la table des entités géométriques («Feature») possède une ou plusieurs clés étrangères dans la table «Geometry». Elle contient également les attributs des données. Renseigne sur : l identité de la table «Feature» (Catalog, schema, name) le SRID (Système de référence : Spatial Reference System IDentifier) le type de la colonne géométrie l étendue des données l identité de la table contenant les géométries les informations permettant de se déplacer au sein de la liste de coordonnées (Nombre de coordonnées par ligne). Figure 4: (Source : OpenGIS Simple Featurres Specification For SQL Revision 1.1) Modèle pour le stockage des tables selon SQL92 (Type numérique) Renseigne sur : son identifiant le nom de l auteur l identifiant de l auteur le WKT décrivant le SRS (texte descriptif du SRS) Renseigne sur les coordonnées des géométries. ETYPE décrit le type de géométrie ESEQ identifie chaque élément d une géométrie SEQ permet d identifier les éléments composés de plusieurs lignes Coordonnées X, Y Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 16

La mise en place de ce modèle sous Oracle Spatial est présentée ci-dessous. c.description du modèle relationnel utilisé sous Oracle Spatial L implémentation au sein d Oracle Spatial du stockage des données géographiques selon un environnement SQL92 utilisant le type numérique repose sur une structure à 5 tables : une table d attribut (nom_calque) une table contenant des métadonnées (nom_calque_sdolayer) une table renseignant sur l étendue du calque (nom_calque_sdodim) une table contenant les coordonnées (nom_calque_sdogeom) une table contenant l index (nom_calque_sdoindex) Figure 5: Modèle de données pour le modèle relationnel sous Oracle Sous Oracle Spatial, les différents Systèmes de Référence Spatiaux sont placés dans la table MDSYS.CS_SRS. Quelque soit le modèle de donnée utilisé, la structure de la table des SRS est celle présentée en annexe 2. Le principal avantage du modèle SQL92 utilisant le type numérique est sa compatibilité avec l ensemble des SGBDR. Ainsi l ensemble des stratégies de stockages et d optimisation des données (répliquas, table partitionnée, base de données répartie) sont directement applicables sans modification du SGBD. Cependant l accès et la mise à jour des données restent lourds du fait de la structure de stockage à 5 tables. De plus, au niveau des fournisseurs de SGBD, le modèle relationnel ne fera l objet d aucune amélioration. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 17

1.1.3Stockage au format binaire propriétaire : «Well Known Binary Format» Le stockage des données géographiques selon le Well-Known Binary format (WKBF) permet l échange au format binaire entre un client ODBC et une base de données SQL. L encodage au format binaire des données de type numérique utilise les standards d encodage au format binaire (NDR et XDR). a.type de géométrie supporté Les types géométriques supportés sont les types primitifs présentés figure 3 et les collections d éléments. b.description du modèle de stockage pour la norme SQL 92 utilisant le format binaire La structure du modèle pour le format binaire (cf. annexe 3) est la même que pour le modèle relationnel. Seul change la manière de stocker les coordonnées. Les champs Xi et Yi de la table «Geometry column» sont remplacés par un champ WKB_GEOMETRY permettant le stockage des coordonnées au format binaire. Le stockage de l ensemble des coordonnées dans ce champ permet de stocker une géométrie par ligne et donc de simplifier l accès aux données. La structure des tables, stockant les géométries selon la norme SQL92 utilisant le format binaire, est représentée dans la figure ci-dessous. Elle regroupe : un identifiant (GID) les coordonnées du MBR Le champ contenant les géométries selon le WKBFormat (Source : OpenGIS Simple Featurres Specification For SQL Revision 1.1) Figure 6: Modèle pour le stockage des tables selon SQL92 utilisant le format binaire Stocker les coordonnées du rectangle englobant permet la création d index sans avoir à accéder à la structure même de la géométrie. Ainsi il est possible de réaliser un premier filtre basé sur l emprise de la géométrie à l aide du langage SQL. Cependant il n est pas possible d accéder aux valeurs des coordonnées de la géométrie via SQL. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 18

c.exemple de stockage Figure 7: Représentation selon le Well-known Binary format selon le standard NDR (B=1) pour une géométrie de type polygone (T=3) ayant deux anneaux (NR=2) de trois points chacun (NP=3) La figure ci-dessus met en évidence la structure des données stockées au sein du format binaire. d.un format propriétaire exploité lors des débuts d ArcSDE d ESRI Ce format a été utilisé par ESRI lors d une liaison entre les SGBD et les différents produits ESRI (ArcInfo, ArcGIS, ArcIMS, ) via ArcSDE (Arc Spatial Da tabase Engine). ArcSDE réalise l ensemble des transferts de données géographique entre le SGBD et les applications SIG d ESRI. L ensemble des SGBD du marché sont utilisables avec ArcSDE (Oracle, Access, Informix, DB2 ). Cependant le format binaire empêche l exploitation de ces données par d autre application. Figure 8: Principe de fonctionnement d ArcSDE (source www.esri.com) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 19

A l origine, le modèle de stockage selon le type binaire a été utilisé. Cependant la version actuelle d ArcSDE (v 8) est également capable d utiliser le modèle objet-relationnel au sein d Oracle Spatial présenté dans la section suivante. Ainsi, d autres applications capables de se connecter à Oracle Spatial peuvent exploiter le même jeu de données. Ce changement de politique vient du fait des meilleures performances du modèle objet-relationnel pour le stockage des données géographiques et de la plus grande interopérabilité vis à vis des multiples applications SIG. En effet aujourd hui de plus en plus de SIG sont capables de se connecter en natif aux serveurs spatiaux alors que pour réaliser la liaison entre un SIG ESRI et un SGBD, ArcSDE est nécessaire. Ce qui implique un coût supplémentaire. Cependant ArcSDE propose un certain nombre de fonctions qui ne sont pas encore intégrées dans l ensemble des serveurs spatiaux (gestion des version par exemple). La structure de stockage selon le Well-known Binary Format est une structure simple mais au format propriétaire. La création de lien entre les données sémantiques et spatiales est plus aisée que pour le modèle relationnel. Cependant la limitation du format binaire propriétaire rend l accès aux données par les applications plus difficiles De plus les SGBD n ont pas de fonctions SQL capable d analyser ces données directement. Il est donc nécessaire d avoir un intermédiaire comme ArcSDE pour assurer les échanges d informations. 1.1.4Le modèle objet-relationnel : Amélioration des performances et des structures de stockage Le modèle objet-relationnel rassemble les avantages du modèle relationnel et du modèle objet (héritage, encapsulation, ). Il a conduit à l apparition de Systèmes de Gestion de Base de Données Objet-Relationnel (SGBDOR). Actuellement, il a tendance à s imposer pour le stockage des données multimédia (image, son, vidéo et données géographiques). a.type de géométrie supporté Le modèle objet-relationnel supporte les types primitifs (cf. figure 3) supportés par les modèles précédemment étudiés et des types de géométrie complexes ci-dessous. Arcs Polygone d'arcs Polygone composé Ligne composée Cercle Rectangle Figure 9: Les différents types de géométrie complexe supportés Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 20

Cependant certains types de géométrie ne sont pas encore supportés par le modèle objet-relationnel. Différents exemples sont présentés en annexe 4. b.description du modèle de stockage pour la norme SQL 92 utilisant les types géométriques Le stockage des informations concernant les Systèmes de Références Spatiales est identique à la norme SQL92 basée sur les types numériques. De plus, une table des métadonnées renseigne sur les informations pour chaque colonne contenant des données spatiales. C est-àdire : le catalogue de la table (F_TABLE_CATALOG) le schéma contenant la table (F_TABLE_SCHEMA) (ie. Propriétaire) le nom de la table (F_TABLE_NAME) le nom de la colonne contenant les données spatiales (F_GEOMETRY_COLUMN) la dimension des données (COORD_DIMENSION) l identifiant du Système de Références Spatiales (SRID) Une table contenant les données : un identifiant (GID) des attributs une ou plusieurs colonnes de type géométrique c.présentation de l objet SDO_GEOMETRY d Oracle Spatial L objet SDO_GEOMETRY permet le stockage des géométries au format Objetrelationnel constituant les calques. Il renseigne sur le système de coordonnées, son type géométrique et ses coordonnées. Cet objet est composé de 5 champs : SDO_GTYPE : Définit le type de géométrie SDO_SRID : Définit le Système de Référence Spatial (Système de Coordonnées) SDO_POINT_TYPE : Objet permettant de stocker des objets de type points SDO_ELEMENT_INFO : Renseigne sur l élément SDO_ORDINATES SDO_ORDINATES : Stocke les coordonnées des points des géométries SDO_GTYPE est un champ de type numérique. Le premier chiffre le composant indique la dimension de l objet (d=2 pour 2D, d=3 pour 3D et d=4 pour 4D) 3. Il est possible d avoir des enregistrements avec différents SDO_GTYPE dans une même table. Les chiffres suivants renseignent sur le type de géométrie : d000 : Géométrie inconnue d001 : Point d002 : Ligne d003 : Polygone d004 : Hétérogène (Points + Lignes + Polygones) d005 : Multi-point d006 : Multi-ligne d007 : Multi-polygone 3 La création des index peut être réalisée sur plus de 2 dimensions depuis la version 9.0.1 d Oracle Spatial disponible depuis juin 2001. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 21

SDO_SRID est un identifiant qui correspond à une des valeurs de la table MDSYS.CS_SRS. La table MDSYS.CS_SRS renseigne la description de l ensemble des SRS supporté par Oracle Spatial c est-à-dire son nom, un identifiant SRID, l identifiant de l auteur (AUTH_SRID), le nom de l auteur, la description de référence (WKTEXT) et les limites du SRS (CS_BOUNDS). La version 9 d Oracle Spatial supporte 952 SRS. Ce champ peut avoir une valeur NULL ; dans ce cas le SRS est inconnu. SDO_POINT_TYPE permet le stockage de données ponctuelles sur 3 dimensions. Cette colonne a été mise en place en plus de la colonne SDO_ORDINATES afin d obtenir de meilleures performances sur les données ponctuelles. Cependant, elle ne permet pas de stocker les géométries de type multi points. SDO_ELEMENT_INFO est une suite de triplets. Cet objet décrit chaque élément d une collection : OFFSET : Indique la position du premier point de l élément dans le champ SDO_ORDINATES. ELEMENT TYPE :. Est un champ de type numérique qui indique le type de géométrie INTERPRETATION : Informe sur le type d éléments. Tableau 1 : ELEMENT TYPE et INTERPRETATION associée Element type Interpretation 0 : Inconnu 1 : Point # 2 : Ligne 1 : Ligne droite 2 : Arc 1 : Ligne droite n003 : n ième Polygone de la géométrie 2 : Arc 3 : Rectangle vrai 4 : Cercle 4 : Ligne composée # n005 : n ème Polygone composé # Rq : # représente le nombre d éléments qui compose la géométrie. SDO_ORDINATES est un tableau représentant l ensemble des coordonnées de la géométrie. Figure 10: ( x 1, y1, x2, y2, x3, y3,...) Ordre des coordonnées d une géométrie au sein de l objet SDO_ORDINATES Si une géométrie est constituée de plusieurs éléments, les informations permettant de trouver les coordonnées de chaque élément sont contenues dans l objet SDO_ELEMENT_INFO. L OFFSET permet de connaître la position des coordonnées dans SDO_ORDINATES du premier point de chaque sous-élément, ELEMENT TYPE et INTERPRETATION permettent de connaître le type de la géométrie. Une table contenant un objet SDO_GEOMETRY est créée de la manière suivante : Create table LOCATION ( GID NUMBER, SHAPE MDSYS.SDO_GEOMETRY ); Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 22

Il suffit donc d indiquer lors de la création de la colonne son type : MDSYS.SDO_GEOMETRY. La syntaxe suivante, présente la création d un cercle dont (x1,y1), (x2,y2) et (x3,y3) sont 3 points situés sur la circonférence. mdsys.sdo_geometry ( 2003, null, null, mdsys.sdo_elem_info_array (1,1003,4), mdsys.sdo_ordinate_array (x1,y1, x2,y2, x3,y3) ) Le modèle objet-relationnel possède une structure simple. Il regroupe l avantage du modèle relationnel et du modèle objet. Comme pour le modèle relationnel, le langages SQL supporte les types de géométries et permet donc l interrogation des géométries. Cependant la structure de stockage sur une table simplifie grandement l exploitation des données. Par ailleurs, il est possible de créer des tables à multigéométrie c est-à-dire contenant plusieurs champ de type MDSYS.SDO_GEOMETRY (par exemple stockage de la géométrie et stockage de la localisation du label ou bien stockage de différents niveaux de précision pour différentes échelles). Le problème majeur posé par le modèle objet-relationnel est son appel au concept d objet. En effet l ensemble des SGBDR actuel n est pas capable de stocker les données spatiales selon ce modèle. A ce jour, 3 principaux Systèmes de Gestion de Base de Données sont capables de stocker des informations géographiques selon le modèle objet-relationnel : Informix Spatial Datablade 4 IBM DB2 Spatial Extende Oracle Spatial 8i 1.2 Comparaison des formats SIG classiques par rapport à celui d un serveur spatial (Oracle Spatial) Le format Shapefile 5 d ESRI est composé de trois fichiers : un fichier de forme contenant les données spatiales, un fichier d index permettant l accès aux données et un fichier d attributs regroupant les données associées avec les géométries. Une comparaison des tailles des différentes structures de stockage a été réalisée à partir du fichier World Vector Shoreline (WVS) représentant les contours des pays (Source : http://crusty.er.usgs.gov/coast/getcoast.html). WVS est composé de 210 624 géométries de type ligne. Le fichier au format Shapefile a une taille de 168 Mo. Le graphique ci-dessous compare les tailles de trois types de structure de stockage sous Oracle Spatial (Modèle Objet-relationnel avec index de type Quad-Tree et R-Tree, Modèle relationnel avec index de type Quad-Tree) avec le format shapefile. 4 Il faut noter qu Informix a été racheté par IBM en juin 2oo1. 5 La comparaison a été réalisée par rapport au format Shapefile car celui-ci est un des formats les plus communs dans le monde des SIG. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 23

Figure 11: Comparaison du format shapefile avec les différents structures de stockages sous Oracle Spatial Quelque soit le type de structure de stockage, le format Oracle Spatial est plus encombrant que le format Shapefile. Le stockage au format relationnel et le modèle objetrelationnel représente respectivement 1,12 et 1,2 fois la taille du format Shapefile. Pour un même type d index (Q-Tree SDO_LEVEL = 5), le stockage selon le modèle objet-relationnel est plus volumineux que le stockage selon le modèle relationnel. Cette différence de taille entre les deux modèles peut s expliquer d une part par l ensemble des données stockées dans les VARRAY SDO_ELEM_INFO, d autre part du fait du stockage des coordonnées dans l élément SDO_ORDINATES. En effet, lorsque le nombre de coordonnées stocké devient important (taille de SDO_ORDINATES supérieure à 4 000 octets), les coordonnées sont stockées dans des BLOB (Binary Large OBject) qui sont des structures permettant de stocker des objets de grande taille au format binaire. Ce phénomène ne s observe que sur les calques contenant des géométries complexes. Par exemple pour WVS, 67 % des coordonnées sont stockés au sein de LOB. Ceci est confirmé dans la publication «Oracle Spatial Performance-Related Characteristics» où la comparaison est réalisée sur 3 234 Shapefiles de type polygone d une taille totale de 458 Mo. La taille du format Oracle Spatial est de 620 Mo soit 1,35 fois la taille des Shapefiles. Par contre, il faut souligner que pour une utilisation optimale au format Shapefile, les fichiers sont fractionnés en plus petits fichiers alors que lors du stockage de données au format Oracle Spatial l ensemble des géométries est stocké dans une même table. Il faut noter également que la mesure de la taille des index est très variable selon le type d index réalisé sur la table. La partie 2.2 présentera les caractéristiques de l indexation spatiale. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 24

1.3 Les promesses du modèle objet-relationnel pour le stockage des données RASTER Aujourd hui les échanges de données multimédia (image, vidéo, son) se développent fortement au sein d Internet. Le monde du SIG utilise de nombreuses données RASTER au sein des applications telles que les images satellites, les photos aériennes, les orthophotos, les images radars, etc Ces images sont utilisées aussi bien comme fond de plan que comme élément d étude (Par exemple le calcul d indice de végétation sur images satellites, contrôle de surface pour les déclarations PAC 6 ). Il semble donc intéressant de voir quelles sont les possibilités de stockage de ces données RASTER encombrantes au sein des serveurs spatiaux. 1.3.1Les problèmes liés aux données RASTER Le problème majeur des données RASTER est la taille. Différentes méthodes de compression existent et permettent de résoudre en partie ce problème. La taille ne constitue pas un facteur limitant pour le stockage des données mais plutôt pour l exploitation de celle-ci. Il semble donc nécessaire d être capable d accéder seulement à la portion d image correspondant à une zone d intérêt ou de travail. Par ailleurs, les formats d images existant actuellement sont très nombreux, chacun présentant des avantages et des inconvénients. Un accès aux images sans contrainte de format permettrait ainsi une exploitation de ces données plus aisée. Il est fréquent que les utilisateurs de données RASTER se plaignent de l absence de métadonnées. De nouveaux formats d image tel que DIMAP (Digital Image Map) de Spot mis en place pour le lancement de Spot 5 insistent tout particulièrement sur cet aspect là. Le stockage au sein de SGBD permettrait de simplifier les liaisons entre les données et leurs métadonnées associées. Le stockage au sein de SGBD permet de s affranchir des traditionnels Systèmes de Gestion de Fichiers (SGF) permettant ainsi un stockage optimal des données en terme d organisation, d échanges et de conservation des données et de leurs métadonnées. 1.3.2Quelles sont les capacités actuelles des SGBD pour l exploitation des données RASTER? Le stockage des données RASTER est assez proche de celui des données géographiques du fait qu il fait appel au modèle objet. En effet la norme SQL3/MM prévoit des fonctions d exploitation des données RASTER via SQL. Certaines de ces fonctions ont déjà été mises en place au sein de certain SGBDOR (Oracle par exemple). Une partie de ces fonctions permettent par exemple de réaliser des conversions entre les différents formats. Le stockage des images permettra ainsi des possibilités de requêtes sur des objets de type image (requête sur forme, texture, sous images ). De plus le SGBD assure la sécurité des données avec une gestion des données comme il existe actuellement sur des données classiques. Ainsi les échanges de données peuvent être maîtrisés et les connexions robustes. Il est ainsi possible de mettre en place des portails de distribution ou de réception de gros volumes de données via des réseaux Intranet, Internet ou autre. 6 PAC :Politique Agricole Commune Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 25

De plus les possibilités d indexation permettront un accès rapide et fiable sur des parties d image (appelé sous-images). Par ailleurs un objet image au sein d un SGBDOR possède un certain nombre de propriétés élémentaires (type MIME, taille, format de compression ) qui peuvent être couplées à des métadonnées supplémentaires a.intermedia : Stockage des données multimédia sous Oracle Intermedia est un module d Oracle permettant le stockage de données multimédia (son, vidéo, image). Ici seul le stockage des données images sera présenté. Le stockage des images est proche du stockage de données géographiques. En effet, une image est stockée dans un objet ORDSYS.ORDImg. La structure de cet objet est la suivante : source ORDSource Données de l image height INTEGER Hauteur de l image width INTEGER Largeur de l image contentlength INTEGER Taille de l image fileformat VARCHAR2(4000) Format de l image (JFIF, GIFF, TIFF ) contentformat VARCHAR2(4000) Type de l image (monochrome, niveau de gris, RGB ) compressionformat Type de compression (JPEG, SUNRLE, VARCHAR2(4000) BMPRLE, LZW, HUFFMAN3, GIFLZW) mimetype VARCHAR2(4000) Type MIME Les images sont donc stockées dans des BLOB. Un grand nombre de formats sont supportés (Tiff, Jfif, Giff, ). Un certain nombre de méthodes d exploitation de ces objets ont été mises en place : process Modification des propriétés de l image getheigth Renvoie la hauteur de l image getwidth Renvoie la largeur de l image getformat Retourne le format de l image getmimetype Retourne le type MIME de l image L ensemble de ces fonctions a été implémenté dans la norme SQL3/MM. La méthode process permet de réaliser les traitements suivant sur des images : cut Découpage d une zone de l image compressionformat Modification du format de compression contentformat Modification du type de l image fixedscale Modification de la taille de l image RGB Modification de l ordre des couches RGB Le module Intermedia actuel est incapable d exécuter des requêtes basées sur des critères de texture, de couleur ou autre sur les images. Cependant ces fonctionnalités sont prévues dans les futures versions des modules d exploitation des données RASTER d Oracle. Par ailleurs, le traitement des données RASTER géoréférencées et les possibilités de reprojection devraient être mis en place avec le module GeoImage dans la release 2 d Oracle 9 (source David Miller, GIS consultant). Cependant, le module Intermedia couplé au module Spatial d Oracle permet de stocker des images géoréférencées. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 26

b.geoimage : Module Oracle pour la gestion des images géoréférencées Geoimage est un module qu Oracle envisage de mettre en place dans la release 2 de la version 9. La structure de stockage des données au sein de Geoimage est la suivante : Données d entête. Données vecteurs de l emprise de l image Données RASTER : l image. Figure 12: (source : Oracle Geoimage characteristics) Structure du stockage des images géoréférencées avec GEOIMAGE Elle fait appel aux objets ORDImage d Intermedia et SDO_GEOMETRY de Spatial 7. L objet OrdImage est composé de métadonnées (propriétés de l image) et d un objet OrdSource contenant l image. De plus, des fonctions de reprojection d image devraient y être incorporées. Actuellement, il n est pas en production, cependant, il est possible de mettre en place des images géoréférencées au sein d Oracle en utilisant les modules Intermedia et le module Spatial. 1.3.3Réalisation: Mise en place d une application de tuilage automatique d images géoréférencées sous Oracle L objectif de cette application est de tester les capacités actuelles d Oracle pour le stockage d images géoréférencées. Le principe repose sur l insertion d une image dans l objet OrdImage et de son emprise dans l objet SDO_GEOMETRY. Une fois l insertion réalisée, l interface propose la possibilité de tuiler l image en spécifiant le nombre de lignes et de colonnes désirées. Les méthodes des deux objets sont alors utilisées afin de réaliser le tuilage aboutissant à la génération des tuiles et de leurs emprises associées. Ensuite l utilisateur peut récupérer l image de chaque tuile ainsi qu un fichier de géoréférencement au format XML, GML ou TAB (MapInfo). La tuile est alors utilisable dans un SIG classique. 7 Remarque : La licence pour Intermedia est incluse dans la licence Oracle Server. La licence pour Oracle Spatial est quant à elle payante (environ 60 000 F) en production. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 27

Un module de visualisation est présent dans l application. Il consiste en la génération d un fichier SVG à la volée d un tuilage réalisé par l utilisateur. Seules les tuiles au format png, jpg et gif sont alors visibles du fait des limitations du SVG. Ce module est doté de fonction de zoom et permet de vérifier la bonne réalisation du tuilage. Le tuilage d une image est réalisé en 2 temps : - le chargement de l image - le tuilage Le chargement de l image est obtenu via un formulaire HTML. Il est nécessaire d indiquer le fichier image ainsi que les coordonnées de son emprise et son SRS. Le chargement vers le serveur est alors pris en charge en PHP et via l intermédiaire de procédures stockées. Le tuilage est également réalisé à l aide de procédures stockées. Figure 13: Interface de l application de tuilage en ligne Le module de visualisation permet l affichage de l ensemble des tuilages réalisés. Il permet l affichage des emprises et des images associées. Un lien est placé sur chaque image afin d accéder à une page de téléchargement de l image et des données de géoréférencement. Figure 14: Module de visualisation L annexe 6 présente les différents formats de géoréférencement téléchargeable : XML GML Mapinfo tab Aujourd hui, les serveurs spatiaux permettent donc le stockage des données RASTER de manière aisée. La mise en place de système de géoréférencement de ces données peut également être instaurée. Cependant il reste difficile de développer des applications du fait du manque d analyse (Requête, seuillage, reprojection ) réalisables sur ces données RASTER. L implémentation du module Geoimage d Oracle devrait permettre l exploitation de données RASTER comme il est aujourd hui possible de le faire avec les données vecteurs. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 28

1.4 Les nouveaux formats d échange de données : Standard de l Open GIS Consortium Aujourd hui les flux de données géographiques augmentent grandement aussi bien au sein des réseaux internes d entreprises qu entre les entreprises et le grand public. Or chaque SIG possède son propre format propriétaire ce qui limite les échanges de données géographiques. Ainsi l OGC a mis en place une norme définissant un format d échange de données géographiques. Cette norme basée sur le XML définit le Geographic Markup Language abrégé GML. Dans cette partie, seront décrites les caractéristiques de ce format d échange ainsi que celles d un format de rendu graphique de données vectorielles pour Internet : le SVG (Scalable Vector Graphic). Ces formats d échanges deviennent de plus en plus importants dans les échanges de données issues des serveurs spatiaux vers les postes clients ou vers d autres applications cartographiques ou serveurs. 1.4.1L échange de données géographiques et le GML : Geographic Markup Language L objectif de cette section n est pas de présenter les détails de la syntaxe GML 8 mais de montrer comment s organise le format GML et comment il est possible de l adapter à ses propres besoins afin de l utiliser au sein d applications exploitant des données géographiques. La dernière spécification du GML date du 20 février 2001. Elle définit la structure du Geographic Markup Language (GML) 2.0. Cette version de GML repose sur l Open GIS Geometry Model présenté dans la section 1.1.1 et n assure pas le support direct des entités géographiques 3D. Elle est compatible avec le «XML Schema Candidate Recommendation» publié en Octobre 2000 par le W3C. a.améliorations de la portabilité des données géographiques Le GML permet d encoder les données spatiales dans le but d améliorer aussi bien le transport que le stockage des données plus particulièrement dans un environnement Internet. Il doit être également suffisamment «extensible» pour supporter l ensemble des manipulations spatiales (de l affichage à l analyse). Il repose sur le XML, il y a donc séparation du contenu, de la forme et la structure comme le présente la figure 15. Les trois composantes d un fichier GML sont : le schéma Structure le fichier GML Contenu le fichier de forme Forme En effet le «schéma» définit les caractéristiques des différentes classes d objets (structure) ; le contenu est représenté par le fichier GML lui même. La forme, quand à elle, n est pas figée : en effet une application tel un catalogue de données puisera dans le fichier de contenu les métadonnées descriptives, une application cartographique pourra puiser les informations géographiques pour réaliser le rendu graphique, etc. Ainsi l apparence sera variable selon l application qui utilise le fichier. Pour cela, il faudra lui associer un fichier de forme (feuille de style, langage XSL, ). Ainsi un fichier source peut être utilisé pour différentes 8 Se référer à «Geographic Markup Language (GML) 2.0 OGC Recommendation Paper, 20 February 2001» pour le détail de la syntaxe GML. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 29

applications, l affichage étant modifié en fonction de l application et du média (Moniteur, Assistant de poche, imprimante ) améliorant ainsi grandement la portabilité des données. Le schéma décrit les caractéristiques des différentes classes d objets ainsi que les balises associées. Il permettra de définir un format de stockage GML personnalisé. A partir du moment où un document XML est lié à un schéma, ce document doit respecter les règles définies dans le schéma. Le document XML est dit «valide» s il se conforme à ces règles. GML possède un espace de nom définissant les noms réservés aux documents GML.. Il est stocké à : http://www.opengis.net/gml. Il est conforme avec les espaces de nom 9 XML («XML Namespaces Recommendation»). Les caractéristiques des classes d objets de la version 1.0 de GML reposaient sur une DTD (Définitions de Types de Documents). Elle a été remplacée par les schémas XML geometry.xsd & feature.xsd. Les DTD ont été mises en place au début du XML. Cependant aujourd hui sont préférés les schémas car ils reposent sur une structure de type XML alors que les DTD n en étaient pas. Les schémas présentent donc une structure classique XML (Arborescence balisée compréhensive). Par ailleurs, les schémas possèdent un grand nombre de types primitifs de données (ie. Chaîne de caractère, booléen, mois, ). Le schéma geometry.xsd inclus les définitions des types géométriques ((multi) point, ligne, polygone). Le schéma feature.xsd inclut les règles du schéma geometry.xsd et définit les propriétés de chaque type géométrique (MBR, ) La version 2.0 de GML supporte les collections d entités géographiques. Les fonctions de lien sont assurées par le schéma des XLINK permettant le document GML avec tous les autres types de document (HTML, GML ). geometry.xsd Include Import Feature.xsd : Structure XLinks.xsd Espaces de noms http://www.w3.org/xsl/transform/1.0 http://www.opengis.net/gml....gml : Contenu.XSL /.SVG /.X3D : Forme XLINK XLINK XLINK Document GML Document XML Document HTML Figure 15: Contenu, Forme & Structure pour le format GML 9 Les espaces de nom permettent de définir un élément ou un attribut dans un espace protégé. Par exemple les éléments XML de transformation XSL sont stockés à l adresse suivante : http://www.w3.org/xsl/transform/1.0, Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 30

Par ailleurs comme le XML, un fichier GML présente une structure arborescente balisée. Le GML est un format texte, il est donc lisible directement sans mise en page (ie. Sans fichier de forme). De plus les taux de compression applicables (gunzip par exemple) sont efficaces. Les données descriptives (ou métadonnées) sont directement incluses dans le fichier contenant les données géographiques. Ainsi toutes les informations nécessaire à l exploitation des données sont accessibles (Auteur, Date de production, Traitement, Projection, MBR, ). Le GML propose donc un format d encodage des données géographiques permettant d améliorer l interoperabilité pour le développement d applications. A ce jour, quelques uns des SIG s orientent dans cette voie. Par exemple Geomedia 4 propose l exportation des données au format GML, FME 10 propose la conversion des données au format GML 1 et 2.0. b.représentation des entités géographiques au format GML Avant de présenter les possibilités de personnalisation du GML, il semble nécessaire d avoir un aperçu de la structure des données au sein du fichier GML. L exemple présente les différentes structures de stockage des coordonnées géographiques. Il existe deux syntaxes pour l écriture des coordonnées en GML. Deux balises ont été mises en place : la balise <coord> la balise <coordinates> Leurs descriptions sont expliquées dans le schéma geometry.xsd qui fixe les règles de validité : Geometry.xsd <element name= coord type= gml:coordtype /> <complextype name= CoordType > <sequence> <element name= X type= decimal /> <element name= Y type= decimal minoccurs= 0 /> <element name= Z type= decimal minoccurs= 0 /> </sequence> </complextype> Exemple d utilisation: <Point srsname= http://www.opengis.net/gml/srs/epsg#4326 > <coord><x>5.0</x><y>40.0</y></coord> <Point> Figure 16: Schéma de la balise <coord> 10 FME : Feature Manipulating Engine, Manipulateur d entités géographiques permettant la conversion de format. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 31

Geometry.xsd <element name= coordinates type= gml:coordinatestype /> <complextype name= CoordinatesType > <simplecontent> <extension base= string > <attribute name= decimal type= string use= default value=. /> <attribute name= cs type= string use= default value=, /> <attribute name= ts type= string use= default value= 11 /> </extension> </simplecontent > </complextype> Exemple d utilisation: <Point srsname= http://www.opengis.net/gml/srs/epsg#4326 > <coordinates>5.0,40.0</coordinates> <Point> Figure 17: Schéma de la balise <coordinates> Le schéma permet donc de définir la manière d écrire les coordonnées dans le fichier GML. Il est possible d aller plu loin et d incorporer son propre schéma afin de définir des règles d écriture relative à son application. c.gml v2.0 repose sur un schéma XML afin de le rendre «extensible» Ainsi à partir du schéma GML, les utilisateurs peuvent bâtir des schémas d application. Le schéma utilisateur doit alors décrire les éléments et les types afin d identifier et distinguer les différentes entités. La méthode permettant de créer un schéma d application compatible GML est présenté dans la spécification GML2 section 4. La réalisation d un schéma d application doit suivre certaines règles : - maintien des noms, des définitions et des types de données définis pour les éléments GML - accessibilité par l ensemble des utilisateurs exploitant les données GML relatives à ce schéma - spécification de l espace de nom utilisé (qui doit être différent de l espace de nom GML) L annexe 7 présente la création des principaux éléments d un schéma (type d entité, type géométrique et propriété) ainsi que la déclaration d un espace de nom. En faisant appel au schéma d application, il est ainsi possible de définir les conditions de validité du document GML. L exemple ci-dessous présente la déclaration d un type d entité appelé «Parcelle» à laquelle il faut l associer à sa surface et la description de ses voisins via une description des règles de validité dans un schéma d application. définition de la surface de la parcelle. Donnée de type integer indication des parcelles voisines (minimum 0, maximum non limité) spécification de l objet géométrique selon le format GML 11 #x20; équivalent au symbole espace () Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 32

La figure 18 présente le schéma d application de l exemple. 1.Dans un premier temps, l espace de nom utilisateur est importé dans le schéma afin de pouvoir utilisé des balises définies par l utilisateur (qui n apparaissent pas dans l espace de nom GML). <schema targetnamespace= http://www.enitab.fr/foo xmlns= http://www.w3.org/2000/10/xmlschema xmlns:gml= http://www.opengis.org/gml xmlns:foo= http://www.enitab.fr/foo ><! Espace de nom utilisateur--> <import namespace= http://www.w3.org/2000/10/xmlschema schemalocation= Feature.xsd /> 2.Ensuite un type Parcelle est défini. Celui-ci reposant sur une entité GML gml:abstractfeaturetype à laquelle sont ajoutés des éléments complémentaires (surface ). <complextype name= Parcelle > <complexcontent> <extension base= gml:abstractfeaturetype > <sequence> <! Insertion des éléments de l entité --> <! surface de la parcelle (integer) --> <element name= surface type= integer /> <! Géométrie de la parcelle --> <element ref= gml:extentof /> <! parcelles voisines (minimum 0/ maximum non limité)--> <element ref= foo:adjacenta minoccurs= 0 maxoccurs= unbounded /> </sequence> </extension> </complexcontent> </completype> 3.Enfin un type d association issu de gml:featureassociationtype afin de permettre l identification des parcelles voisines via une balise nommée adjacenta. <! Définition du type de la parcelles voisines : type Parcelle --> <complextype name= adjacenta > <complexcontent> <restriction base= gml:featureassociationtype > <sequence> <element ref= foo:parcelle /> </sequence> <attributegroup ref= gml:associationattributegroup /> </restriction> </complexcontent> </completype> </schema> Figure 18: Exemple de schéma d application : schfoo Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 33

Ensuite, il est possible de créer un document GML respectant les règles du schéma d application schfoo. 1.Dans un premier temps l espace de nom utilisateur et le schéma sont importés dans le fichier GML <doc xmlns:gml= http://www.opengis.org/gml xmlns:foo= http://www.enitab.fr/foo xsi:schemalocation = http://www.enitab.fr/foo schfoo > 2.Ensuite les types définis dans le schéma peuvent être utilisés. Le document GML sera valide s il se conforme aux règles définies dans le schéma. <Parcelle gid= 1 > <surface>2546</surface> <gml:extentof> </ gml:extentof> <adjacenta xlink:type= simple xlink:href= #2 > </Parcelle> <Parcelle gid= 2 > <surface>25046</surface> <gml:extentof> </ gml:extentof> <adjacenta xlink:type= simple xlink:href= #1 > <adjacenta xlink:type= simple xlink:href= #3 > </Parcelle> </doc> Figure 19: Exemple d utilisation du schéma d application L utilisation des schémas pour l encodage au format GML a été bénéfique sur trois points principaux : le mélange de différents espaces de noms (richesse de vocabulaire de référence) le contrôle plus fin de la hiérarchie des définitions des types géométriques l extensibilité et la flexibilité grâce à la présence de types dérivés et de groupes de substitution. Ainsi, il est possible d'accorder la structure du schéma geometry.xsd pour l adapter à ses besoins. Dans un environnement bâti sur les serveurs spatiaux, le GML peut être un des formats d échanges à préconiser dans le cadre d application orienté Internet. Ceci est d autant plus vrai si de multiples sources de données sont utilisées. Le GML a donc été mis en place pour séparer la forme du contenu. Il donne ainsi les mécanismes de stockage des informations géographiques sans se préoccuper du «comment ces informations seront présentées à un lecteur humain». Comme il a été vu précédemment, l apparence du fichier GML sera dépendante du fichier de forme comme toute application XML. La création d un rendu cartographique sera donc réalisée de deux manières différentes : via l utilisation d une application graphique affichant les données décrites dans le fichier de contenu ou bien en utilisant une technologie graphique XML tels que le SVG (Scalable Vector Graphic) ou le X3D (VRML). Le GML n est associé à aucune notion de représentation cartographique (représentation des couleurs, ). Ainsi seront évaluées les capacités du SVG pour les applications cartographiques vectorielles sur Internet dans la partie suivante. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 34

1.4.2La cartographie vectorielle sur Internet et le SVG : Scalable Vector Graphics Fin 1999, un nouveau standard prometteur est apparu : SVG (Scalable Vector Graphics). Il offre la possibilité d'intégrer le graphisme vectoriel aux sites Internet. SVG est un standard reconnu par le W3C ; il est en constant développement. SVG 1.0 a été présenté le 2 août 2000 par le W3C comme une spécification officielle (candidate à la recommandation). SVG est un dialecte XML standardisé pour décrire le graphisme 2D (graphisme vectoriel, texte, animation, graphisme RASTER). L'intérêt manifesté par les grands acteurs de l'informatique (Adobe, Apache, Apple, AutoDesk, Bit-Flash, Corel, HP, IBM, ILOG, Inso, Kodak, Macromedia, Microsoft, Netscape, Oasis, Open Text, Oxford University, Quark, RAL, Sun Microsystems, W3C et Xerox. ) rend prévisible à court terme une application massive de cette technologie entre autre pour le rendu graphique de données GML. En effet, comme le souligne WINTER André (Institut de Géographie et de Recherche Régionale, Université de Vienne et Département New Media), le SVG «profitera sans aucun doute aux cartographes qui, pour la première fois dans l'histoire du web, seront en mesure de répondre aux demandes de représentations graphiques complexes.». a.structure d un document SVG Comme pour la figure 15 présentant la structure d un document GML, il est possible de resituer les éléments constitutifs d un document SVG. Pour cela, la figure 20, représente un document SVG en précisant le type et la localisation des trois composantes forme, structure et contenu d un fichier SVG. svg10-20000303-stylable.dtd (DTD Externe) Include DTD interne : Structure Espaces de noms http://www.w3.org/xsl/transform/1.0 http://www.opengis.net/gml....svg : Contenu.XSL /.CSS : Forme XLINK XLINK XLINK Document SVG Document XML Document HTML Figure 20: Organisation d un document SVG Un fichier SVG possède une structure semblable à tout autre document XML. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 35

b.les possibilités graphiques du SVG Un problème majeur est l'impossibilité de diffuser à l'utilisateur final (coté client) des représentations graphiques 2D en mode vectoriel de manière aisée. Depuis quelques années, l apparition des serveurs de carte permettaient la diffusion de données géographiques en mode RASTER puis vecteur grâce à des technologies complexes. L apparition du VML développé par Microsoft pour des applications orientées bureautiques, puis de Flash (Macromedia) orienté publicité et animation a conduit au développement d un standard pour la représentation de données vecteurs sur Internet : le SVG. Le SVG définit une panoplie d objets graphiques tels que les ellipses, rectangles et les formes (balise <path>) permettant d encoder tous types de formes géométriques. La couleur des objets graphiques peut être de type uniforme, gradient ou schéma (hachure). Les objets graphiques peuvent être regroupés en couche à l aide de la balise <g>. Il est possible d inclure ses propres symboles en plus des symboles prédéfinis. Ceci est très important dans le domaine cartographique pour la réalisation de légende de manière simple et homogène. Les symboles utilisateurs doivent être partagés sans pour autant demander l accord du W3C. Il est ainsi possible d utiliser des bibliothèques de symboles existantes. Des images RASTER peuvent être intégrées au document SVG. Les types supportés actuellement sont le GIF, le PNG et la JPEG. Les effets RASTER tels que les ombres, les filtres, les lumières, la transparence peuvent être définis dans le fichier de forme du fichier SVG. Les polices sont incorporées au sein du fichier SVG. Ainsi les documents originaux sont préservés. Il n est plus nécessaire de convertir au format RASTER pour préserver l apparence des textes. Des animations peuvent être mises en place via des scripts mais aussi via des éléments XML permettant de définir les déplacements et déformation d objets dans le temps. c.exemple de structure Ci-dessous est présenté un exemple de structure de document SVG. La balise <g> définit un groupe d objets ayant un identifiant id pour attribut. Ce groupe est composé d un cercle et de 2 polygones. <g id="maregion"> <path class="frontiereregion" d="m93 1085l-21-1"/> <path class="subregion" d="m113 1084c2,9 14,23 4,29"/> <circle class="poscapitale" cx="62" cy="135" r="2" /> </g> Figure 21: Exemple de structure SVG d.principes de fonctionnement du SVG La plupart des formats vectoriels mentionnés en annexe 5 sont affichés dans le navigateur au moyen d'un plugin, c'est-à-dire un programme complémentaire, qui à l'origine n'est pas intégré au programme de navigation. En outre, il s'agit souvent de formats binaires propriétaires (Flash par exemple), peu documentés, qui sont générés via des fonctions d'exportation de programmes graphiques particuliers. Pour visualiser un fichier SVG aujourd hui il est nécessaire de faire appel à un plugin. Un des plus utilisés est celui d Adobe (www.adobe.com/svg). Apache a également développé un plugin nommé Batik basé sur la Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 36

technologie JAVA. Il faut noter que le navigateur Mozilla est en cours d intégration d un plugin SVG dans son navigateur et sans doute les navigateurs Netscape et Internet Explorer feront de même dans leur prochaine version. Serveur Client Page HTML Fichier SVG Gunzip 371 Ko Fichier SVGZ 71 Ko 1.Chargement de la page HTML par le navigateur 2.chargement du fichier SVG ou SVGZ si compression Navigateur Plugin SVG 1.Décompression si svgz 2.Lecture du fichier 3.Affichage (fonctions natives) 4.Exploitation (Javascript...) 3.Chargement des images Données Raster 29 à 500 Ko selon la résolutionappelées par le fichiers SVG En rouge taille des fichiers pour l'application SVGib Figure 22: Parcours d un fichier SVG du serveur au client Le fichier SVG envoyé au client est donc affiché grâce au plugin qui peut intégrer des fonctions d affichage (zoom et autre) de manière native comme le montre la figure 23. Figure 23: Fonctions natives du plugin d Adobe Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 37

Une fois le fichier SVG affiché par le plugin, il est possible d interagir avec celui-ci. L'interactivité exige que les éléments individuels d'une page Web, y compris les objets vectoriels, soient manipulables. Aucun des formats propriétaires évoqués respecte ce principe. Pour manipuler chacun des objets, une hiérarchie des objets est nécessaire, la page Web étant l'objet supérieur. La structure simplifiée d'une page Web conventionnelle est présentée en annexe 8. A partir du Modèle d'objet de Document (DOM), il est possible de manipuler l ensemble des éléments de la page web donc du fichier SVG via un langage de script (Javascript ou Vbscript). Cette technologie a donc été mise en place dans le cadre du développement d un catalogue d images satellites reposant sur une base de données Oracle Spatial. e.réalisation: Présentation de l interface de SVGeographic Information Browser (SVGIB) : Catalogue d images satellites L objectif était de tester les capacités des différents opérateurs spatiaux d Oracle Spatial et les capacités du SVG pour le rendu graphique de données vectorielles sur Internet. Dans cette section, seule l interface SVG sera présentée. Le détail du fonctionnement de l application SVGib sera montré dans la section 3.2. L interface client repose sur un fichier SVG visualisé grâce au plugin d Adobe. Ce fichier SVG a été généré par un programme en C++ sdo2xml à partir des données contenues dans Oracle Spatial. Les possibilités de superpositions de données vecteur et RASTER ont été utilisées pour le fond de carte. Le SVG supporte trois formats RASTER ; le JPEG, le GIFF et le PNG. Le placement de l image RASTER dans le fichier est réalisé en spécifiant le coin inférieur gauche d une image ainsi que sa largeur et hauteur. Ci-dessous sont présentés les deux fonds RASTER utilisés dans SVGib. L un est un GIFF transparent, l autre est un JPEG. Figure 24: Données Raster et SVG En haut à gauche : Fond Giff transparent En haut à droite : Fond Jpg A droite : supperposition des deux fonds RASTER En plus des fonctions fournies par le plugin (figure 23), d autres fonctions ont été mises en place. Les fonctions gérées via l interface HTML sont gérées en Javascript en se basant sur le DOM de la page web de l interface (Annexe 9) : gestion de l affichage des calques (DESCW, Villes, Fond RASTER 1 et 2) interrogation du fichier SVG (Récupération du nom des villes) gestion des déplacements une zone de requête circulaire Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 38

Figure 25: localisation du curseur en degré sur les déplacement de la souris en dynamique Localisation de la vue courante dans une fenêtre de localisation L ensemble de ces fonctions est présenté sur la figure 25. Interface de SVGib. Menu (Quitter, Recherche, Info ) Carte SVG (Visualisée dans le plugin SVG d adobe Fenêtre de localisation Liste de sélection des calques visibles ou non Panneau de recherche par pays, villes ou buffer (zone de requête circulaire). Localisation X / Y (en Degré) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 39

Concernant la gestion des propriétés graphiques des objets SVG, des styles ont été définis. Ils utilisent les fonctions de couleur, de bordure et de transparence. Le format SVG montre de grandes qualités pour le rendu graphique de données vectorielles grâce aux fonctions de transparence, gradient, filtre, etc. Par ailleurs, l exploitation de données SVG via un réseau Internet semble envisageable même dans le cadre de connexion modem. Cependant il sera nécessaire de «bien penser» (utilisation des symboles, des fonds RASTER de fond de plan, ). la structure du fichier SVG et d utiliser la compression au format gunzip afin de minimiser au maximum le poids du fichier SVG et donc le temps de chargement. De plus un document SVG comme tout document XML est un fichier texte. Une fois téléchargé par le client, ce dernier est capable de lire l intégralité des données contenues dans le fichier. Ceci pose donc le problème de la confidentialité des données surtout que dans le cadre du SVG, les données envoyées sont des données vecteurs. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 40

Depuis le début des années 90, de grands changements ont affecté les modèles de stockages des données géographiques. Les travaux de l ISO et de l OGC ont permis la normalisation des trois structures de stockages au sein des serveurs spatiaux. La tendance actuelle est l abandon des modèles relationnels (format numérique et binaire) pour le modèle objet-relationnel. Grâce à ce modèle et à la norme SQL/MM, le stockage, la manipulation et l interrogation des données géographiques sont simplifiés et normalisés. De plus, dans le cadre des échanges de données géospatiales, un grand nombre de logiciels SIG sont actuellement capables d exploiter ces données en natif. De plus, dans un avenir proche, l exploitation des données RASTER devrait également être implémentée en production au sein des serveurs spatiaux regroupant ainsi l ensemble des données spatiales et non spatiales. Pour ce qui concerne les échanges de données dans un environnement Intranet et Internet, l OGC et le W3C élaborent les standards d échange de données basés sur le XML. Ainsi le GML devrait être le format d échange de données géographiques principales entre l ensemble des acteurs du monde des SIG ; celui-ci étant soutenu par le SVG pour le rendu graphique des données vectorielles dans un contexte Internet et Intranet. L intégration, la manipulation et l analyse des données spatiales au sein des serveurs spatiaux sont elles-aussi en cours de normalisation grâce à la prochaine norme SQL :SQL3/MM qui est prévue pour septembre 2001. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 41

2.INTÉGRATION, MANIPULATION ET ANALYSE DES DONNÉES SPATIALES Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 42

La dernière version de la norme SQL date de 1999 avec l apparition de SQL3. Conjointement à l élaboration du SQL3, le SQL3/MM a été esquissé. Le SQL3/MM n est pas encore finalisé mais devrait l être d ici la fin de l année 2001. Cette nouvelle norme spécifiera l ensemble des méthodes applicables sur les objets (aussi bien géographiques que les objets multimédia telles que la vidéo, les images, ). Actuellement les langages SQL implémentés dans les SGBD sont les précurseurs de SQL3/MM. SQL3/MM permettra de créer un standard SQL commun à l ensemble des SGBD pour l interrogation des objets multimédia. Les propriétés du SQL3/MM seront sans doute assez proches de l ensemble des fonctions SQL présentées dans ce document qui sont issues de l utilisation d Oracle version 8i et 9. Cette section a pour but la présentation des différentes étapes de la mise en place et de l analyse des données spatiales au sein des serveurs spatiaux. Dans un premier temps, seront présentés les processus d intégration de données issues de différentes sources. Ensuite seront exposées les procédures d indexation de données spatiales et dans une dernière partie seront étudiées les méthodes d analyses de données spatiales sous serveurs spatiaux. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 43

2.1 Réalisation : Intégration de données vers le modèle objet-relationnel Actuellement, un grand nombre de base de données assure le stockage de l ensemble ou partie (attributs) de données géographiques. Cette section présente les différentes possibilités d intégration de données spatiales vers un modèle de stockage objet-relationnel type Oracle Spatial 8.1 ou supérieur 12. Les types de migration possibles sont : migration d un modèle relationnel vers un modèle objet-relationnel migration de données géographiques stockées selon un format non normalisé vers le modèle objet-relationnel migration de données à partir d un format SIG propriétaire. Les procédures de migration seront présentées sous forme d exemple. 2.1.1Du modèle relationnel au modèle objet-relationnel : Catalogue d images satellites Apries2 a.présentation des données géographiques d APRIES Apries est une base de données contenant l ensemble des emprises des images satellites du Centre Géographique Interarmées (CGI). L objectif est de réaliser la migration de ces données vers le modèle objet-relationnel pour la migration de l application de Geomedia 3 vers Geomedia 4 13. Cette base de données contient 5 calques différents contenant tous des géométries de type polygone. Chaque calque correspond à un type d image. Ces calques sont stockés selon le modèle relationnel présenté dans la section 1.1. Chaque calque est donc stocké sur 5 tables : <calque> Stockage des attributs <calque>_sdogeom Stockage des coordonnées <calque>_sdolayer Stockage des informations d indexation <calque>_sdoindex Stockage de l index <calque>_sdodim Stockage du rectangle englobant b.mécanisme de migration L objectif est de réaliser la migration de ces données du modèle relationnel au modèle objet. La fonction SDO_MIGRATE.TO_81X d Oracle Spatial a été utilisée. Le système de coordonnées est WGS84. L étendue de chacun de ces calques est lat(-90,90) / long (-180,180). 12 En effet des modifications ont été apportées à l objet MDSYS.SDO_GEOMETRY entre la version 8.0.et 8.1 (se reporter à «Oracle Spatial :Installation, Migration» pour plus de détails sur la nature des changements. 13 Geomedia est un SIG de la gamme Intergraph Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 44

Afin de les convertir le script suivant a été utilisé pour chaque table. 1.Connexion à la base connect exploit/exploit@ap2 2.Suppression de la table qui va être créée -- SPATIO_IGN_ESPACE -- 1.Suppression de la table qui va être créée si une table portant le même nom existe déjà DROP TABLE SPATIO_IGN_ESPACE_MOR; 3.Création de la table avec un champ de type MDSYS.SDO_GEOMETRY -- 2.Création de la table CREATE TABLE SPATIO_IGN_ESPACE_MOR (GID NUMBER CONSTRAINT pk_spatio_ign_espace_mor PRIMARY KEY, SHAPE MDSYS.SDO_GEOMETRY); 4.Insertion des métadonnées dans la table des métadonnées. Cette étape est obligatoire pour l exploitation ultérieure des données. -- 3.Mise à jour des métadonnées dans la table USER_SDO_GEOM_METADATA du schéma MDSYS INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO) VALUES ('SPATIO_IGN_ESPACE_MOR', 'SHAPE', MDSYS.SDO_DIM_ARRAY (MDSYS.SDO_DIM_ELEMENT('X', -180, 180, 0.000000050), MDSYS.SDO_DIM_ELEMENT('Y', -90, 90, 0.000000050) ) ); COMMIT; 5.Exécution de la fonction de migration SDO_MIGRATE.TO_81X. Les paramètres indiquent la table source, la table destination, l identifiant de la table destination et le nom de la colonne de type MDSYS.SDO_GEOMETRY. La colonne GID est définie en tant que clé primaire. -- 4.Exécution de la fonction de migration EXECUTE SDO_MIGRATE.TO_81X( 'SPATIO_IGN_ESPACE','SPATIO_IGN_ESPACE_MOR','GID','SHAPE'); Figure 26: Processus de migration de données depuis le modèle relationnel La figure 27 présente le résultat de l importation des données Apries2 dans Mapinfo. Figure 27: Données APRIES2 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 45

La migration d un modèle relationnel au modèle objet-relationnel a été réalisée avec succès sur des calques de type ligne et polygone. Cependant des avis signalent des problèmes lors de l utilisation des fonctions de migration d Oracle Spatial. «L outil de migration du modèle relationnel vers le modèle objet n est pas conseillé, il est préférable de décharger les données dans le SIG, puis recharger les données dans Oracle spatial objet. En règle générale, le passage du modèle relationnel au modèle objet doit se faire après une bonne étude des données, des volumes et des étapes de migration (Ce n est pas évident). Globalement des données stockées dans le modèle relationnel occuperont à peu près le même volume en modèle objet. L espace occupé est très dépendant de la précision des coordonnées (précision des réels )» signale Fabrice Berranger dans son compte rendu de formation Oracle Spatial 8i du 28 & 29 février 2oo1. Parfois, certains utilisateurs ont développé des modèles de stockage de données géographiques personnalisés dont la migration est un peu plus délicate. 2.1.2D un modèle de données non normalisé vers le modèle objet-relationnel : Catalogue d images satellites GIB de l UEO GIB (Geographic Information Browser) est une application réalisée pour le Centre Satellitaire de l Union de l Europe Occidentale (UEO). Elle permet la gestion et la consultation d images satellites. Le modèle de stockage des données géographiques mis en place a été personnalisé dans le but d être assez proche de la manière de représentation des données géographiques d ILOG Views qui est le composant logiciel à partir duquel GIB est développé. Cependant ce modèle est inexploitable par les fonctions spatiales d Oracle Spatial, la migration vers le modèle objet-relationnel a donc été réalisée. a.présentation des données géographiques de GIB 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 Alpha 14 ). 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. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 46

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 GIB 15. 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». Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 47

); ) ) 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 loi 16 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. SDO_GEOMETRY 16 Remarque sur les alias : l utilisation d alias est obligatoire pour l accès aux éléments de l objet Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 48

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 objetrelationnel 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 objetrelationnel. 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 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 49

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 objetrelationnel 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. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 50

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é. a.quad-tree Hybride (QTH) L index de type Quad-tree Hybride a été mis en place dans les premières versions d Oracle Spatial. Le tuilage des index hybrides colle à la forme des objets. Le nombre de tuiles augmentent autour des objets et diminuent dans les zones dépourvues d objets ; le nombre de tuile par objet correspondant au paramètre SDO_NUMTILES. Figure 29: Quad-tree Hybride b.quad-tree Fixe (QTF) Le tuilage des index fixes est constitué de tuiles de taille fixe. Seul le niveau de profondeur du tuilage est à déterminer. Figure 30: Quad-tree Fixe Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 51

La figure 31 montre la représentation des deux types d index Quad-Tree. Figure 31: Visualisation des index avec Spatial Advisor En haut à gauche : QTF SDO_LEVEL = 7 En haut à droite : QTF SDO_LEVEL = 6 A gauche : QTH SDO_LEVEL = 7, SDO_NUMTILES = 6 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 52

2.2.3R-tree (RTR) Les index de type R-tree (Region Tree) ont été implémentés en bêta dans la version 8.1.6 et en production dans la version 8.1.7 d Oracle Spatial. Les index de type R-tree définissent pour chaque géométrie la MBR (Minimum Bounding Rectangle ie. l étendue). Cette étendue constitue les feuilles de l arbre de l index. Ensuite ces feuilles sont regroupées dans des rectangles plus grands. Cette action est réalisée jusqu à l obtention d un seul rectangle contenant l ensemble des géométries du calque. Du fait de ses propriétés il peut être facilement utilisé pour l indexation d objet en 3 dimensions ou plus 18. Figure 32: Concept de l indexation de type R-tree 2.2.4Choix du type d index selon les données Avec la Release 3 d Oracle, les différents guides d utilisation conseillent l utilisation des index de type R-Tree dans la majorité des cas. Il est possible de maintenir 2 types d index différents sur la même colonne de type SDO_GEOMETRY. Lors des requêtes, il sera alors nécessaire de spécifier la table d index à utiliser en utilisant le paramètre idxtab1 or idxtab2. 9 d Oracle. 18 L indexation sur 3 et 4 dimensions pour les index de type R-Tree est en production depuis la version Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 53

Tableau 3 : Quad-tree L approximation d une géométrie peut être très fine du fait des 2 paramètres de l index hybride Difficulté de réglage Peu sensible aux mises à jour Comparaison des deux grands types d index: R-Tree L approximation d une géométrie ne peut pas être bien réglée car les R- Tree se basent sur la MBR Création facile Peut devenir instable en cas de nombreuses mises à jour (dans ce cas il faut augmenter le paramètre RTR_PCTFREE) Peut être étendu à 3 voir 4 dimensions Plus rapide pour les requêtes de type SDO_NN (plus proches voisins) Les caractéristiques d un bon index de type Quad-Tree sont les suivantes: Environ 200 tuiles pour une zone de requête Environ 10000 tuiles pour l étendue du calque Présence de tuile à l intérieur des géométries Un index hybride est préférable dans les cas suivants : Si un calque possède un mélange de petites géométries couvrant une petite surface et de grands polygones couvrant une grand surface (ie. lorsque l écart type des aires des polygones est important). Ainsi le nombre de tuile par géométrie reste constant ce qui limite l augmentation de la taille de l index. Si des requêtes de type jointure doivent être réalisées entre 2 calques dont la différence des SDO_LEVEL optimum est supérieure à 4, alors les performances seront sans doute meilleures en diminuant le SDO_LEVEL du calque ayant le SDO_LEVEL le plus élevé, puis en créant un index de type Quad-Tree hybride en lui donnant une valeur non nulle pour SDO_NUMTILES. Une bonne valeur de départ pour le SDO_NUMTILES est : SDO_NUMTILES = nb de ligne de l index QTF / nb de ligne de la table Un certain nombre de fonctions a été mis en place au sein des serveurs spatiaux afin d aider la mise en place des index : SDO_TUNE.ESTIMATE_INDEX_PERFORMANCE Estime la sélectivité d un index en fonction du niveau de tuilage. SDO_TUNE.ESTIMATE_TILING_LEVEL Détermine une valeur du niveau de tuilage pour un index Quad-Tree SDO_TUNE.ESTIMATE_TILING_TIME Estime le temps de création de l index (en s) SDO_TUNE.ESTIMATE_TOTAL_NUMTILES Estime le nombre total de tuile pour un calque La création d un index fait donc appel à l analyse des données à indexer mais aussi de leur utilisation (fréquence des mises à jours). De plus la création d un index est une tâche Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 54

relativement longue, coûteuse en ressource matérielle (CPU et mémoire) qui augmente avec la quantité de données et avec le niveau de tuilage pour les index de type Quad-tree. L indexation spatiale est une des étapes les plus importantes de la mise en place d un serveur spatial. Trois types d index présentent des caractéristiques différentes : Le type R-Tree basé sur les MBR, semble être le plus simple à mettre en place et le plus performant dans la majorité des cas. Son problème majeur réside sans doute dans son instabilité face aux mises à jour. Le type Quad-Tree Fixe dont le paramètre principal est le niveau de tuilage présente de bonnes performances. Il est à conseiller pour les calques présentant des géométries aux caractéristiques (surface et répartition) assez homogènes. La précision s obtient en augmentant le niveau de tuilage et donc en augmentant parfois considérablement la taille des tables d index. Le type Quad-Tree hybride est à utiliser dans des cas particuliers (calques non homogènes). Afin de choisir les meilleurs paramètres d indexation, un certain nombre de fonctions d estimation aide à la mise en place de ces index et permet d évaluer leurs performances pour l accès aux données. 2.3 Relation spatiale et analyse spatiale L analyse spatiale des données directement au sein des serveurs spatiaux permet de s affranchir du logiciel SIG. D après Alain Prallong (Realia), «80% des données manipulées par les organisations, qu elles soient publiques ou privées, sont localisées dans l espace». L implémentation de ces fonctions d analyse spatiale permet d étudier des phénomènes géographiques sans faire appel nécessairement à une visualisation cartographique. L implémentation des méthodes d analyse spatiale a été définie dans l OGC Geometry Model. Les principaux opérateurs spatiaux seront présentés via la description des opérateurs implémentés dans différentes applications dont SVGib dont l interface a été présentée dans la section 1.4.2.e. 2.3.1Analyse des relations spatiales grâce aux modèles des 9 intersections De manière générale, les relations spatiales sont séparées en trois catégories : les relations spatiales de distance les relations spatiales d orientation les relations spatiales topologiques Cette section décrit les différents types de relation spatiale réalisable au sein des serveurs spatiaux. Ces relations ont été définies dans l OGC Geometry Model. De plus des exemples de syntaxe des commandes SQL pour Oracle Spatial montreront les possibilités d analyses offertes au sein des SGBD. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 55

a.les relations spatiales de distance Les relations spatiales de distance englobent des informations qualitatives et des informations quantitatives. Des exemples de relations spatiales de distances sont : Plus proches voisins : Cette fonction renvoie le nombre de voisins les plus proches d un géométrie donnée (par exemple les 5 parcelles les plus proches d une source). Tampon (géodésique & projeté) : Cette fonction détermine si 2 objets sont éloignés d une distance inférieure à d (d largeur du tampon). Rq : Les calculs de distance dans le cas des données géographiques sont plus ou moins difficiles selon que les données sont projetées ou non (coordonnées géodésiques). Avant la version 9 d Oracle Spatial, des imprécisions ont été notées sur le calcul des distances pour les données non projetées. b.les relations spatiales d orientation Les relations spatiales d orientation permettent de donner des informations sur l orientation d un objet par rapport à un autre. Ce type de relation intervient fréquemment dans les méthodes de parcours de graphes (réseau). Actuellement, elles n ont pas été implémentées au sein des serveurs spatiaux. c.les relations spatiales topologiques Les relations spatiales topologiques interviennent fréquemment lors de l exploitation des données spatiales. Elles donnent une description de l espace en terme d intersection entre les différentes composantes des objets étudiés (intérieur, frontière, extérieur). Il est ainsi possible de distinguer les relations de tangence, disjonction ou inclusion. Au sein des serveurs spatiaux, l évaluation des relations spatiales topologiques repose sur une extension du modèle des «9 intersections» (9IM). 9IM est un modèle apparu en 1991 lors des travaux du professeur Max Egenhofer (Université du Maine) puis repris par T.Y. Jen. Il a été repris dans l OGC geometry model pour définir les différents types de relations topologiques entre objets. Le modèle utilisé par l OGC est appelé DE-9IM pour Dimensionnaly Extended Nine-Intersection Model (Modèle des 9 intersections prenant en compte les dimensions des objets) qui, en plus de définir la présence ou l absence d intersection comme le faisait le 9IM, définit la dimension de l intersection. Un objet «a» est caractérisé par trois composantes : F(a) : sa frontière I(a) : son intérieur E(a) : son extérieur La frontière d un objet est définie comme un groupe de géométrie de dimension inférieure à l objet. La frontière d une courbe non fermée est constituée de ses 2 extrémités. La frontière d une courbe fermée est vide. Le frontière d un polygone est composée de ses cotés. L intérieur d un objet correspond à ce qu il reste lorsque l on retire sa frontière. L extérieur d un objet est représenté par les points n étant pas à l intérieur ni sur sa frontière. Tout couple d objet possède 9 types de relations entre leurs trois composantes. La dimension de l intersection entre deux composantes est comprise dans l ensemble {-1,0,1,2). -1 correspondant à l ensemble vide dim( ). L ensemble des relations liant 2 géométries est Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 56

représenté par une matrice 3x3 des 9 intersections représentant la dimension de l intersection entre les composantes. a b Intérieur Frontière Extérieur Intérieur dim( I( a) I( b)) dim( I( a) F( b)) dim( I( a) E( b)) Frontière dim( F( a) I( b)) dim( F( a) F( b)) dim( F( a) E( b)) Extérieur dim( E( a) I( b)) dim( E( a) F( b)) dim( E( a) E( b)) Figure 33: Matrice des intersections selon le DE-9IM (a) (b) a b Intérieur Frontière Extérieur Intérieur 2 1 2 Frontière 1 0 1 Extérieur 2 1 2 Figure 34: Exemple : La matrice correspondant à deux polygones se chevauchant est de la forme «212101212». La «matrice résultat» est ainsi comparée aux matrices de référence pour définir le type de relations topologiques entre les deux objets. La matrice de référence contient 6 valeurs différentes : p=t dim(x) {0,1,2}, ie. x Point ou ligne ou polygone p=f dim(x) = -1, ie. X= Ensemble vide p=* dim(x) {-1,0,1,2} p=0 dim(x) = 0 Point p=1 dim(x) = 1 Ligne p=2 dim(x) = 2 Polygone Ainsi ont été définies 5 matrices de référence (cf. annexe 14) pour les principaux type de relation topologique (source : OGC Geometry Model) : Disjoint (DISJOINT) : Touche (TOUCHES) : Croise (CROSSES) : A l intérieur (WITHIN) : Chevauchant (OVERLAP) : Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 57

D autres relations complémentaires ont été définies pour aider l utilisateur lors de l analyse des relations spatiales. Contient (CONTAINS) : a.contains(b) b.within(a) Intersecté (INTERSECTION) : a.intersect(b) a.disjoint(b) La matrice de l exemple figure 34 2 1 2 12 0 1 1 2 T correspond à la matrice ** * T T * références correspondant à des objets se chevauchant. Les opérateurs spatiaux reposent donc sur ce modèle défini par l OGC. 2.3.2Principe de fonctionnement des opérateurs spatiaux SQL sous Oracle Spatial Deux étapes principales sont réalisées afin de résoudre une requête spatiale. Le résultat de ces deux étapes conduit à la solution exacte. Le premier filtre : Celui-ci permet de réaliser une sélection rapide des enregistrements à partir des index. Il permet de réduire la complexité de calcul pour le second filtre en sélectionnant un groupe d enregistrement parmi l ensemble des enregistrements. Le second filtre réalise un calcul exact sur les géométries. Il renvoie la solution exacte de la requête. Il est beaucoup plus exigeant en termes de temps de calcul. de SDO_FILTER SDO_RELATE Figure 35: Fonctionnement des requêtes Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 58

Sous Oracle Spatial, la fonction SDO_FILTER permet de réaliser le premier filtre et la fonction SDO_RELATE renvoie le résultat exact (1 er & 2 ème filtre). 2.3.3Influence du type d index sur les performances des requêtes spatiales L étude des performances réalisée dans Oracle Spatial 8.1.6 Performance-Related Characteristics montre que les meilleurs résultats sont obtenus pour un SDO_LEVEL = 8 pour les calques de type ligne. Figure 36: (Source : Oracle Spatial 8.1.6 Performance Related Characteristics) Temps d exécution de requête fonction du niveau de tuilage pour 2 calques de type ligne (1 & 2) Le graphique ci-dessus présente la vitesse du premier filtre (Filter) et du deuxième (Relate). Par contre pour les calques de types point et polygone, la vitesse est améliorée lorsque le SDO_LEVEL augmente. Le graphique ci-dessous présente l évolution du nombre de géométries par seconde renvoyées en fonction de la distance au centre de la zone de requête. Figure 37: (Source : Oracle Spatial 8.1.6 Performance Related Characteristics) Effet de SDO_LEVEL sur les performances de SDO_RELATE Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 59

L augmentation du niveau de tuilage permet de retrouver plus rapidement les géométries lorsque la zone de requête est petite. Cependant lorsque la zone de requête augmente, le nombre de géométries trouvées par seconde devient équivalent. (Source : Oracle Spatial 8i : Installation, Indexation, ) Figure 38: Comparaison des vitesses des requêtes RELATE et FILTER pour le calque COUNTRIES (Polygones) en fonction des différents types d index Les trois courbes représentant la vitesse du premier filtre (Filter) sont les plus rapides. La vitesse du premier filtre est plus rapide lorsque l index est de type R-Tree. Par contre pour la réalisation du deuxième filtre, la requête réalisée avec l index de type R-Tree est la plus lente. Figure 39: (Source : Oracle Spatial 8i : Installation, Indexation, ) Comparaison des vitesses des requêtes RELATE et FILTER pour le calque CITIES (Point) en fonction des différents types d index Pour les résultats concernant le calque Cities qui est un calque contenant des géométrie de type point, l efficacité du R-Tree est à nouveau montrée pour le premier filtre. Les temps d exécution obtenus pour le second filtre montrent que les performances restent équivalentes pour le RTR et le QTF. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 60

Les index QTF et QTH présente le même comportement. Cependant l étude des performances réalisée dans Oracle Spatial 8.1.6 Performance-Related Characteristics montre que les index fixes sont plus efficaces pour les requêtes sur de grandes étendues mais sont moins efficaces sur les requêtes sur de petites étendues. Performance du filtre SDO_RELATE pour les QTF et les QTH 20 Temps (en s) 15 10 5 0 0 20 40 60 80 100 Taille de la fenêtre de requête BG L=14, N=8 BG L=14 Figure 40: Comparaison entre index QTF et QTH 19 (Source : Oracle Spatial 8.1.6 Performance Related Characteristics) Performance du filtre SDO_RELATE pour de petites tailles de fenêtre 0,8 Temps (en s) 0,6 0,4 0,2 0 0 0,5 1 1,5 2 Taille de la fenêtre de requête BG L=14, N=8 BG L=14 Figure 41: (Source : Oracle Spatial 8.1.6 Performance Related Characteristics) Comparaison entre index QTF et QTH pour de petite taille de fenêtre En conclusion de cette comparaison des performances des requêtes selon le type d index, aucune tendance franche ne peut être présentée. En effet, les performances sont très 19 L correspond au paramètre SDO_LEVEL (niveau de tuilage) et N au paramètre SDO_NUMTILES (nombre de tuile par géométrie). Un index ayant comme seul paramètre L est de type Quad-Tree Fixe (QTF), un index ayant N et L est un index de type Quad-Tree Hybrid (QTH) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 61

liées avec le type, la répartition et la structure des géométries contenues dans le calque. Il est donc nécessaire d analyser principalement : - la répartition des géométries et leurs principales caractéristiques (Surface +/- écart type pour les polygones) - le niveau de tuilage optimal du calque avec les opérateur d Oracle Spatial 2.3.4Présentation des différents opérateurs géographiques sous serveur spatial Cette section constitue un catalogue présentant les différents opérateurs spatiaux disponibles sous Oracle Spatial. Certains des exemples sont analysés à partir de réalisations concrètes tel que SVGib. Les syntaxes des principaux opérateurs sont présentées en annexe 15. a.analyse des relations topologiques : Exemple de SVGib SVGib permet la recherche d élément en se basant sur le type de relation qui lie deux objets. Par exemple lors d une recherche d emprise par pays, il est possible de choisir le type de relation désirée : A l intérieur de Contenu dans Contenant Figure 42: Interface de recherche par pays La syntaxe de la requête exécutée est la suivante : select des.descw_id DESCW_ID, cnt.cntry_name CNTRY_NAME, des.quicklook QUICKLOOK from BRW.DESCW des, SPATIAL.COUNTRY cnt where cnt.cntry_name = '$country' and SDO_RELATE (des.shape, cnt.shape,'mask=$mask querytype=join') = 'TRUE' Rq : - en bleu la syntaxe SQL classique - en rouge l opérateur spatial - en vert les variables $country déterminant le pays et $mask déterminant le type de relation topologique à réaliser (les valeurs de $mask peuvent être : anyinteract / inside / overlapbdyintersect / contains) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 62

Figure 43: Comparaison des relations topologiques Recherche réalisée sur l Égypte : En haut à gauche : Toutes les relations topologiques En haut à droite : à l intérieur A gauche : sur les frontières Recherche réalisée sur Andorre : En bas à gauche : contenant Figure 44: Résultats des trois types de relations topologiques b.analyse des relations de distance : Exemple de SVGib Lors d un clic sur une emprise, le détail des informations relatives à l emprise est présenté. Il est alors possible de rechercher les X voisins les plus proches de l emprise sélectionnée. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 63

Figure 45: Interface de recherche des plus proches voisins d une emprise La syntaxe de la requête exécutée est la suivante : select des.descw_id DESCW_ID, des.quicklook QUICKLOOK from BRW.DESCW des where SDO_NN (des.shape,(select SHAPE from brw.descw where descw_id='$id'), 'sdo_num_res=$nbnn')='true'"; Rq : - en bleu la syntaxe SQL classique - en rouge l opérateur spatial - en vert les variables $id déterminant l emprise sélectionnée et $nbnn déterminant le nombre de voisin recherché Figure 46: Recherche des 9 voisins les plus proches d une emprise sélectionnée Emprise sélectionnée c.opérateurs complémentaires Reprojection : Oracle Spatial propose 2 fonctions permettant le changement de projection. SDO_CS.TRANSFORM permet le changement de projection d une géométrie dans un calque. SDO_CS.TRANSFORM_LAYER permet le changement de projection d un calque entier. Cette dernière a été utilisée pour changer la projection d un calque placé dans une table WORLD. La projection initiale de ce calque est : SRID : 8307 CS_NAME : Longitude / Latitude (WGS 84) WKT :GEOGCS [ "Longitude / Latitude (WGS 84)", DATUM ["WGS 84", SPHEROID ["WGS 84", 6378137.000000, 298.257224]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]] Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 64

Ce calque a été reprojeté selon la projection Azimuthal Equidistant (North Pole) (SRID : 106496) et la projection Sinusoidal (WGS 84) (SRID :1). La commande ci-dessous permet la reprojection. EXECUTE SDO_CS.TRANSFORM_LAYER('table_name_in', 'column_geom_in', 'table_name_out', SRID); Figure 47: Reprojection avec Oracle Spatial (version 8 ou supérieure) En haut à gauche : Longitude / Latitude (WGS 84) En haut à droite : Sinusoidal (WGS 84) A gauche : Azimuthal Equidistant (North Pole) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 65

Réalisation d un tampon et calcul du polygone de Hull autour d un géométrie : Une fonction appelée SDO_GEOM.SDO_BUFFER permet la création d un buffer. La requête suivante propose la mise à jour d un champ appelé BUFFER de type SDO_GEOMETRY dans une table à partir d un champ appelé SHAPE de type SDO_GEOMETRY dans la même table. UPDATE BUFFER SET (BUFFER) = (select mdsys.sdo_geom.sdo_buffer( tn.shape, distance, tolérance) from table_name tn where tn.gid = table_name.gid ); Figure 48: Buffer réalisé autour de la France Figure 49: Résultat de la fonction SDO_CONVEXHULL 20 pour l Europe Opérateurs d union, Intersection, Xor 21 et Difference Chacune des fonctions est présentée sous forme d un script PL/SQL en annexe 15 qui ajoute la géométrie résultat dans une table. Les fonctions utilisées sont : SDO_GEOM.SDO_UNION Union SDO_GEOM.SDO_XOR Xor SDO_GEOM.SDO_INTERSECTION Intersection SDO_GEOM.SDO_DIFFERENCE Différence 20 Le polygone de Hull est le plus petit polygone englobant une géométrie. 21 Xor correspond au Ou exclusif Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 66

Figure 50: Opération d union, d intersection et de différence En haut à droite : Union des polygones France et Espagne En haut à gauche : Différence entre la France et son polygone de Hull A gauche : Intersection entre la France et un rectangle de coordonnée LLC 22 (-5,44) URC (2,51) En bas à gauche : XOR entre le même rectangle et la France Autres opérateurs D autres opérateurs permettent le calcul : o Des surfaces (SDO_GEOM.SDO_AREA) o Des longueurs ou périmètres (SDO_GEOM.SDO_LENGTH) des géométries o Des distances (SDO_GEOM.SDO_DISTANCE) o D un point sur la géométrie (SDO_GEOM.SDO_POINTONSURFACE ou SDO_GEOM.SDO_CENTROID). La majorité des possibilités de recherche d un SIG classique est retrouvée dans les serveurs spatiaux. Cependant ces fonctions sont directement accessibles via le langage SQL. Par ailleurs dans certains cas où la visualisation graphique des résultats d une requête spatiale n est pas nécessaire, seul le serveur spatial suffit. 22 LLC : Lower Left Corner / URC : Upper Rigth Corner Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 67

L intégration de données provenant de sources diverses (modèle relationnel, modèle non normalisé ou format SIG) sous serveur spatial ne présente pas de difficulté majeure. La méthode permettant de traiter de matière exhaustive l insertion de données est sans doute l utilisation de FME. Cependant celle-ci reste onéreuse. Dans des situations plus spécifiques, il faudra faire appel soit à des programmes existants (shp2sdo 23 par exemple), soit au développement de procédures d intégrations. Une fois ces données intégrées dans le SGBD, une phase d indexation est nécessaire. Celle-ci doit être réfléchie car elle peut influer grandement sur les performances des requêtes. Cependant aucune véritable règle n existe, il est nécessaire d analyser les caractéristiques géométriques du calques (surface, répartition des entités ) et d utiliser les opérateurs d estimation des paramètres optimum d Oracle Spatial. Les serveurs spatiaux actuels proposent la majorité des opérateurs spatiaux disponibles au sein des SIG classiques. Ces opérateurs sont simples d implémentation car il font appel au langage SQL qui sera normalisé en ce qui concerne l ensemble des opérateurs spatiaux d ici la fin de l année 2001 sous le nom de SQL3/MM. De plus l ensemble des données géographiques intégrées dans les serveurs spatiaux a pour vocation d être partagé entre de multiples utilisateurs. Ainsi grâce aux efforts de normalisation aussi bien au niveau de la structure que de l accès aux données, les serveurs spatiaux vont être les acteurs principaux de l ensemble des systèmes d information exploitant des données «géolocalisées». 23 shp2sdo est un programme permettant l insertion de données au format shapefile dans Oracle Spatial. Il est distribué par Oracle mais non supporté. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 68

3.MISE EN PLACE DES SERVEURS SPATIAUX EN ENVIRONNEMENT MULTI-UTILISATEURS Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 69

Autour des serveurs spatiaux vont graviter un grand nombre d applications aussi bien Intranet qu Internet ; ces applications internes développées par l entreprise ou applications externes à l entreprise vont exploiter les données contenues dans les serveurs spatiaux. Cependant les problèmes «classiques» de partage des données se posent : accès aux bonnes données, sécurité des accès, mise à jour, De ce fait les SGBD ont été (ou vont être) dotés d interface de gestion de l exploitation des données géographiques via la gestion d espaces de travail et de gestion des versions. Par ailleurs, il semble intéressant de faire un bilan concernant les connexions entre les SIG et les serveurs spatiaux. «Accès libre aux données de référence», «géoservices», «web mapping» deviennent des expressions communes dans le domaine de la géomatique. Le partage de données au niveau mondial fait appel à l ensemble des standards de structuration et d accès aux données présentés dans ce document. Les serveurs spatiaux font partie intégrante de ces environnements multi-utilisateurs. Cependant comment va s organiser l architecture des systèmes d information basés sur ces technologies? Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 70

3.1 Concept d espace de travail et de gestion des versions Un espace de travail correspond à un environnement virtuel accessible par un ou plusieurs utilisateurs pouvant effectuer des mises à jour et des consultations. Dans le monde des SIG, AM/FM ou des CAD, les transactions sont souvent longues (de quelques secondes à plusieurs journées). Les SGBD actuels ont été développés pour gérer des transactions de courte durée comme dans le domaine de la finance par exemple. Dans un environnement multiutilisateur, un moyen pour permettre d avoir un ensemble de données valide est de faire appel à la création d espace de travail. Ceci se traduit au niveau des serveurs spatiaux par la mise en place de modules permettant de faciliter la gestion de ces espaces. Actuellement la version 9 d Oracle propose en production 24 un module Oracle Workspace Manager (OWM), permettant la création d espace de travail. Un second exemple est ArcSDE qui assure la gestion des versions au sein des SGBD auquel il se connecte. 3.1.1Princ ipes a.organisation des espaces de travail pour la gestion des données L objectif de OWM est de permettre le stockage de différentes versions d un même ensemble de données dans une même base de données. Ce principe est appelé «versionning» en anglais, traduit par gestion des versions. Les atouts du principe de gestion des versions sont : favoriser les accès concurrents aux données permettre les transactions longues. L unité de base de la gestion des versions est la table. En effet, OWM permet d autoriser la gestion des versions pour une table. C est-à-dire que chaque ligne de cette table pourra posséder différentes versions. Lorsqu un espace de travail est créé, il dépend d un parent appelé LIVE. L espace de travail LIVE est l espace de travail originel qui peut être mis à jour à partir d un de ses enfants. Espace de travail "LIVE" Espace de travail 1 Espace de travail 4 Espace de travail 2 Espace de travail 3 Espace de travail 5 Figure 51: Hiérarchie des espaces de travail 24 OWM existe en béta pour la release 3 d Oracle 8i Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 71

Ainsi peut être défini un grand nombre d espaces de travail descendant tous de l espace LIVE. Ensuite, il est possible de générer des points de sauvegarde (savepoints) qui permettront des retours en arrière si nécessaire. Ils permettent de prévenir les données de tous dommages réalisés «derrière le mur» (ie. Ensemble des opérations réalisées après le point de sauvegarde). SPa SPd Espace de travail "LIVE" SPb SPc Espace de travail 1 Espace de travail 4 SPe SP1 Espace de travail 2 Espace de travail 3 Espace de travail 5 SP2 SP3 Figure 52: Point de sauvegarde au sein des espaces de travail Des points de sauvegardes sont créés de manière implicite à chaque création d espace de travail. Par exemple sur le schéma ci-dessus, les points de sauvegarde SPa et SPd correspondent à la création des espaces de travail 1 et 4 ; les points de sauvegarde SPb et SPc correspondent à la création des espaces de travail 2 et 3 ; le point de sauvegarde SPe correspond à la création de l espace de travail 5. Grâce à ces points de sauvegarde, il est donc possible de faire des retours en arrière. Les retours en arrière ne sont pas possible s il y a des utilisateurs ayant des sessions actives. Il est possible de fusionner deux espaces de travail. Ainsi les changements ayant eu lieu chez les enfants s appliquent au(x) parent(s). Cette mise à jour enfant-parent peut être réalisée de manière automatique ou non. Lors de la fusion d espaces de travail, des conflits peuvent apparaître, il faut alors les résoudre manuellement. Il est également possible de comparer 2 espaces de travail ensemble. Un espace de travail peut être gelé. Cette méthode conduit au blocage de l espace de travail : Il n est plus possible d y accéder. Dans une moindre mesure, il est possible de bloquer un espace de travail. Ceci peut se faire de 2 manières : Blocage exclusif comme pour les transactions courtes : Les lignes en cours de modifications sont accessibles par un seul utilisateur Blocage partagé : Les lignes en cours de modifications sont accessibles par un groupe d utilisateur dans un espace de travail donné. Différents rôles peuvent être attribués pour chaque utilisateur des espaces de travail permettant ainsi la création, la suppression, la fusion, des différents espaces. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 72

b.structures des espaces de travail et notion de version Les tables incluses dans un espace de travail sont dites «version-enabled» c est-àdire capable de stocker différentes versions d un ensemble de données. Pour cela, lorsque cette fonctionnalité est attribuée à une table, la structure de cette dernière est modifiée. Un champ appelé VERSION est ajouté à la table. Il contient le numéro de version des données. Cependant l ensemble des données d une table n est pas stocké pour chaque version. Seules les données ayant subi des modifications le sont. Ainsi les données non modifiées sont stockées dans l espace de travail appelé LIVE. La gestion des versions et la création des espaces de travail permettent aux données contenues dans les serveurs spatiaux d être mises à jour de manière organisée. La gestion des droits des utilisateurs ainsi que des différents états des données permet de tenir à jour un historique des travaux réalisés sur ces données. Cependant, l utilisation des espaces de travail sous Oracle Spatial est en phase de production depuis Oracle 9i (juin 2oo1). Du fait de la jeunesse de ce module, l accès aux données version enabled par les SIG n est pas encore possible de manière aisée. 3.2 Interactions SIG / Serveurs Spatiaux Actuellement la difficulté d établir des échanges entre les serveurs de données spatiales et les SIG rendait la mise en place de tel Système d information délicate. En effet, le choix des SIG capables d établir une connexion vers un SGBD stockant les données spatiales était limité. Par ailleurs, certains SIG ne sont pas capables de se connecter en natif à Oracle Spatial d où un coût supplémentaire parfois très élevé (cas d ArcSDE). Cependant, la tendance actuelle observée auprès des différents éditeurs du marché au cours du salon Géo-événements 2oo1 a montré que les principaux SIG allaient être capables de se connecter aux différents serveurs spatiaux. A ce jour, 4 principaux SIG capables de se connecter à Oracle Spatial modèle objetrelationel ont été recensés : Mapinfo 6 Geomedia 4 Microstation Ispatial Geographic GeoConcept (prévu en septembre) Par ailleurs, en utilisant ArcSDE, l ensemble des SIG et serveurs de cartes ESRI sont capable de se connecter à un serveur spatial de type Oracle, informix ou autre Le tableau cidessous reprend l intégralité des SIG capables d interagir avec Oracle Spatial ainsi que les caractéristiques des échanges. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 73

Tableau 4 : SIG MapInfo 6 Geomédia 4 Bentley Geographic Ispatial Géoconcept 5.0 Bilan des connexions entre les logiciels SIG et Oracle Spatial Modèle Relationnel Modèle Objetrelationnel WKBF (binaire) L E L E L / E Logiciel SIG Commentaire Testé Testé ( ) ( ) Source Bentley Source Géoconcept (Prévu Septembre) Autocad Map ( ) ( ) Source Technet Esri SIG (SDE) SDE) (SDE) Serveur de cartes Source ESRI MapGuide 5 Source Technet & Autodesk ArcIMS (SDE) (SDE) Source Technet & ESRI Jshape (SDE) Source Jshape MapServer v 3.3.011 (SDE) Source Mapserver/Testé à l Australian Oceanographic Data Centre en été 2ooo. Outil de manipulation de données géographiques FME Testé Outil de visualisation de données géographiques Geomatica FreeView ArcExplorer ArcSDE (SDE) Moteur de connexions aux bases de données Testé Source ESRI Source ESRI RQ : L = Lecture / E = Ecriture : Possible Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août (SDE) 2oo1 : Possible avec ArcSDE 74

3.3 Interopérabilité et organisation des échanges de données spatiales Le nombre d applications utilisant des informations géographiques est en constante augmentation dans des disciplines variées. Les jeux de données géographiques sont de plus en plus partagés, échangés et utilisés dans des cadres non prévus lors de leur création. Cette section a pour objectif de montrer les techniques permettant de développer des systèmes d information s inscrivant dans le contexte des nouvelles normes en géomatique. 3.3.1Interopérabilité entre les systèmes D après l OGC Service Architecture, l interopérabilité pour les données géographiques est «la capacité qu à un système d information pour : Échanger librement toutes sortes de données spatiales concernant la Terre et les objets et phénomènes situés à la surface ou sous la surface de la Terre Manipuler et analyser ces données à travers les réseaux.» Cela signifie que 2 systèmes doivent être capables d interagir (ie. d être interopérable) afin d effectuer des tâches c est-à-dire si X peut envoyer une requête «Ri» à Y et Y peut lui répondre «Si» basé sur une compréhension réciproque. Ri X Si Y Figure 53: Interopérabilité 3.3.2De l architecture client-serveur à l architecture multitiers La figure 54 présente le passage d une architecture 2-tiers (ou client-serveur) vers une architecture 3-tiers typique. Pourquoi apparaît cette évolution de l architecture des Systèmes d Information? Le modèle client-serveur reste idéal pour des applications de type infocentre car il permet de répondre rapidement à la haute fréquence de la demande. Cependant il reste limité car extrèmement dépendant du serveur de données. De plus il est peu modulable car l ensemble de la logique d application se trouve sur le poste client. Dans le cadre d utilisation partagée d informations géographiques issues de serveurs spatiaux, une telle architecture rend l évolution du système difficile et l interopérabilité réduite. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 75

Interface / Interrogation Station de travail + outils et fonctions de travail Service d'interface Client Service d'utilisation Traitements Serveur d'applications Service de traitement Source de données Serveur de données Service de données Serveur de données Type d'architecture : Figure 54: 2 tiers 3-tiers logique n-tiers D une architecture 2-tiers à une architecture 3-tiers Le modèle logique (au centre de la figure) présente les différents composants du modèle logique d une architecture n-tiers. Le service d interface permet la gestion de l ensemble des interactions avec les utilisateurs au travers d une interface. Le service de communication représenté par les traits reliant les différents services permet de connecter les différents tiers entre eux. Le service d utilisation permet d activer le service de traitement qui gère les processus. Le service de données constitue la source d information. Il est possible de distinguer 2 types d environnement : un avec «client léger» : dans ce cas le serveur d application est complété par un serveur web et le client est un navigateur web. un autre avec «client lourd» : dans ce cas le client est une station de travail identique à l architecture 2-tiers mais les traitements sont réalisés par le serveur d application L interaction entre les services repose sur le service de communication qui assure la gestion des liaisons. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 76

3.3.3Liaisons entre services a.3 types de liaison L ISO et l OGC ont défini 3 types de liaison entre les services : les liaisons dites transparentes l utilisateur gère les échanges d informations les liaisons dites translucides L utilisateur demande à un service de gestion des flux de gérer les liaisons entre services. L utilisateur reste dépendant de chacun des services invoqués. les liaisons dites opaques L utilisateur demande à un service de gestion des flux de gérer les liaisons entre services. L utilisateur est indépendant vis à vis services invoqués. Ces 3 liaisons sont présentées ci-dessous : 1.Requête 2.Résultats Client 6.Demande le service Catalogue 3.Demande le service 4.Demande le service Service 7.Demande d'informations Service 5.Demande d'informations Service 8.Demande d'informations Figure 55: Liaisons transparentes Dans le cadre des liaisons transparentes, l utilisateur choisit l ordre d appel aux différents services. Pour effectuer son choix, il fait appel à un catalogue de données lui indiquant les données disponibles pour chacun des services ainsi que leurs disponibilités. La communication entre les services est ainsi réduite. La difficulté d un tel service est que l utilisateur doit évaluer la pertinence du croisement d information entre les différents services. Le validité des données affichées coté client est laissée à l utilisateur ; aucun contrôle n est réalisé. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 77

1.Requête 5.Résultats Client 4d.Statut du service service de gestion des flux 2a.Demande le service 2b.Statut du service 3a.Demande le service 3c.Statut du service 4a.Demande le service Service 4b.Demande d'informations Service 3b.Demande d'informations Service 4c.Demande d'informations Figure 56: Liaisons translucides Dans ce cas, un service de gestion des flux (workflow service) assure la gestion des requêtes envoyées aux différents services. Ce service permet de diminuer la charge de travail pour l utilisateur car celui-ci est dépendant des informations disponibles au niveau du service. Quelque soit les demandes utilisateurs, les données affichées auront obligatoirement une valeur cartographique du fait du contrôle effectué par le service de gestion des flux. 1.Requête 8.Résultats Client 2.Demande le service Service Opaque 5.Demande le service Service 4.Demande d'informations Figure 57: 3.Demande le service Service Service 6.Demande d'informations 7.Demande d'informations Liaisons opaques Dans ce cas, un seul service est visible à l utilisateur. Ce type de liaison assure la totalité de la gestion du croisement d information issue des différents services. Ainsi le travail Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 78

fourni par l utilisateur est minime. De plus, les différentes données affichées ont obligatoirement un sens du fait de la présence du service opaque qui joue le rôle de contrôleur. Ces 3 schémas de liaison peuvent être utilisés conjointement pour former des systèmes complexes. La communication entre ces différents services fait appel au niveau technologique à certain type de composant logiciel et matériel propre aux systèmes partagés. b. Communication entre les systèmes d information D un point de vue technologique, il est important de présenter les différents composants logiciels et matériels utilisables dans les systèmes d information basés sur le partage des données. La communication dans un environnement partagé (indépendant des réseaux, des plateformes, des langages et des systèmes d exploitation) repose sur le service de communication. Celui-ci peut être réalisé via l Object Request Broker (ORB) dans un environnement CORBA. Le service de communication assure la propagation des requêtes issues d un objet utilisateur vers un objet coté serveur. Le résultat issu des différents serveurs est ensuite collecté, assemblé puis renvoyé au client. Système A Système B Client Client ORB ORB SA SS SA SS Figure 58: ORB: Object Request Broker SA: Serveur d'applications SS: Serveur spatial : Flux de données Mise en place de systèmes interopérables d un point de vue technologique Le fonctionnement des systèmes présentés figure 58 conduit à deux cas : les deux systèmes utilisent le même protocole ORB ainsi les objets d un système peuvent interagir avec les objets de l autre. les deux systèmes n utilisent pas le même protocole, il est alors nécessaire de faire appel à un intermédiaire de liaison. Grâce à ce type d architecture, la liaison entre les différents services est assurée. Cependant il est nécessaire d avoir des objets de même nature pour réaliser les liaisons. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 79

c.le problème des formats de données : médiateurs (Middle wear) Afin d optimiser l interopérabilité entre les systèmes dans le domaine de la géomatique, l OGC préconise l utilisation du format GML afin de permettre la communication entre les systèmes sans intermédiaire de liaison. Pour cela il est donc nécessaire d utiliser un médiateur effectuant la conversion entre chaque serveur de données (serveur spatiaux ou serveur de carte classique) afin de générer des objets transportables via le réseau. Ainsi une architecture est établie autour des géoservices comme le présente la figure 59Le format GML est utilisé entre les différents acteurs. En fonction de l interface client, un format de rendu graphique peut être utilisé comme par exemple le SVG. Clients Serveur de carte Calques de référence Serveurs GML Serveur de carte (vecteur) Catalogue GML GML Géoservices (Internet / Intranet) GML Serveur de carte (RASTER) SVG GML GML GML Serveur de données rasters Serveur de données vecteurs Médiateur Figure 59: Architecture des géoservices Ce type d architecture permet, de plus, d avoir des données mises à jour par le centre d origine et donc de limiter l apparition de source de données hétérogènes et la multiplication des données. L objectif est ainsi de développer des applications basées sur les standards également appelées SCOTS (Standard Commercial off the shelf). C est dans cette optique que devront être mis en place les prochains systèmes d information afin de développer des géoservices interopérables. L accès aux données devra être régulé avec la mise en place de systèmes de sécurité. Face à l implantation d un nombre croissant de systèmes basés sur les standards, un élan général au sein de la communauté géomatique internationale est demandeur de la mise à disposition libre des données de référence support de la plupart des représentations cartographiques. Par ailleurs pour l accès aux données spécifiques des moyens de paiement (fonction du volume, du temps de connexion et du type de données) seront établis. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 80

3.4 Architecture des Géoservices Le modèle relatif au système d information est fournie par l ISO 19101. Il définit l EOSE (Extended Open Systems Environment / Environnement des systèmes ouverts évolutifs) pour l information géographique. 3.4.1EOSE modèle pour l information géographique Il décrit 6 classes principales de géoservices: Service de présentation de document permettant la visualisation d informations géographiques et la création d interface utilisateurs. o Catalogue de métadonnées o Interface de visualisation cartographique o Interface de gestion de librairie de symbole Service de gestion des données assurant le stockage, la manipulation des métadonnées et des données. o Service d administration de données o Service d achat de données en ligne Service de flux gérant les liaisons entre les composants o Service permettant d exécuter une requête pour un produit Service de calcul assurant les manipulations des données (par exemple les services réalisant les reprojections de données). Ce type de service n assure pas le stockage des données ou le transfert au travers les réseaux. o Reprojection o Traitements Spatiaux o Service de positionnement o Générateur d itinéraires o Géocodage Service de communication participant à la gestion des transfert de données. o Service d encodage o Service de messagerie (visualisation et échange d informations simultanée) Service d administration assurant la gestion des applications, des réseaux mais aussi la gestion des droits utilisateurs (comptes et privilèges). o Gestion des accès o Gestion des licences L objectif de EOSE est d aider à la mise en place des géoservices en procurant une description de services génériques 25. Architecture» 25 Pour un aperçu de l ensemble des géoservices décrit par EOSE se référer à «Open GIS Service Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 81

3.4.2Recherche de données : les catalogues Afin d assurer l accès aux données spatiales contenues dans les multiples Systèmes d Information, des catalogues de métadonnées sont en train de se mettre en place. Ces catalogues peuvent regrouper des données soit de manière thématique (catalogue de données océanographiques) soit de manière géographique (catalogue de données des États-Unis connu sous le nom de spatial data clearing house). Les catalogues de métadonnées permettent de connaître la localisation des données ainsi que leur description. Des modèles de métadonnées de référence assurent le stockage du même type d information. L annexe 16 présente le modèle d un service de consultation de métadonnées selon l OGC. Ces services permettent la localisation des services distributeurs ainsi que les données contenues pour chacun. La mise en place de tels services suppose également la création d un vocabulaire de référence utilisé pour décrire les différentes propriétés des données et des services de distribution. Ceci nécessite une coordination entre les différents producteurs et distributeurs de données. 3.4.3Web mapping Testbed : exemple d applications basées sur les standards (SCOTS) en environnement Internet Le Web Mapping Testbed (WMT) a démarré au cours de l année 2000. WMT consiste en la réalisation d un serveur de cartes basé sur les standards capables de regrouper des données issues de sources différentes. Ainsi il est possible de consulter sans limitation l ensemble des données géoréférencées distribuées dans le monde. Des dizaines de serveurs traitent en parallèle des informations dont l utilisateur a besoin et ces informations se superposent sans connaissance du format d origine. Cette initiative lancée par l OGC a été réalisée par plusieurs participants (SICAD, NASA, CubeWerx, ) et consiste en l installation de serveur de données dans des architectures basées sur les standards. L interface d un serveur de cartes dans le cadre de WMT doit être capable de réaliser 3 tâches : Présentation d une carte (GetMap) Description d une entité (GetFeatureInfo) Récupération du catalogue de données de chaque serveur (GetCapabilities). Un serveur de cartes peut être décomposé en 4 éléments assurant le transit de l information du serveur vers le client. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 82

Caractéristiques du client Contraintes de l'image Affichage Image Rendu graphique Client : Léger Moyen Styles Requêtes Générateur d'affichage d'élément (DEG) Filtre Eléments graphiques Entités géographiques (GML) Serveur de données Lourd Figure 60: Décomposition d un serveur de carte et définition des différents types de client L interface peut être bâtie sur 3 types de technologie : rendu RASTER (Gif, Jpeg ou Png) Transit de données RASTER du client vers le serveur (client léger) rendu d élément graphique Transit d éléments graphiques dans un style et dans un SRS prédéfini (client moyen) rendu d entités géographiques Transit d entités géographiques au format GML par exemple nécessitant le rendu graphique coté client (client lourd) La répartition des 4 composants d un serveur de cartes pour ces 3 types d architectures est présentée en annexe 18. La mise en place d un serveur spatial dans le cadre du WMT nécessite : d être référencé dans un service de catalogue de données et d être capable de renseigner ce catalogue d être capable de répondre aux requêtes émises par l utilisateur dans un format standard grâce à un médiateur. Le Web Mapping Testbed permet le développement des activités SIG traditionnelles impliquant des processus interopérables ou l accès à des données provenant de sources multiples. Il a été mis en place pour différents projets en utilisant les différents types de liaison vus dans la section 3.3.3 (Opaque, translucide, transparente) par SICAD, IONIC. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 83

3.5 Réalisations Cette section présente différentes applications mises en place dans divers types d environnement. Le point commun est l exploitation de données géographiques issues d Oracle Spatial. 3.5.1SDO Viewer : Module de visualisation de données au format Oracle Spatial dans une architecture client-serveur SDO Viewer est une application permettant de combiner des données issues de multiples serveurs de données Oracle Spatial. Il a été développé en C++ avec les composants logiciels Ilog Views dans un environnement Unix. L objectif sous-jacent de cette application était la formation au composant Ilog afin de réaliser par la suite la migration de l application GIB (fonctionnant également avec les composants Ilog Views) pour l exploitation de données issues du module Spatial d Oracle. a.présentation de l interface L interface permet d accéder aux fonctions cartographiques de bases (Zoom, Pan). Ensuite il est possible de définir une zone d intérêt permettant de récupérer seulement les données relatives à cette zone. Une fenêtre de localisation interactive a également été créée. Ensuite sont gérés les connexions avec les différents serveurs spatiaux. L arbre supérieur gauche représente le catalogue de l ensemble des calques des serveurs spatiaux connectés ; il est ainsi possible de se connecter à plusieurs serveurs simultanément. L arbre inférieur représente la superposition des calques. Un certain nombre de propriétés est accessible pour chaque calque (modification de sa position dans l arbre, modification des couleurs ). L aspect projection n est pas géré dans la version actuelle cependant 2 solutions permettraient de superposer des données qui ne seraient pas dans le même système de projection : réaliser la reprojection au niveau du serveur de données avant le transfert vers le client réaliser la reprojection au niveau client grâce au composant Ilog Views Map. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 84

Fonction SIG (zoom / Pan) Liste des connexions actives et bouton de connexion Zone de visualisation des données Catalogue de données pour l ensemble des serveurs spatiaux connectés Superposition des calques et gestion de leurs propriétées Fenêtre de localisation interactive Figure 61: Interface de SDOViewer Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 85

b.architecture du système Le système de SDO viewer repose donc sur une architecture de type client-serveur où l ensemble de la logique d application réside coté client. Cependant si la gestion des projections était assurée coté serveur, ceci impliquerait une délocalisation d une partie des fonctions d applications ; ces fonctions pouvant alors être utilisées par d autres applications. Serveurs (Internet / Intranet) Clients SDOviewer IP Serveur Oracle Spatial Nom d'hote IP Serveur Oracle Spatial Figure 62: Serveur Oracle Spatial Nom d'hote IP Clients SDOviewer Architecture du système Client-Serveur de SDOviewer SDOViewer nécessite l installation d un simple client Oracle 8.0.5 minimum afin de pouvoir accéder aux données contenues dans une base de données se conformant au modèle objet-relationnel. Il peut se connecter à des serveurs Oracle aussi bien en réseau Intranet (résolution des noms selon le nom d hôte) que sur un réseau Internet (résolution des noms selon l adresse IP). Les principales améliorations à apporter sont la gestion des projections (en utilisant une des deux solutions exposées précédemment), la récupération des attributs d un élément sélectionné, le chargement progressif des données en fonction de la zone visible à l écran (fonction appelée «load on demand») et éventuellement la visualisation de données RASTER géoréférencées contenues dans Oracle comme l a présentée la section 1.3. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 86

3.5.2SVGib : Mise en place d un système de consultation d un catalogue basé sur une architecture multi-tiers L interface de SVGib a été présentée dans la section 1 et les différentes requêtes spatiales réalisables dans la section 2. Cette partie s attarde sur l architecture du système de SVGib. Cette application ne se conforme pas à l ensemble des règles présentées dans cette dernière partie du mémoire. Cependant lors de la conception de SVGib, l objectif était l évaluation d un certain nombre de nouvelles technologies d échanges de données associées à un serveur spatial Oracle Spatial dans une architecture multi-tiers. Le service de présentation de document correspond donc à l interface cartographique basée sur le SVG. Celle-ci repose sur les technologies HTML pour la conception de la page, PHP pour les parties dynamiques de la page faisant appel à un contenu issu de la base de données et au Javascript pour l ensemble des processus d interactions (manipulation des objets SVG, manipulation des formulaires HTML). A l opposé, le service de gestion de données est donc constitué d une base de données Oracle utilisant le module Spatial pour le stockage des données géographiques et le module Intermedia pour le stockage de l ensemble des données RASTER. Le service de calcul est constitué d un médiateur réalisant la conversion des données du format Oracle Spatial en SVG. Ce médiateur nommé sdo2xml a été développé en C++. Le service de flux, permettant la réalisation de requêtes, est assuré par l utilisation de PHP permettant d interroger la base de données GIB. Enfin, le service de communication assurant le transfert des données est assuré par le réseau Internet et le serveur web (Apache) qui permet également la gestion des accès et constitue donc le service d administration. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 87

OCI/SQL Serveur Oracle Module Intermedia Données RASTER Module spatial Données géographiques Serveur de données Serveur d'applications sdo2xml Médiateur C++ Figure 63: Serveur Web PHP Fichier SVG Architecture de SVGib Clients Carte SVG Formulaire HTML Javascript : - Gestion de l'affichage - Interactions curseur - Interrogation du SVG Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 88

L architecture présente donc les différents services, chacun d eux pouvant être réutilisé en partie par d autres services. Le principal objectif de SVGib est donc l évaluation de la mise en place d une application Internet basée sur Oracle Spatial et les derniers standards d échanges de données géographiques. La génération d un fichier SVG via un médiateur (sdo2xml) permet le rendu graphique de données vectorielles sur Internet. Ainsi, il est possible de créer des interfaces «client moyen» d une très grande qualité graphique. De plus l interaction avec le serveur spatial «Oracle Spatial» permet à cette interface une interrogation des données géographiques comme le ferait un SIG ou un serveur de cartes. Ainsi a été montrée la possibilité de s affranchir du logiciel SIG tout en créant une interface d interrogation et de recherche puissante basée sur un ensemble de données géographiques. Le coût logiciel d une telle application peut ainsi être réduit par rapport à la mise en place d un serveur de carte classique jusqu alors utilisé. L utilisation de technologies tel que le XML (SVG et GML) pour le rendu graphique et les échanges de données, et du PHP pour l interrogation des données permet d obtenir des interfaces de qualité capable d inter agir avec d autres serveurs et applications. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 89

Différents aspects doivent être étudiés lors de l implémentation d un serveur spatial au sein d un système d information. En effet selon que le système est un système de consultation de données ou de production ou les deux, la mise en place de module de gestion de version des données doit être utilisé. Ainsi l intégrité des données lors des transactions souvent longues est assurée. Par ailleurs, l implication d un serveur spatial dans le contexte d un réseau d entreprises ou d un réseau Internet implique la mise en place d architecture spécifique selon le type d application développée. En effet, l engouement général pour les applications Internet fait que l architecture client-serveur traditionnel est abandonnée au profit d architecture multi-tiers. Ce type d architecture conduit à la séparation des différents niveaux logiques du système en autant d objet. Ainsi apparaissent les serveurs de données, les serveurs d application et les clients. Les nombreux formats dans le domaine du SIG a conduit au développement de Géoservices reposant sur des médiateurs convertissant les données géographiques en un format de référence le GML. La communication entre les différents géoservices est ainsi facilitée. Malgré tout, la mise en place de tels services n en est qu à ses débuts. Cependant, un nombre croissant de SIG permet d exploiter les données géographiques contenues dans les serveurs spatiaux. L intégrité et le partage des données sont de ce fait mieux organisés. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 90

Le présent document a permis de voir les différentes étapes de la mise en place d un serveur spatial au sein d un Système d Information de la structure des données à l architecture du système opérant final. Il repose sur l ensemble des travaux réalisés au cours de ces 6 mois à la Générale d Infographie. Le déroulement de stage a suivi celui de ce mémoire. Tout d abord les différents modèles de stockage des données géographiques sous serveur spatial ont été étudiés ; du modèle relationnel apparu il y a une dizaine d années au modèle objet-relationnel. L analyse de ces différents modèles a permis de réaliser l intégration de données à partir de différents formats vers le modèle objet-relationnel le plus utilisé aujourd hui. Ensuite l acquisition de l ensemble des opérateurs spatiaux et le paramétrage des index spatiaux ont conduit à la mise en place de ces fonctions d analyse et d interrogation des données géographiques au sein de différentes applications cartographiques dans différentes architectures. L établissement de ces architectures a permis de tester les capacités d un serveur spatial à jouer son rôle de partage de données dans des contextes variés. Ainsi les réalisations ont montré la possibilité d orienter les systèmes cartographiques vers des systèmes plus ouverts en se basant sur les standards géomatiques. D un point de vue des structures des données, le modèle objet-relationnel tend à s imposer pour le stockage des données géographiques sous serveur spatial. Un serveur spatial étant, par définition, un élément de partage de données, l échange des données doit être organisé. Pour cela le TC211 de l ISO, le SQL/MM et l OGC travaillent sur la mise en place des standards des modèles de stockages, l interrogation de données et les échanges de données. D un point de vue des applications, l étude réalisée établit que globalement l ensemble des acteurs SIG du marché et des SGBD s oriente vers des serveurs spatiaux basés sur Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 91

le modèle objet-relationnel. Le SIG devient l outil d étude des données géographiques et sa tâche de gestionnaire de fichiers remplie, plus ou moins avec succès selon les produits, tend à disparaître avec l apparition des serveurs de données géographiques. De plus, l architecture hybride basée sur un SIG pour les données géographiques et une base de données pour les données sémantiques aura tendance à être remplacée par l installation de serveurs spatiaux dans les années à venir. Par ailleurs, les fortes capacités d analyse des données sous serveur spatial permettent de développer des applications dotées de fonctions similaires au SIG en utilisant seulement la norme SQL3/MM. D un point de vue système, une modification des architectures dans le domaine de la géomatique s observe. En effet avec l ouverture des réseaux, l architecture client-serveur traditionnelle est de plus en plus souvent remplacée par une architecture multi-tiers. Cette évolution entraîne une séparation des différents niveaux logiques des systèmes. Ainsi le système est décomposé en différents services (Données, Administration, Calcul, Communication, Flux, Visualisation, ), chacun d eux participant à la réalisation du Géoservice. Par ailleurs l environnement Internet conduit à l apparition de systèmes interopérables. Ici intervient l ensemble des standards d échanges de données basés sur le XML (GML & SVG). Les organes de liaisons et médiateurs deviennent les pièces maîtresses de ces systèmes. Au niveau des métiers, les cahiers des charges de projet SIG seront de plus en plus demandeur du respect de ces standards internationaux. En effet, de plus en plus les systèmes devront être conformes aux standards afin d assurer la portabilité des données et des applications dans des systèmes de plus en plus ouverts où de multiples serveurs spatiaux vont communiquer entre eux. Ainsi pourront être développés des systèmes évolutifs capables de s insérer dans la dynamique du monde de la géomatique. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 92

Les serveurs spatiaux vont donc être de plus en plus implémentés dans les systèmes d information géomatiques. Alliant de fortes capacités de stockages et de puissantes fonctions d analyse, ils permettront ainsi d assurer l intégrité des données géographiques via la gestion des accès, des versions et des espaces de travail. Le partage des données sera facilement mis en place pour des applications aussi bien Intranet qu Internet. La liaison entre données sémantiques et géographiques permet d en faire un outil d analyse puissant. Il possède donc à la fois les propriétés d un serveur de données et les propriétés d un outil d aide à la décision. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 93

Abréviations : AM/FM : Automated Map / Facilities Managment BLOB : Binary Large Object CAD : Computer Aide Design DEG : Display Element Generator DIMAP : Digital Image MaP DOM : Document Object Model EOSE : Extended Open Systems Environment ESRI : Environmental Systems Research Institut FME : Feature Manipulating Engine GML : Geographic Markup Language HTML : Hypertext Markup Language LLC : Lower Left Corner LOB : Large Object MB : Mégabyte MBR : Minimum Bounding Rectangle OGC : Open GIS Consoritum OGIS : OpenGIS consortium OGS : Open GIS Consortium ORB : Object Request Brocker OWM : Oracle Workspace Manager PAC : Politique Agricole Commune QTF : Index de type Quad-Tree Fixe QTH : Index de type Quad-Tree Hybrid RTR : Index de type R-Tree SCOTS : Standard Commercial off The Shelf SDE : Spatial Database Engine SDO : Spatial Data Object SGBDOO : Système de Gestion de Base de Données Orienté Objet SGBDOR : Système de Gestion de Base de Données Objet-Relationnel SGBDR : Système de Gestion de Base de Données Relationnel SGF : Système de Gestion de Fichier SIG : Système d Information Géographique SQL : Structured Query Language SQL3/MM : Nouvelle norme SQL multimédia SRS : Système à Référence Spatiale SVG : Scalable Vector Graphics SVGib : SVGeographic Information Browser UML : Unified Modeling Language URC : Upper Right Corner WKBF : Well Known Binary Format WMF : Web Mapping Features WMS : Web Mapping Server WMT : Web Mapping Testbed WVS : World Vector Shoreline XML : extensible Markup Language Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 94

Références Bibliographiques : - Bédard Yvan, 2001, Fundamentals of Spatial Data Warehousing for Geographic Knowledge Discovery, Laval, Centre for research in geomatics, Laval University, Août 2001, 50 pages - Chatelier Bertrand. Page consultée en juin 2001, Formalisation du changement des relations spatiales dans un processu multi-échelle, [en ligne], URI : www-l3i.univlr.fr/l3i/equipe/ezahzah/bchatel/rapport.htm - Dessard Vincent, 2001, Le point sur les standadrs ISO /OGC de web mapping, Géoévénement 2001, Avril 2001, 30 pages - Engelen Marc, 2001, SICAD GEOMATICS au sein de l OpenGIS Consortium, Géoévénement 2001, Avril 2001, 5 pages - GIS Belgium / Luxembourg. Page consultée en mai 2001, les SIG répartis ou distribués, [en ligne], URI : www.gis-belgium.be/sigreparti.htm - Godfrind Albert, 2000, Oracle Spatial Training, 27 decembre 2000, Oracle Corporation Data Server Division Sophia Antipolis France, 400 pages. - Godfrind Albert, 2001, Base de données relationnelles et information géographique : normes et évolution, Géoévénement 2001, Avril 2001, 1 pages - Hebert Jeff, Logan Anna, Marray Chuck, 2000, Oracle Spatial User s Guide and Reference Release 8.1.7, Septembre 2000, Oracle Corporation, 464 pages. - LAP. (page consultée en mai 2001, Les architectures multi-tier, [en ligne], URI : www.lap.fr/archi3tiers.htm - Open GIS Consortium, 1999, OpenGIS Simple Features Specification For SQL Revision 1.1, 5 mai 1999, Open GIS Consortium, 78 pages. - Open GIS Consortium, 2000, OpenGIS Web Map Server Interface Implementation Specification Revision 1.0.0, 19 avril 2001, Open GIS Consortium, 38 pages. - Open GIS Consortium, 2001, Geographic Markup Language 2.0 Specification, 20 février 2001, Open GIS Consortium, 70 pages. - Open GIS Consortium, 2001, OpenGIS Service Architecture, 29 janvier 2001, Open GIS Consortium, 63 pages. - Oracle Corporation, Mai 2000, Oracle Spatial 8.1.6 Performance-Related Characteristics, Oracle Corporation, 54 pages. - Oracle Corporation, Mars 2000, R-tree Indexing User s Guide, Oracle Corporation, 8 pages. - Prallong Alain, 2001, Serveur spatial / serveur de données : points commun et différences, Géoévénement 2001, Avril 2001, 6 pages - Prunayre François-Xavier, 2001, Bilan des interactions entre SIG et Oracle Spatial, Le Pecq, Générale d Infographie, Juin 2001, 45 pages - Prunayre François-Xavier, 2001, Migration des bases de données GIB et APRRIES2, Le Pecq, Générale d Infographie, Juin 2001, 30 pages - Prunayre François-Xavier, 2001, Oracle Spatial 8i :Installation, Intégration et migration de données, Indexation spatiale,, Le Pecq, Générale d Infographie, Juin 2001, 77 pages - Prunayre François-Xavier, 2001, SVGib : Interface internet réalisé dans le but de tester les différents opérateurs spatiaux d Oracle spatial et les qualités du SVG pour le rendu graphique de données vectorielles, Le Pecq, Générale d Infographie, Juillet 2001, 50 pages - Publication Normes en géomatique. Page consultée en mai 2001, Normes en Géomatiques, [en ligne], URI : www.cgdi.gc.ca/publications/reports/standarads/pub_report_f.htm - W3C, 2000, Scalable Vector Graphics 1.0 Specification, 2 novembre 2000, W3C, 650 pages. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 95

Bibliographie : - Deborde Pascal, 2001, Un serveur spatial pour une gestion du patrimoine, Géoévénement 2001, Avril 2001, 6 pages - Hebert Jeff, Logan Anna, Marray Chuck, Oracle Spatial User s Guide and Reference Release 8.1.6, Decembre 1999, Oracle Corporation 322 pages. - Kennedy Mark, Installation Guide Enterprise Edition Release 3 (8.1.7) for Windows NT, novembre 2000, Oracle Corporation, 244 pages - Mastère SILAT, Avril 2001, Le GéoEvennement 2001, Actes des conférences - Oracle Corporation, 12 objectifs à approcher pour implanter un système répartie, Avril 2000, Oracle Corporation, 38 pages. - Oracle Corporation, Java Library User s Guide, Avril 2000, Oracle Corporation, 36 pages. - Oracle Corporation, Oracle GeoImage, Avril 2000, Oracle Corporation, 10 pages. - Oracle Corporation, Oracle Spatial 9, Mai 2001, Oracle Corporation, 40 pages.oracle Corporation, Coordinate Systems User s Guide, Avril 2000, Oracle Corporation, 38 pages. - Oracle Corporation, Oracle Spatial Data Sheet, Mach 2000, Oracle Corporation, 7 pages. - Oracle Corporation, Oracle Spatial Linear Referencing System (LRS), An Oracle Technical Whitepaper, Mars 2000, Oracle Corporation, 10 pages. - Oracle Corporation, Oracle Spatial Linear Referencing System (LRS) User s Guide, Avril 2000, Oracle Corporation, 82 pages. - Oracle Corporation, Oracle Spatial: Experiences with Extensible Databases, Mars 2000, Oracle Corporation, 29 pages. - Oracle Corporation, Read-Only Replication of Tables Containing Objects, Mai 2000, Oracle Corporation, 9 pages. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 96

Table des annexes : Annexe 1 : Méthodes d accès aux entités géographiques...98 Annexe 2 : Structure de la table des SRS...99 Annexe 3 : Modèle de donnée pour le well-know-binary-format...100 Annexe 4 : Exemple de géométries supportées ou non par le modèle objet-relationnel...101 Annexe 5 : Formats vectoriels pour Internet...102 Annexe 6 : Export d images géoréférencées...103 Annexe 7 : Création d un schéma d application...104 Annexe 8 : DOM d une page web classique...105 Annexe 9 : DOM de SVGib...106 Annexe 10 : Problème de l alpha pour la migration de GIB...107 Annexe 11 : Gestion des Ellipses au cours de la migration de GIB...108 Annexe 12 : Gestion des Polygones au cours de la migration de GIB...109 Annexe 13 : Formats supportés par FME...111 Annexe 14 : Matrices de références des différents opérateurs spatiaux...112 Annexe 15 : Opérateurs spatiaux...114 Annexe 16 : Diagramme UML pour un catalogue de métadonnées...116 Annexe 17 : Les 3 types de WMT...117 Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 97

Annexe 1 : Méthodes d accès aux entités géographiques. Les méthodes suivantes ont été implémentées au sein des serveurs spatiaux : Dimension () : retourne la dimension de la géométrie Geometry Type () : retourne le nom du type de géométrie SRID () : retourne l identifiant du SRS Envelope () : retourne le rectangle englobant (abrégé MBR) AsText () : exporte la géométrie dans un format texte de référence AsBinary () : exporte la géométrie dans un format binaire de référence IsEmpty () : renvoie VRAI si la géométrie est vide IsSimple () : renvoie VRAI si la géométrie est simple (pas d auto intersection, ou de tangence par exemple Boundary () : renvoie la frontière de la géométrie Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 98

Annexe 2 : Structure de la table des SRS Sous Oracle Spatial, les différents Systèmes de Référence Spatiaux sont placés dans la table MDSYS.CS_SRS. Quelque soit le modèle de donnée utilisé, la structure de la table des SRS est la suivante : Figure 64: Structure de la table CS_SRS Ci-dessous est présenté la description du système de projection Lambert III sud dans la table CS_SRS d Oracle Spatial : CS_NAME French Lambert III Sud SRID 41017 AUTH_SRID 41017 AUTH_NAME Oracle WKTEXT PROJCS ["French Lambert III Sud", GEOGCS [ "NTF (Paris meridian)", DATUM ["NTF (P aris meridian)", SPHEROID ["Clarke 1880 (IGN)", 6378249.200000, 293.466021]], PR IMEM [ "", 0.000649 ], UNIT ["Decimal Degree", 0.01745329251994330]], PROJECTION ["Lambert Conformal Conic"], PARAMETER ["Standard_Parallel_1", 43.199291], PARA METER ["Standard_Parallel_2", 44.996094], PARAMETER ["Latitude_Of_Origin", 44.10 0000], PARAMETER ["False_Easting", 600000.000000], PARAMETER ["False_Northing", 200000.000000], UNIT ["Meter", 1.000000000000]] Figure 65: Description du Lambert III Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 99

Annexe 3 : Modèle de donnée pour le well-knowbinary-format Figure 66: (Source : OpenGIS Simple Featurres Specification For SQL Revision 1.1) Modèle pour le stockage des tables selon SQL92 (Type binaire) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 100

Annexe 4 : Exemple de géométries supportées ou non par le modèle objet-relationnel Figure 67: (1) (2) (3) Exemple de polygones La figure ci-contre présente quelques exemples de polygones avec 1, 2 et 3 anneaux. Sous Oracle Spatial, l anneau externe est distingué de l anneau interne grâce à l orientation des coordonnées. Ceux de l anneau externe sont placés dans le sens inverse des aiguilles d une montre alors que ceux de l anneau interne sont dans le sens contraire. (1) (2) (3) (4) Les polygones (1) et (4) peuvent être représentés avec deux polygones mais (2) et (3) ne satisfont pas les règles de l OGC Geometry Model. Figure 68: Exemple de polygone violant les règles de l OGS Geometry Model. (1) (2) (3) (1) (2) (3) Figure 69: Exemple de multipolygone Figure 70: Exemple de géométrie non représentable comme une seule instance d un multipolygone Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 101

Annexe 5 : Formats vectoriels pour Internet Format Module de visualisation Propagation Niveau d interactivité* Format interne Raster navigateur très forte 0 - SVF plugin désuet 1 binaire DWF plugin /applet très rare 2 binaire Flash plugin forte 3 binaire PDF plugin forte 1 binaire + ascii SVG plugin rare (nouveau) 4 ascii VRML plugin rare 4 ascii PGML ² ² 3 ascii WebCGM ² ² 2 binaire HGML ² ² 1 ascii DrawML ² ² 0 binaire VML navigateur forte³ 1 ascii Java2D applet rare (nouveau) 4 binaire ActiveX browser forte³ 4 binaire ²) format en développement ³) uniquement sous MSIE4.0+ * 0: Affichage simple 1: Zoom, couches, liens sur objets 2: Scripts externes interagissent avec le graphisme 3: Animation 4: Contrôle externe sur les objets et les animations Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 102

Annexe 6 : Export d images géoréférencées Fichiers générés à partir de la tuile sélectionnée à partir des métadonnées images.!table!version 300!charset WindowsLatin1 Definition Table File "15.jpg" Type "RASTER" (36.00000,18.00000) (0,0) Label "pt1", (36.00000,-18.00000) (0,1002) Label "pt2", (108.00000,18.00000) (2004,0) Label "pt3" CoordSys Earth Projection 1, 0 Units "degree" Format XML Format Mapinfo TAB Ci-dessous 3 tuiles géoréférencées visualisées dans Mapinfo. Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 103

Annexe 7 : Création d un schéma d application Création d un nouveau type d entité : <complextype name= montyped Entité > <complexcontent> <extension base= gml:abstractfeaturetype > <sequence> <! Insertion des éléments de l entité --> </sequence> </extension> </complexcontent> </completype> Une entité compléte le type AbstractFeatureType du GML. Création d un nouveau type géométrique : <complextype name= montypegéométrique > <complexcontent> <extension base= gml:abstractgeometrytype > <sequence> <! Insertion des éléments de l entité --> </sequence> </extension> </complexcontent> </completype> Création d une nouvelle propriété : <complextype name= mapropriétédegéométrie > <complexcontent> <restriction base= gml:abstractpropertytype > <sequence minoccurs= 1 > <element ref= foo:montypegéométrique /> </sequence> <attributegroup ref= gml:associationattributegroup /> </restriction> </complexcontent> </completype> Foo est l espace de nom utilisateur. Déclaration d un espace de nom dans un schéma d application : Il est nécessaire de déclarer l espace de nom utilisateur afin que chaque élément utilisé dans le schéma soit présent dans l espace de nom. Celui-ci est appelé dans le schéma en attribut de la balise schéma <schema targetnamespace=»http://www.enitab.fr/foo» xmlns=»http://www.w3.org/2000/10/xmlschema» xmlns :gml=»http://www.opengis.org/gml» xmlns :foo=»http://www.enitab.fr/foo»> </schema> Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 104

Annexe 8 : DOM d une page web classique (source : La cartographie en mode vectoriel sur le Web en XML les possibilités de SVG Andé Winter, Andréas Nueman) Figure 71: Exemple de Modèle d'objet de Document (DOM) d une page web simple Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 105

Annexe 9 : DOM de SVGib Page SVGib.php Coord.svg Localisation du curseur en TbAff Tableau de gestion de l'affichage des calques bloc_recherche Contient l'ensemble des panneau de recherche bloc_info Contient les liens vers l'organisation de SVGib Coords Ensemble des éléments DESCWcheck bloc_vue coordx DESCW_nodatacheck bloc_pays coordy background1 mask GIBloc.svg Localisation background2 pays bloc_buffer Background eathloc.png rectloc Rectangle de localisation maskbuf x GibMap.svgz Carte y r background2 earth.jpg bloc_ville background1 world.gif maskville DESCW_nodata nomville DESCW Villes Curseur Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 106

Annexe 10 : Problème de l alpha pour la migration de GIB -- Problème du type Alpha -> on attribue des types en fonction du nb de coord. DECLARE geometry_val mdsys.sdo_geometry; gid NUMBER; NB_COORD NUMBER := 0; -- Récupération des identifiants CURSOR curseur IS Select LOI_ID from LOI where AREA_TYPE = 'alpha'; BEGIN -- Ouverture du curseur puis boucle sur les identifiants OPEN curseur; LOOP FETCH curseur INTO gid; Select count(*) into NB_COORD from COORD_LOI where LOI_ID = gid; If NB_COORD = 1 then Update LOI set SHAPE_TYPE = 'Point' where LOI_ID = gid; Elsif NB_COORD = 2 then Update LOI set SHAPE_TYPE = 'Ellipse' where LOI_ID = gid; Else Update LOI set SHAPE_TYPE = 'Rectangle' where LOI_ID = gid; End if; Commit; EXIT when curseur%notfound; END LOOP; CLOSE curseur; END; / Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 107

Annexe 11 : Gestion des Ellipses au cours de la migration de GIB -- Cercle -- Dans le cas des cercles et ellipses on stocke les coordonnées du MBR (comme Ilog) Update LOI loi set (loi.shape.sdo_gtype) = (2003) where loi.shape_type = 'Ellipse'; Update LOI loi set (loi.shape.sdo_elem_info) = MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3) where loi.shape_type = 'Ellipse'; Update LOI loi set (loi.shape.sdo_ordinates) = MDSYS.SDO_ORDINATE_ARRAY( (Select min(lc.coord_lon) from COORD_LOI lc, LOI lo where lc.loi_id = lo.loi_id and lc.loi_id = LOI.LOI_ID), (Select min(lc.coord_lat) from COORD_LOI lc, LOI lo WHERE lc.loi_id = lo.loi_id and lc.loi_id = LOI.LOI_ID), (Select max(lc.coord_lon) from COORD_LOI lc, LOI lo where lc.loi_id = lo.loi_id and lc.loi_id = LOI.LOI_ID), (Select max(lc.coord_lat) from COORD_LOI lc, LOI lo WHERE lc.loi_id = lo.loi_id and lc.loi_id = LOI.LOI_ID)) where loi.shape_type = 'Ellipse'; Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 108

Annexe 12 : Gestion des Polygones au cours de la migration de GIB La fonction permettant l insertion des coordonnées dans un VARRAY est présentée ci-dessous : -- Fonction permettant l'insertion d'un point x, y dans un varray SDO_ORDINATES CREATE or REPLACE FUNCTION Insert_coord(geom mdsys.sdo_geometry, x number, y number, Deb number) -- Geom objet géométrie -- x et y les coordonnées -- deb variable permettant de savoir si on veut insérer les premiers coordonnées du varray ou pas RETURN mdsys.sdo_geometry IS Geom_copy mdsys.sdo_geometry := geom; ordinate_count integer; i integer := 1; j integer := 1; BEGIN -- calcul de la taille du varray ordinate_count := geom_copy.sdo_ordinates.count; if (Deb <> 1) then -- Agrandissement du varray avant l'insertion geom_copy.sdo_ordinates.extend(2); -- dbms_output.put_line( 'Extending ordinates object'); ordinate_count := geom_copy.sdo_ordinates.count; i := ordinate_count - 1; j := ordinate_count; else i := 1; j := 2; end if; -- Insertion geom_copy.sdo_ordinates(i) := x; geom_copy.sdo_ordinates(j) := y; RETURN geom_copy; END; / La procédure permettant de récupérer les coordonnées de chaque géométrie est présentée ci-dessous. Elle fait appel à la procédure précédente qui réalise l insertion des coordonnées dans l élément SDO_ORDINATES. -- Procédure réalisant une boucle pour l'ensemble des ID create or replace procedure put_ordinates(id number, geom mdsys.sdo_geometry) IS geom_copy mdsys.sdo_geometry := geom;-- Objet geom X NUMBER; Y NUMBER; Deb NUMBER := 1; -- Définition des curseurs CURSOR curseur1 IS Select COORD_lon from COORD_LOI where LOI_ID = id; CURSOR curseur2 IS Select COORD_lat from COORD_LOI where LOI_ID = id; BEGIN -- dbms_output.put_line( 'Insert data for ID : ' id ); OPEN curseur1; Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 109

OPEN curseur2; LOOP FETCH curseur1 INTO X; FETCH curseur2 INTO Y; EXIT when curseur1%notfound; dbms_output.put_line( 'Value X : ' X ', Y : ' Y ); geom_copy := insert_coord (geom_copy, X, Y, Deb); -- MAJ de la geométrie update LOI set SHAPE = geom_copy where LOI_ID = id; Deb := 0; END LOOP; CLOSE curseur1; CLOSE curseur2; END; / Enfin la procédure précédente est appelée pour chaque identifiant distinct. Le programme lui envoie en argument l objet SDO_GEOMETRY et l identifiant. -- GIB_LOI modele objet relonionnel DECLARE Geometry_val mdsys.sdo_geometry; gid NUMBER; -- Récupération des identifiants CURSOR curseur IS Select LOI_ID from LOI where SHAPE_TYPE = 'Polygon' or loi.shape_type = 'Rectangle'; BEGIN OPEN curseur; LOOP FETCH curseur INTO gid; EXIT when curseur%notfound; -- Initialisation et Récupération de l'objet SDO_GEOM Update LOI l set l.shape.sdo_ordinates = MDSYS.SDO_ORDINATE_ARRAY(0,0) where LOI_ID = gid; select SHAPE into geometry_val from LOI where LOI_ID = gid; -- Insertion des coordonnées put_ordinates(gid, geometry_val); commit; END LOOP; CLOSE curseur; END; / Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 110

Annexe 13 : Formats supportés par FME Format FME (option Oracle) en production en haut / en beta en bas (27/08/01). Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 111

Annexe 14 : Matrices de références des différents opérateurs spatiaux. La matrice de référence contient 6 valeurs différentes : p=t dim(x) {0,1,2}, ie. x p=f dim(x) = -1, ie. X= p=* dim(x) {-1,0,1,2} p=0 dim(x) = 0 p=1 dim(x) = 1 p=2 dim(x) = 2 Ainsi ont été définies 5 matrices de référence pour les principaux type de relation topologique (source : OGC Geometry Model) : Disjoint (DISJOINT) : a.disjoint(b) b a = a.relate(b, Touche (TOUCHES) : a.touches(b) (I(b) I(a) = ) (b a) a.relate(b, F ) F * F ** ** F * T ** * * ou T F * ** ** * * ou F* * T ** * Croise (CROSSES) : a.crosses(b) (dim(i(b) I(a)) < max (dim (I(b)), dim (I(a))) (b a a) (b a b) Cas où a P 26, b L 27 ou a P, b A 28 ou a L, b A : a.relate(b, * **T ** a.relate(b, * 0 ** * * ) A l intérieur (WITHIN) : a.within(b) (I(b) I(a) ) (b a = a) a.relate(b, ) T ) * ** ** * F T ) et cas où a L et b L : Chevauchant (OVERLAP) : a.contains(b) (dim (I(a)) = dim (I(b)) = (dim (I(b) I(a))) (b a a) (b a b) Cas où a P, b P ou a A, b A : a.relate(b, T ** * T T * 26 P représente une géométrie de dimension 0 (points ou multi-points) 27 L représente une géométrie de dimension 1 (lignes ou multi-lignes) 28 A représente une géométrie de dimension 2 (polygones et multi-polygones) ) et cas où a L et b L : Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 112

a.relate(b, 1 ** * T T * ) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 113

Annexe 15 : Opérateurs spatiaux DECLARE -- initialisation des variables poly1 MDSYS.SDO_GEOMETRY := NULL; poly2 MDSYS.SDO_GEOMETRY := NULL; union_poly MDSYS.SDO_GEOMETRY := NULL; diminf MDSYS.SDO_GEOMETRY := NULL; BEGIN -- récupération des deux géométries à nir SELECT C.SHAPE INTO poly1 FROM COUNTRIES C WHERE C.NAME = 'FRANCE'; SELECT C.SHAPE INTO poly2 FROM COUNTRIES C WHERE C.NAME = 'ESPANA'; -- Réalisation de l union SELECT SDO_GEOM.SDO_UNION (poly1, m.diminfo, poly2, m.diminfo) INTO union_poly FROM COUNTRIES C_A, COUNTRIES C_B, USER_SDO_GEOM_METADATA M WHERE M.TABLE_NAME = 'COUNTRIES' AND M.COLUMN_NAME = 'SHAPE' AND C_A.NAME = 'FRANCE' AND C_B.NAME = 'ESPANA'; -- Insertion dans une table INSERT INTO UNI VALUES ('union', union_poly); COMMIT; END; Figure 72: Script PL/SQL d union de deux polygones DECLARE -- initialisation des variables union_poly MDSYS.SDO_GEOMETRY := NULL; BEGIN -- Réalisation de l intersection SELECT SDO_GEOM.SDO_INTERSECTION (C.SHAPE, MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3), MDSYS.SDO_ORDINATE_ARRAY(-5,44,2,51)), 0.00005) INTO union_poly FROM COUNTRIES C WHERE C.NAME = 'FRANCE'; -- Insertion dans une table INSERT INTO UNI VALUES ('intersect', union_poly); END; Figure 73: Script PL/SQL d intersection entre deux polygones DECLARE -- initialisation des variables union_poly MDSYS.SDO_GEOMETRY := NULL; BEGIN Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 114

-- Réalisation de XOR SELECT SDO_GEOM.SDO_XOR (C.SHAPE, MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3), MDSYS.SDO_ORDINATE_ARRAY(-5,44,2,51)), 0.00005) INTO union_poly FROM COUNTRIES C WHERE C.NAME = 'FRANCE'; -- Insertion dans une table INSERT INTO UNI VALUES ('xor', union_poly); END; Figure 74: Script PL/SQL XOR (Ou exclusif) entre deux polygones DECLARE -- initialisation des variables union_poly MDSYS.SDO_GEOMETRY := NULL; BEGIN -- Réalisation de la différence SELECT SDO_GEOM.SDO_difference (CH.SHAPE, m.diminfo, C.SHAPE, mh.diminfo) INTO union_poly FROM COUNTRIES C, COUNTRIES_HULL CH, USER_SDO_GEOM_METADATA m, USER_SDO_GEOM_METADATA mh WHERE m.table_name = 'COUNTRIES' AND m.column_name = 'SHAPE' AND mh.table_name = 'COUNTRIES_HULL' AND mh.column_name = 'SHAPE' AND C.NAME = 'FRANCE' AND CH.NAME = 'FRANCE'; -- Insertion dans une table INSERT INTO UNI VALUES ('intersection', union_poly); END; Figure 75: Script PL/SQL de différence entre deux polygones SELECT SDO_GEOM.SDO_CONVEXHULL (c.shape, m.sdo_diminfo) INTO convex_hull_obj FROM COUNTRIES c, MDSYS.SDO_GEOM_METADATA_TABLE m WHERE m.sdo_table_name = 'COUNTRIES' AND m.sdo_column_name = 'SHAPE' AND c.name = name AND c.eurnuts0_i = compteur; Figure 76: Syntaxe pour la création des polygones convexes de Hull (plus petit polygone convexe englobant la géométrie) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 115

Annexe 16 : Diagramme UML pour un catalogue de métadonnées (Source : OGC service architecture) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 116

Annexe 17 : Les 3 types de WMT (source : OGC service Architecture) Mise en place des serveurs spatiaux au sein des systèmes d information - Générale d infographie Août 2oo1 117