Formats et échanges de l information géographique

Transcription

1 P7 : Projet Bibliographique Dans le cadre du Mastère ASIG Formats et échanges de l information géographique Yohann Ly 15 mai 2008 Mastère ASIG / Projet bibliographique

2 TABLE DES MATIERES 1 CONTEXTE GENERAL 4 2 PROBLEMATIQUE DE L ECHANGE DE DONNEES LES DIFFERENTS PROBLEMES MECANISME D ECHANGE 8 3 LES FORMATS D ECHANGE LES FORMATS PROPRIETAIRES ET D ECHANGE LES FORMATS STANDARDS 13 4 ACCES DIRECT AUX DONNEES ODBC, UNE LIBRAIRIE D'ACCES AUX DONNEES FDO, UNE LIBRAIRIE OPEN SOURCE D'ACCES AUX DONNEES GEOSPATIALES LES PROTOCOLES WMS ET WFS 25 5 LES CONVERTISSEURS DE DONNES LA GEOSPATIAL DATA ABSTRACTION LIBRARY GDAL/OGR LE TRADUCTEUR FME 32 6 REFERENCES 34 Mastère ASIG / Projet bibliographique

3 TABLE DES ILLUSTRATIONS FIGURE 1 : DIFFERENCE D ARCHITECTURE DANS LE STOCKAGE DES DONNEES 6 FIGURE 2 : PROBLEME DE LA PERTE DE SYMBOLOGIE 8 FIGURE 3 : MECANISME D ECHANGE DE DONNEES 9 FIGURE 4 : FICHIERS D EXPORT MIF / MID 11 FIGURE 5 : LE FORMAT GML 15 FIGURE 6 : MODELE DE DONNEE DE L EXEMPLE DE LA FERME 16 FIGURE 7 : CONTENU DU FICHIER XSD DE L EXEMPLE DE LA FERME 16 FIGURE 8 : CONTENU DU FICHIER XML DE L EXEMPLE DE LA FERME 17 FIGURE 9 : TECHNOLOGIE ODBC 20 FIGURE 10 : UNE APPLICATION, UN ODBC, PLUSIEURS DRIVERS 20 FIGURE 11 : FDO, UNE TECHNOLOGIE MODULAIRE 22 FIGURE 12 : UNE APPLICATION, UN FDO, PLUSIEURS FOURNISSEURS 23 FIGURE 13 : SITE DE L OPEN GEOSPATIAL CONSORTIUM 26 FIGURE 14 : ARCHITECTURE CLIENT / SERVEUR POUR LES PROTOCOLES WMS / WFS 27 FIGURE 15 : CONNEXION MAPINFO A UN SERVEUR CARTOGRAPHIQUE VIA WMS 29 FIGURE 16 : FME, LE COUTEAU SUISSE DES SIG 32 FIGURE 17 : INTERFACE FME 33 Mastère ASIG / Projet bibliographique

4 1 CONTEXTE GENERAL Voila une vigtaine d années que les SIG ont fait leur apparition, progressivement, pour être aujourd hui un outil quasi indispensable pour toutes les thématiques visant la gestion de l information géographique. Cette technologie impacte de multiples domaines, plus divers et variés les uns des autres, comme les télécommunications, la gestion du territoire, la gestion des réseaux, le géo-décisionnel etc. Au jour d aujourd hui, de multiples solutions commerciales ou libres se sont implantées dans le monde des Systèmes d Information Géographique, ce qui permet désormais à tout utilisateur d avoir un vaste choix parmi ces solutions. La diversité de ces solutions implique légitimement une diversité au moins égale du point de vue des formats de données disponibles. Chaque éditeur de logiciel est à l origine de son propre format de donnée. Depuis quelques années, beaucoup d organismes utilisant les SIG tendent à se regrouper (exemple des Conseils Généraux, des directions gouvernementales, ) afin de centraliser l information et de la redistribuer. Ce qu il ne faut pas oublier c est que le plus coûteux dans un système d information géographique n est pas le matériel hardware ou bien les logiciels, de par leurs licences et supports, mais ce sont les données en elles même. Là encore, ce fait implique qu un utilisateur de données va plutôt tendre à utiliser des données externes, acquises par un quelconque organisme ou société, de manière payante ou gratuite. A la vue du contexte actuel, il est ainsi tout à fait légitime d apporter une attention toute particulière aux formats de données et à leurs manipulations. C est le concept d interopérabilité. Mastère ASIG / Projet bibliographique

