• Aucun résultat trouvé

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

N/A
N/A
Protected

Academic year: 2022

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

Copied!
117
0
0

Texte intégral

(1)

Ministère de l’Agriculture et de la Pêche

ÉCOLE NATIONALE d’INGÉNIEURS desTRAVAUX AGRICOLES deBORDEAUX

Mise en place des

serveurs spatiaux au sein des systèmes d’information

Organisation des structures et flux de données sous serveur spatial

François-Xavier Prunayre

(2)

Ministère de l’Agriculture et de la Pêche

ÉCOLE NATIONALE d’INGÉNIEURS desTRAVAUX AGRICOLES deBORDEAUX

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

(3)

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.

Également merci à toute l’équipe de la Générale d’Infographie pour son soutien et son ambiance agréable.

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.

(4)

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 objet- relationnel 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)

(5)

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 objet-

relationnel : 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

(6)

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 intersections 55 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

(7)

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

(8)

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

(9)

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

(10)

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

(11)

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 Spatial1 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.

(12)

1. S TRUCTURE DE STOCKAGE DES INFORMATIONS GÉOGRAPHIQUES SOUS SERVEUR

SPATIAL

(13)

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.

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

ISO SQL/MM Langage commun

Fonctions spatiales communes Organe d'archivage dictionnaire API (OGDI)

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 vecteurs2 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.

2 Les formats de stockage non conforme aux normes OpenGIS tel que celui de Sybase ne seront pas présentés.

(14)

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.

(15)

Source :(OpenGIS Simple Features Specification For SQL Revision 1.1)

Figure 2: 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 objet- relationnel 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.

(16)

Point Ligne Polygone

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.

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

(Source : OpenGIS® Simple Featurres Specification For SQL Revision 1.1)

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.

Figure 4: Modèle pour le stockage des tables selon SQL92 (Type numérique)

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).

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

(17)

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.

(18)

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.

(19)

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.

(source www.esri.com)

Figure 8: Principe de fonctionnement d’ArcSDE

(20)

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

(21)

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 Objet- relationnel 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.

(22)

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 #

1 : Ligne droite 2 : Ligne

2 : Arc

1 : Ligne droite 2 : Arc

3 : Rectangle vrai n003 : nième Polygone de la géométrie

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.

,...) ,

, ,

, ,

( x 1 y 1 x 2 y 2 x 3 y 3

Figure 10: 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 );

(23)

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 Datablade4

• 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 Shapefile5 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.

(24)

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 objet- relationnel 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.

(25)

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 PAC6…).

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

(26)

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

VARCHAR2(4000) Type de compression (JPEG, SUNRLE, 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.

(27)

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 :

(source : Oracle Geoimage characteristics)

Figure 12: Structure du stockage des images géoréférencées avec GEOIMAGE

Elle fait appel aux objets ORDImage d’Intermedia et SDO_GEOMETRY de Spatial7. 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.

Données d’en- tête.

Données vecteurs de l’emprise de l’image

Données RASTER : l’image.

(28)

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.

Figure 13: Interface de l’application de tuilage en ligne

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 14: Module de visualisation

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.

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.

(29)

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 GML8 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.

(30)

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 nom9 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 …).

Feature.xsd : Structure

.GML : Contenu

.XSL / .SVG / .X3D : Forme

http://www.opengis.net/gml ...

http://www.w3.org/XSL/Transform/1.0 Espaces de noms

Document GML

Document XML

Document HTML

XLINK

XLINK

XLINK

geometry.xsd XLinks.xsd

Include

Import

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,

(31)

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, FME10 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.

(32)

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=”&#x20;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 (« »)

Références

Documents relatifs

Un stage peut ne pas être effectué comme il peut être effectué par un seul étudiant (0, N) : donc ce champs NumET peut avoir une valeur optionnelle dans la table STAGE. Il

Schéma de la relation (intention) : Définition structurelle de la relation R 1(Ncli, Nom, Prénom, Adr, Ville) Un n-uplet correspond à une ligne de la relation.  Cardinalité :

Exemple 2 : Dans la table LIGNE-FACUTRES, il existe deux clés étrangères : - Référence du produit, qui référence la clé primaire de PRODUITS ; - N° facture, qui fait

Cette relation est en première forme normale car tous les attributs sont élémentaires et en dépendance fonctionnelle de la clé primaire (la connaissance du matricule d’un

5 Quels producteurs voient tous les films qu’ils produisent. 6 Quels producteurs voient tous les films

Donner pour chaque fournisseur le nom et les noms des produits qu'il fournit. Quels sont les produits fournis par tous

Ait Taleb TECC Techniques cinématographiques Informatique et gestion d’organisation Informatique et gestion d’entreprise. 3.1 Intérêt de

Alami Ali IGE Informatique et gestion d’entreprise Slaoui Rachid IGE Informatique et gestion d’entreprise Nasri Hind IGE Informatique et gestion d’entreprise Belhaj Amina