5 «L'interopérabilité est la capacité qu'ont les systèmes des technologies de l'information et de la communication (TIC), ainsi que les processus de fonctionnement qu'ils permettent, d'échanger des données et de permettre le partage des informations et des connaissances.» (Source : Décision n [...]/2004/CE du Parlement européen et du Conseil relative à la fourniture interopérable de services paneuropéens d'administration en ligne aux administrations publiques, aux entreprises et aux citoyens (IDABC)) Mastère ASIG / Projet bibliographique

6 2 PROBLEMATIQUE DE L ECHANGE DE DONNEES 2.1 LES DIFFERENTS PROBLEMES On a vu que l échange de données est incontournable au sein des utilisateurs actuels de l information géographique. Mais pourquoi est-ce si compliqué de s échanger des données de formats différents. Les problèmes sont en effet multiples Architecture de stockage des données Les systèmes qui échangent des données peuvent avoir des architectures de stockage différentes. Une couche peut être décrite géographiquement sur un fichier spatial et chaque entité de cette couche possède ses caractéristiques attributaires dans un ficher différent. La relation est assurée par un identifiant unique. Lors de l échange de cette donnée vers le système cible, ce dernier peut posséder une architecture d archivage contenant qu un SGBD gérant à la fois les données attributaires et les données spatiales. Il faut alors savoir comment passer de l un à l autre tout en assurant la cohérence de l information. Figure 1 : Différence d architecture dans le stockage des données Mastère ASIG / Projet bibliographique

7 2.1.2 Les systèmes de projection La plupart des SIG gère les systèmes de projection, mais il se peut que certains en gèrent que d autres ne gèrent pas. Là encore, le problème n est pas négligeable pour assurer l interopérabilité des données. Ce problème concerne la capacité des logiciels sur cette problématique, mais le problème des systèmes de projection s applique aux données même. Par exemple, le format Shapefile de l éditeur ESRI ne contient pas le système de projection des données dans lequel elles ont été créées. Comment alors pouvoir intégrer ces données à d autres qui possèdent leur projection? La limitation des logiciels L échange de données peut être limité par la technologie même des logiciels. Ainsi les problèmes suivants peuvent survenir : Type d objets supportés (de nombreux logiciels de SIG ne supportent par les arcs qui sont fréquemment utilisés dans des applications cadastrales) Type d objet par couche Taille de l objet Nombre de polygones par couche Nombre de nœuds par polygones Nombre de trous par polygones Tous ces problèmes sont difficiles à prévoir sans avoir une parfaite connaissance des logiciels source et cible La représentation de la symbologie Chaque logiciel a sa propre méthode, plus ou moins sophistiquée selon la catégorie de logiciel, pour représenter les objets géographiques, ce qui pose des problèmes lors de l échange. Très souvent, lors d un transfert de données, on perd toute la symbologie qui a été définie dans le système source. C est un problème important puisque coûteux en temps. Mastère ASIG / Projet bibliographique

8 Certains systèmes gèrent de plus une symbologie en fonction de l échelle dite «symbologie conditionnelle» ou alors en fonction de la valeur des attributs. Figure 2 : Problème de la perte de symbologie 2.2 MECANISME D ECHANGE Afin de pouvoir échanger des données d un système source vers un système but, il faut définir une interface connaissant parfaitement les deux systèmes. Les deux systèmes modélisent une même information suivant deux modèles qui peuvent être plus ou moins différents. L interface devra avoir connaissance de chacun des deux modèles de données et savoir passer de l un à l autre. Pour cela, il y a un format intermédiaire spécifique à l interface. Le passage du format du système source vers le format intermédiaire est l encodage. Le passage du format intermédiaire vers le format du système but est le décodage. Ces deux opérations sont contrôlées par la connaissance de l interface du modèle de données des deux systèmes. Mastère ASIG / Projet bibliographique

9 Figure 3 : Mécanisme d échange de données Mastère ASIG / Projet bibliographique

10 3 LES FORMATS D ECHANGE 3.1 LES FORMATS PROPRIETAIRES ET D ECHANGE Dans la famille des formats de données SIG, il faut distinguer plusieurs types de format de données. Premièrement, il y a des formats dits «propriétaires», c'est-à-dire que ce sont les formats de données propres aux SIG qui servent de base de travail. Le tableau suivant répertorie les différents formats des principaux SIG du commerce. La plupart des formats propriétaires sont au format binaire. Logiciels Formats propriétaires Formats d export ArcView.shp,.shx,.dbf,.cov shp,.eoo MapInfo.tab,.dat,.map,.ind.MIF,.MID AutoCAD map 3D.dwg.dxf MicroStation.dgn Apic.asc.asc L intérêt des éditeurs à préserver leurs formats est multiple : Premièrement de promouvoir l utilisation de leurs gammes de produits Deuxièmement, maintenir leurs clients Enfin, intégrer leurs savoirs sur un support Certains SIG proposent un format d export de leurs données afin que celles-ci soient utilisées sur d autres plateformes. Ces formats sont en général simples à comprendre et leurs structures sont largement documentées afin d en faciliter l usage. Ces formats sont donc souvent choisis codés en ASCII. Là encore on parle de format propriétaire. Nous prenons l exemple des fichiers MIF, MID qui sont les formats d export des données MapInfo. Les formats de travail dans l environnement MapInfo sont tout autre et sont les.tab,.dat,.map,.ind. Mastère ASIG / Projet bibliographique

11 Les formats MIF et MID sont complémentaires et décrivent une couche de données. Le fichier MIF contient le système de projection, la structure de la table attributaire et les coordonnées des objets (donc la géométrie). Le fichier MID, quant à lui, contient les enregistrements des attributs. Figure 4 : Fichiers d export MIF / MID En plus de fournir un format d échange propre à l éditeur, certains SIG proposent aussi d exporter leurs données suivant des formats concurrents. L exemple d ArcView 3.x est montré ci-dessous. Les formats d'import et d'export dans ArcView 3.x : Format Import Export Couverture ArcInfo Lu en natif Couverture PC ArcInfo Lu en natif d échange E00 Outil de conversion au format ArcInfo/PC ArcInfo Couverture ArcInfo d échange E00 Outil de conversion au format ArcInfo/PC ArcInfo Couverture PC ArcInfo Extension de conversion au Script de conversion au format Generate ArcInfo format shapefile : generate : GenerateToShape ShapeToGenerate.ave Mastère ASIG / Projet bibliographique

12 Mif/Mid MapInfo DXF Autocad DWG Autocad DGN Microstation AGF Atlas GIS militaire VPF ERV ErMapper hydrologique S57 SDTS Point Profile Outil de conversion au format shapefile : Mif To Shape Lu en natif avec l extension Cad Reader Lu en natif avec l extension Cad Reader Lu en natif avec l extension Cad Reader Outil de conversion au format shapefile : Atlas Geo File to Shapefile Translator Lu en natif avec l extension Visualiseur VPF (1) Script de conversion au format shapefile : Shape To ERV Lu en natif avec l extension Visualiseur S57 Outil de conversion au format Couverture ArcInfo : SDTS Data Converters Extension de conversion au format Mif/Mid : Import/Export MapInfo Mif/Mid Outil de conversion au format DXF : Shape DXF Converter Extension de conversion au format DWG : Cad Fusion Extension de conversion au format DGN : ESRI shapefile Import Outil de conversion au format AGF : Shapefile to Atlas Geo File Translator Un fait important est que certains formats de données, du fait de leurs fortes utilisations et de leurs renommées, sont devenus des formats standard d échange de données. Ces formats sont appelés standards de fait (ex : format shape d ESRI, format DXF d AutoCAD). Mastère ASIG / Projet bibliographique

13 3.2 LES FORMATS STANDARDS Définition et listing Il existe enfin un dernier type de format dit «format standard» qui est un format validé par différents organismes de standardisation et donc suit une norme stricte. Ces standards ont pour but de décrire l information géographique d une manière normalisée et qui permet de totalement s affranchir du côté applicatif des logiciels ou données propriétaires. Voici une liste exhaustive des différents organismes de standardisation : OPENGIS, OpenGIS Foundation, CNIG, Conseil National de l'information Géographique (France), SNV, Association Suisse de Normalisation (Suisse), INTERLIS, Interlis (Suisse), SDTS, USGS Spatial Data Transfer Standard (USA), COSIG, Le centre de coordination de données géographiques COSIG de l'administration Fédérale, ISO, Organisme de normalisation ISO (Suisse), FGDC, Centre de coordination du National Spatial Data Infrastructure(USA), NGDF, Equivalent de FGDC pour le Royaume-Uni, EUROGI, European Umbrella Organization for GIS, Les principaux formats standard sont les suivants: SDTS: Spatial Data transfert Standard (standard USA) TIGER: Topologically Integrated Geographic Encoding and Referencing DIGEST: Digital Geographic Information Exchange Standard EDIGEO: Norme française GML: Geographic Markup Language Mastère ASIG / Projet bibliographique

14 Les normes standard sont créées afin que l information soit le plus interopérable possible (lisible sur le maximum de plateformes différentes) Zoom sur le GML Définition Geography Markup Language (GML) est une application de XML qui permet de modéliser, échanger et stocker des informations géographiques en incluant les propriétés spatiales et non-spatiales des objets géographiques. Le langage GML permet de décrire les objets géographiques, les systèmes de projection, la géométrie, la topologie, le temps, les unités de mesures et les attributs des objets géographiques. GML peut être utilisé pour définir des modèles de données pour des applications métiers (Télécoms, réseaux, cadastre, aménagement, etc.). Le langage GML, qui s apparente au XML, est très simple à comprendre. Il utilise le principe de balise (comme le HTML) et présente une architecture hiérarchique. Il permet de lier les informations entre elles ce qui est très utile dans l information géographique (ex : attributs liés à un polygone). Du fait de son langage balisé, on peut définir le format GML comme un format modulé, c'est-à-dire qu un utilisateur peut utiliser qu une partie du code pour en retirer les objets qui l intéressent Historique 1999 : premier prototype de GML développé et testé par l OGC au cours de l initiative Web Mapping Testbed (WMT-1) Février 2001 : GML 1.0 publié sous forme de recommandation de l OGC Avril 2001 : approbation de GML 2.0 comme OGC Implementation Specification. GML 2.0 fournit un schéma XML (XML-Schema), des objets complexes et des relations entre objets Mastère ASIG / Projet bibliographique

15 Février 2003 : approbation de GML 3.0 (objets complexes, images, topologies, systèmes de références, métadonnées, etc.) et qui converge avec le format japonais G-XML. Standard international émergent supporté par plus de 200 compagnies et agences en phase de devenir un standard ISO dans la famille ISO TC 211 Certains pays choisissent GML pour la diffusion des données comme Ordnance Survey en Angleterre La structure Le jeu de données décrit en GML se décompose en deux fichiers distincts et complémentaires : un fichier.xsd et un fichier.xml. Le fichier.xsd contient la structure du modèle de donnée (préalablement décrit dans un format comme UML ou HBDS), tandis que le fichier XML contient les données à proprement parler. Figure 5 : Le format GML Mastère ASIG / Projet bibliographique

16 Un exemple concret Prenons l exemple d une ferme qui contient des champs et des bâtiments. Figure 6 : Modèle de donnée de l exemple de la ferme Les fichiers.xsd et.xml associés à la scène sont présentés ci-dessous. Figure 7 : Contenu du fichier XSD de l exemple de la ferme Mastère ASIG / Projet bibliographique

17 Figure 8 : Contenu du fichier XML de l exemple de la ferme Dans cet exemple la géographie n est pas mentionnée, celle-ci serait spécifiée dans le fichier.xsd et renseignée dans le fichier.xml Zoom sur le format français EDIGEO EDIGEO signifie Echange de données informatisées dans le domaine de l'information géographique. Elle a été définie par l'afnor suivant la référence NF Z Elle définit non pas une structure de donnée figée permettant d'échanger des informations géographiques, mais la manière d'échanger les données et de décrire la structure des données transmises. On parle de «lot édigéo» transmis. Ce lot comporte donc une description de la structure des données transmises et les données elles-mêmes (similarité avec le GML). Les données transmises peuvent être de tout ordre : vectorielles, raster, ou bien encore alpha numérique. Mastère ASIG / Projet bibliographique

18 Un lot édigéo comprend un certain nombre de fichiers d'extensions suivants : THF: fichier principal décrivant la transmission de données (références aux fichiers) GEN: données générales (types de structure des sous-ensembles) GEO: sous-ensemble de la référence des coordonnées QAL: sous-ensemble de la description de la qualité (0 ou 1 fichier) DIC: sous-ensemble du dictionnaire ou nomenclature (0 ou 1 fichier) SCD: sous-ensemble du schéma conceptuel des données (0 ou 1 fichier) VEC: sous-ensemble des données géographiques vectorielles (0 à N fichiers) MAT: sous-ensemble des données géographiques matricielles (0 à N fichiers) Tous ces fichiers sont des fichiers "textes" éditables (les fichiers MAT peuvent être binaires). Cette norme de transmission décrit les différents objets par leurs relations de construction et sémantiques entre eux (topologiques ou non). Actuellement, en France, c'est principalement la norme d'échange des données du Plan Cadastral Informatisé (PCI). Ceux-ci ont quelque peu modifié ce standard pour pouvoir décrire leurs données un peu à leur manière. Etant à peu près les seuls à travailler avec, ce problème n en est pas vraiment un. Mastère ASIG / Projet bibliographique

19 4 ACCES DIRECT AUX DONNEES 4.1 ODBC, UNE LIBRAIRIE D'ACCES AUX DONNEES ODBC signifie Open DataBase Connectivity qui définit un ensemble API/pilote permettant la communication entre des clients de bases de données et les SGBD du marché historique En 1992 un sous-comité du SQL Access Group (SAG), qui devait fusionner plus tard avec le consortium X/Open, a défini une API permettant à des applications clientes de communiquer avec des bases de données utilisant le langage SQL. Cette API, dénommée SQL/CLI pour SQL Call Level Interface, a été normalisée aussi bien par ISO que par ANSI en 1993 et a été par ailleurs annexée à la norme SQL-92. Cette spécification a été publiée en 1992 sous la dénomination Microsoft Open DataBase Connectivity (ODBC), mais Microsoft n'en est pas le seul auteur ODBC est une interface procédurale L'API ODBC est une interface procédurale c'est-à-dire que ce n'est pas un protocole à destination d'un serveur, comme peut par exemple l'être le protocole HTTP. L'API est accessible aux applications clientes sous la forme de bibliothèques à liaison dynamique. Ces bibliothèques, conçues habituellement par le fournisseur de la base, constituent le pilote ou driver de la base en question et doivent être installées sur le poste client. La technologie ODBC permet donc d'interfacer de façon standard une application à n'importe quel serveur de bases de données, pour peu que celui-ci possède un driver ODBC (la quasitotalité des SGBD possède un tel pilote). Cette architecture permet de plus de limiter les interfaces entre clients et SGBD. En effet, sans ODBC, il faudrait une interface pour chaque couple client/sgbd. Ici nous avons une interface standard complémentée de drivers spécifiques à chaque SGBD. Mastère ASIG / Projet bibliographique

20 Figure 9 : Technologie ODBC Le gestionnaire ODBC est présent sur de nombreuses plates-formes, notamment des platesformes Windows et de type UNIX. Figure 10 : Une application, un ODBC, plusieurs drivers Il est à noter qu il n existe pas que l API ODBC qui permet de se connecter à des bases de données. Il existe par exemple l API ADO (ActiveX Data Objects), ou bien l API OLEDB qui a été conçu dans le but de remplacer ODBC. OLEDB permet l'accès à des bases de données exotiques ou des sources de données qui n'utilisent pas un processeur de requêtes SQL. Mastère ASIG / Projet bibliographique

21 4.2 FDO, UNE LIBRAIRIE OPEN SOURCE D'ACCES AUX DONNEES GEOSPATIALES FDO signifie "Feature Data Objects". C'est une API, une couche logicielle d'abstraction de l'accès aux données géospatiales. FDO est le morceau de programme qui permet à des outils SIG d'accéder aux données géospatiales. FDO permet d accéder à des données stockées sous forme vecteur, raster ou purement alphanumérique. Ces différentes données peuvent être stockées dans des fichiers, des bases de données, ou accessibles via des services Web comme par exemple de type WMS, WFS, mais aussi plus généralement via des architectures SOA (Services Oriented Architecture) Historique La création de cette API FDO est à l initiative d Autodesk, ne vendant alors que des produits s apparentant uniquement au domaine de la DAO. Autodesk avait besoin d une technologie pouvant permettre l accès à différentes sources de données géospatiales par le biais d un mécanisme commun. Cette technologie devait de plus être flexible afin de s adapter à toutes les technologies clients. Etant développée par l éditeur Autodesk, cette API était bien évidemment payante, ou tout du moins n était fournie qu avec le produit Autodesk Map 3D Celui-ci permettait de se connecter aux bases Oracle et SDF. La version 2.0 permit ensuite la connexion à ArcSDE, puis la version 3.0 à MySQL, SQL Server, ODBC, SHP, Raster, OGC WFS, et OGC WMS. En été 2006, Autodesk offrit au monde du logiciel libre (OSGeo), son produit MapGuide et du même coup la technologie FDO, avec les fournisseurs à SDF, SHP, MySQL, ArcSDE, ODBC, OGC WFS, et OGC WMS. Le moteur FDO est donc désormais open source, et développé en mode «communautaire», ouvert, et distribué sous licence LGPL. Mastère ASIG / Projet bibliographique

22 4.2.2 Une architecture modulaire FDO correspond à une architecture modulaire. Cela signifie que FDO se compose d un noyau fixe qu on installe au produit, puis de modules supplémentaires appelés fournisseurs ou FDO provider qu on lui ajoute si nécessaire. A chaque source de données correspond un fournisseur. Accéder à un nouveau format de données requiert uniquement la réalisation ou l installation d un nouveau fournisseur, mais en aucun cas la recompilation de FDO. Cette technologie est assimilable à celle d ODBC, à ceci près que FDO gère les données géospatiales. Figure 11 : FDO, une technologie modulaire Certains fournisseurs FDO sont open source, d autres sont propriétaires. Certains fournisseurs sont mis à disposition et supportés par Autodesk, d autres sont uniquement disponibles via l OSGeo et supportés par la communauté. Les développeurs de fournisseurs FDO sont multiples. Il y a bien sûr Autodesk. La communauté en a aussi développé certains, comme le fournisseur FDO pour OGR (sorte de FME) et le fournisseur FDO pour GDAL (homologue à OGR mais pour les données raster). Il y a aussi Safe Software, qui intègre à FME 2007 un fournisseur FDO. Grâce à ce fournisseur, tous les produits qui intègrent FDO accèdent nativement aux formats fournis par FME. A ce jour, ce fournisseur FDO pour FME ne supporte que les données vectorielles, et est en lecture seule. Refractions (la société qui est derrière PostGIS) développe un fournisseur natif FDO pour PostGIS. On est ici dans un modèle très pertinent, permis par FDO : c'est l'expert de la technologie de base de données qui réalise le fournisseur d'accès à cette base de données. Mastère ASIG / Projet bibliographique

23 Figure 12 : Une application, un FDO, plusieurs fournisseurs Un point très important est que FDO est une API qui gère la lecture mais peut aussi gérer l écriture des données. Ces propriétés dépendent du type de données auxquelles le FDO se connecte. Un tableau récapitulatif est fourni ci dessous. fournisseurs Description ArcSDE MySQL SDF SHP ODBC WFS Accès en lecture / écriture sur des données stockées dans une base ArcSDE (sur un support Oracle ou SQL Server database). Accès en lecture / écriture sur des données stockées dans une base MySQL. Accès en lecture / écriture sur des données stockées dans une base SDF (format géospatiale d Autodesk). Accès en lecture / écriture sur des données ESRI SHP Accès en lecture / écriture sur des données stockées dans une base ODBC. Accès en lecture seule sur des objets stockés sur une base OGC WFS. Mastère ASIG / Projet bibliographique

24 fournisseurs Description WMS GDAL OGR Oracle Accès en lecture seule sur des objets stockés sur une base OGC WMS. Accès en lecture seule sur des rasters stockés sur une base GDAL. Accès en lecture / écriture sur des données vecteurs stockées sur une base OGR. Permet l accès à Oracle spatial dans les versions 10G, Oracle Express Edition (Oracle XE) et Oracle 9i. Les utilisateurs de FDO : 1Spatial Product FDO Version Radius Studio v Autodesk Product FDO Version Autodesk Map 3D Autodesk Map 3D Autodesk Map 3D Autodesk Map 3D Autodesk Map 3D Autodesk MapGuide Enterprise Autodesk MapGuide Enterprise Autodesk MapGuide Enterprise Open Source Product FDO Version MapGuide Open Source MapGuide Open Source MapGuide Open Source MapGuide Open Source MapGuide Open Source Mastère ASIG / Projet bibliographique

25 Safe Software Product FDO Version FME FME 2006 GB SL-King Product FDO2FDO v0.7.4 FDO Version 3.2.x Geomap Systems Product Geomap 2008 FDO Version 3.2.x 4.3 LES PROTOCOLES WMS ET WFS l'open Geospatial Consortium Fondée en 1994 en réponse à la non-interopérabilité des systèmes et des données dans le domaine de l'information géographique, l'open Geospatial Consortium est une organisation internationale à but non lucratif. Ses objectifs sont de résoudre les problèmes d'incompatibilité des données constituant l'information géographique et les problèmes d'inter-opérabilité des systèmes, problèmes soulignés par l'ensemble de la communauté géomatique. Ainsi, l'objectif de l'ogc est de rendre les systèmes d'informations géographiques inter-communicables et inter-opérables, au travers de prescriptions techniques traduites dans des spécifications OpenGIS. L'Open Geospatial Consortium regroupe des organismes privés et publics actifs dans le domaine des technologies de l'information géographique, et compte plus de 250 membres tels que : Des éditeurs de logiciels SIG : AutoDesk, Cadcorp, ESRI, Intergraph, Mapinfo,... Des constructeurs de matériel informatique et de logiciels : Adobe, Helwett-Packard, Microsoft, Oracle, Sun Microsystems,... Des agences gouvernementales : AUSLIG, BRGM, NASA, Natural Resources Canada, NIMA, NOAA, Ordnance Survey, USGS,... Mastère ASIG / Projet bibliographique

26 Des organisations inter-gouvernementales : FAO, Centre Satellitaire de l'union Européenne, Nations Unies,... Des producteurs de données : NAVTEQ, Space Imaging, Spot Image, Tele Atlas,... Des universités et instituts de recherche : EPFL, National Center for Atmospheric Research (NCAR), Office International de l'eau, Université Laval, Université de Vienne, Université de Tokyo,... Des sociétés de développement informatique et de service : Ionic Software, Webraska,... Des sociétés diverses : Boeing, Mitsubishi, Shell, Vodafone,... Figure 13 : Site de l Open Geospatial Consortium Mastère ASIG / Projet bibliographique

27 4.3.2 Le protocole WMS WMS (Web Map Service) est un protocole standardisé permettant la consultation de données géoréférencées stockées sur un serveur cartographique. On parle ici d accès directe à la donnée et ce indépendamment de la technologie utilisée. Figure 14 : Architecture client / serveur pour les protocoles WMS / WFS Le protocole WMS supporte trois types de requêtes standard : GetCapabilities : cette requête permet d interroger le serveur cartographique sur le type de données qu il possède. Les informations qui sont renvoyées sont la liste des couches, le format des images produites, les systèmes de projections Mastère ASIG / Projet bibliographique

28 GetMap : Cette requête permet de récupérer la carte spécifiée par le client, celui-ci connaissant toutes ses caractéristiques par la précédente requête. Il doit donc renseigner la liste des couches voulues, le système de projection, les coordonnées de visualisation, le format de sortie GetFeatureInfo : cette opération permet de récupérer les informations attributaires dont les coordonnées sont connues. Exemples de requête WMS : GetCapabilities : GetMap: t=getmap&srs=epsg:4326& BBOX=-100,- 90,100,80&WIDTH=400&HEIGHT=400&LAYERS=Continents,Rivers,Glaciers%20(all%20sizes)&S TYLES=&FORMAT=image/png Pour chacune des requêtes effectuées par l utilisateur, celle-ci est traitée du côté du serveur cartographique et la réponse est renvoyée sous forme d un fichier XML(GetCapabilities) ou GML(GetMap). Cette réponse sera facilement interprétable par le poste client disposant d un viewer. On ne cherche donc plus maintenant à partager de la donnée, mais on partage aussi les fonctionnalités d un système de traitement de l information géographique. Concernant la carte, celle-ci peut être au format image (JPEG, PNG, GIF, ) ou vecteur (SVG). Quelques logiciels SIG (ArcGis, Geomedia, MapInfo, OpenJump, Google Earth ) proposent maintenant de pouvoir interroger des services WMS directement à partir de leurs interfaces. Voici une liste exhaustive des web clients pouvant se connecter à des serveurs cartographiques via le protocole WMS : UMN Mapserver, MapBender RedSpider Web de IONIC Mastère ASIG / Projet bibliographique

29 CubeSERV WMS XtraWMS, WMSViewer Intergraph Cadcorp SIS ArcIMS + OGC WMS Connector GeoMedia WebMap Autodesk MapGuide, Mapguide OpenSource Mapinfo MapXtreme Figure 15 : Connexion MapInfo à un serveur cartographique via WMS Un point important à préciser est que le protocole WMS ne permet que la visualisation des données géoréférencées et ne permet en aucun cas la manipulation de celles-ci. Le service se base essentiellement sur la consultation de carte raster. Mastère ASIG / Projet bibliographique

30 4.3.3 Le protocole WFS Le protocole WFS (Web Feature Service) est le protocole standardisé conçu par l OGC pour la manipulation et la création de données présentes sur un serveur cartographique. Les opérations de manipulation de données permettent des opérations de recherche, d'extraction et de transaction (c.-à-d. ajout, mise à jour ou suppression). Ces données sont au format vecteur. Ce protocole dispose de 5 interfaces pour envoyer des requêtes au serveur : GetCapabilities : identique à l interface de WMS DescribeFeatureType : retourne la structure de chaque entité présente sur le serveur (format XML) GetFeature : permet de récupérer des objets géométriques ou attributaires sous forme GML LockFeature : cette fonction permet à un utilisateur d'empêcher la mise à jour d'une entité particulière par d'autres utilisateurs Transaction : cette interface permet la mise à jour des données. Les fonctions associées sont les suivantes : InsertElement, DeleteElement, UpdateElement Mastère ASIG / Projet bibliographique

31 5 LES CONVERTISSEURS DE DONNES Au temps ou l échange de données est de plus en plus répandue et recherchée, de nombreux outils de traduction de données géographiques ont fait leur apparition. Certains sont directement intégrés dans le SIG et d autres fonctionnent indépendamment de la plateforme SIG. Ce chapitre présente de manière exhaustive trois de ces principaux outils. 5.1 LA GEOSPATIAL DATA ABSTRACTION LIBRARY GDAL/OGR La Geospatial Data Abstraction Library GDAL/OGR est une bibliothèque de traduction géospatiale raster/vecteur multiplateformes, développée en langage C++ et supportée par l Open Source Geospatial Foundation. Elle se présente à l'application mère comme un unique modèle de données, applicable à tous les formats supportés. GDAL/OGR inclut une variété d'utilitaires en ligne de commande pour la traduction et la manipulation de données géospatiales. GDAL supporte plus de 50 formats d'imagerie et OGR plus de 20 formats vectoriels. GDAL et OGR servent de supports de données pour de multiples applications comme MapServer, GRASS, QGIS, et OpenEV. Ils sont aussi utilisés comme package dans OSSIM, Cadcorp SIS, FME, Google Earth, VTP, Thuban, ILWIS, MapGuide et ArcGIS. Les formats de données intégrés par GDAL/OGR raster GeoTIFF Erdas Imagine SDTS ESRI Grids ECW MrSID JPEG2000 DTED vecteur MapInfo (tab and mid/mif) ESRI Shapefile ESRI Coverages ESRI Personal Geodatabase DGN GML PostGIS Oracle Spatial Mastère ASIG / Projet bibliographique

32 5.2 LE TRADUCTEUR FME FME signifie Feature Manipulation Engine. FME est plus qu un simple traducteur de données. Il est également paramétrable, ce qui permet d effectuer des opérations lors de la traduction comme la généralisation, construction de topologies, transformation de coordonnées, rotation, contrôle de cohérence, jointure de tables... Il s agit d un véritable SIG «boîte à outil» pour l échange de données. Figure 16 : FME, le couteau suisse des SIG Comme les autres convertisseurs concurrents, FME peut traduire un format de données vers un autre. La plupart des logiciels de traduction de données le font avec des données dont les formats sont structurés de façon semblable. L avantage de FME est que le procédé peut se dérouler avec des formats de structures différentes. Un exemple: INTERLIS est un format relationnel qui supporte des géométries complexes et qui définit également la représentation de l objet ; par contre MapInfo n est pas Mastère ASIG / Projet bibliographique

33 relationnel, ne supporte pas d objets complexes, mais la représentation de l objet est définie dans son format. FME réalise aussi des traductions sémantiques. Avec des logiciels comme FME, l échange de logiciel se trouve fortement facilité. Un exemple : Le gestionnaire du SIG d une région est amené à gérer les données acquises par le district, et il a la responsabilité de distribuer celles-ci sur demande aux partenaires de la région. Ces derniers disposent tous de leur propre logiciel (MapInfo, AutoCad,...). Le gestionnaire est ainsi amené à extraire les données dans la base de données de l'association et de transformer le format original pour permettre aux partenaires de les utiliser. De plus, les partenaires n'étant pas des spécialistes, des demandes de transformations et de calculs sont souvent faites au gestionnaire. Figure 17 : Interface FME Mastère ASIG / Projet bibliographique

34 6 REFERENCES Sites web : Présentation : «Mécanismes d échange de données, formats et méthodes de compression», EPFL, Laboratoire de Systèmes d Information Géographique (LaSIG) Mastère ASIG / Projet bibliographique