ECHANGE DE DONNEES A DISTANCE : SVG OU GML ?

5.1 LIMITES DU FORMAT SVG

Nous avons vu avec cette maquette que le langage SVG est bien adapté pour publier des informations

géographiques sur le Web. Mais qu’en est-il de l’échange de données entre SIG ou de l’utilisation de SVG

comme format standard pour un SIG ? SVG est un langage permettant de décrire des graphiques et des

animations. Il n’est absolument pas prévu pour décrire des informations géographiques. Il ne permet par

exemple pas d’associer des propriétés définies par l’utilisateur aux différents polygones représentant des zones.

Il pourrait donc décrire les objets graphiques eux-mêmes (leurs coordonnées), mais pas leurs propriétés. Dans la

maquette, nous avons utilisé l’attribut « class » pour affecter un type à chaque zone ou secteur, mais nous ne

pourrions pas associer plus d’informations en utilisant le seul document SVG.

De plus, nous avons vu qu’il existe des outils pour générer du SVG à partir de MapInfo, mais l’inverse

n’est pas possible. Il faut donc réserver l’utilisation de SVG à la publication des données (sur le Web ou d’autres

médias).

5.2 GML

Le langage GML (Geographic Markup Language) est standardisé par le groupe OpenGIS. Sa deuxième

version date du 20 Février 2001. C’est également un langage XML, mais son objectif est de permettre la

description de données géographiques. Son principe de base est simplement de décrire des objets, avec des

propriétés définies par l’utilisateur, dont certaines peuvent représenter des coordonnées géographiques. Il

pourrait donc être utilisé pour décrire les objets graphiques contenus dans les tables de MapInfo. Voici un

exemple de document GML qui pourrait être utilisé pour décrire une zone géographique :

<Zone fid ="ZUB1"> <Type>UB</Type> <COS>2.0</COS> <gml:extentOf> <gml:Polygon srsName=”http://www.opengis.net/gml/srs/epsg.xml#4326"> <gml:outerBoundaryIs> <gml:LinearRing> <gml:coordinates> 491888.999999459,5458045.99963358 491904.999999458,5458044.99963358 491908.999999462,5458064.99963358 491924.999999461,5458064.99963358 491925.999999462,5458079.99963359 491977.999999466,5458120.9996336 491953.999999466,5458017.99963357 </gml:coordinates> </gml:LinearRing > </gml:outerBoundaryIs> </gml:Polygon> </gml:extentOf> </Zone >

On peut ainsi lier pour un même objet des informations textuelles (ici le type de zone et le C.O.S.) et des

informations grahiques (un polygone). Ce format est bien mieux adapté que SVG pour la manipulation et

l’échange des données géographiques. De plus, il offre tous les avantages des langages XML en termes de

transformation par XSLT. On peut aisément écrire une feuille de style XSLT qui transforme un document GML

en un document SVG qu’on peut présenter sur une page Web par exemple.

Toutefois, il faut noter que ce format est encore très jeune et qu’il existe à ce jour très peu d’outils pour

le manipuler. Les premiers devraient faire leur apparition dans les mois qui viennent. Les développeurs qui

veulent utiliser GML dès aujourd’hui sont donc obligés de développer leur propre code. Et surtout, GML ne fait

pas l’objet d’une recommandation du W3C. On ne peut donc pas affirmer que ce standard va s’imposer. Vu que

les serveurs de données géographiques sont de plus en plus souvent des serveurs Oracle, il se peut que le

standard en matière de description de données géographiques devienne le format choisi par Oracle et non pas

GML. On peut toutefois noter que s’il n’existe pas d’outils effectuant directement la conversion MapInfo $!

5.3 PROPOSITION D’ARCHITECTURE

Nous proposons de s’appuyer sur GML pour définir une structure de document, à la fois pour l’aspect

règlementaire du POS et pour les données cartographiques. Cette définition est formalisée par un schéma XML

qui est une extension de celui de GML.

Notre préconisation est donc d’utiliser GML pour l’échange de données entre systèmes différents, et

éventuellement pour la manipulation des données si les prochaines générations de SIG reconnaissent ce format

en standard. Nous recommandons toutefois de rester très prudent sur ce point car même si GML dispose d’atouts

non négligeables, rien ne permet d’affirmer qu’il sera le standard de demain en matière de données

géographiques. Pour la consultation sur le web, par contre, l’utilisation de SVG reste plus adaptée car il existe

déjà des visualisateurs performants et que ce format permet de réaliser des effets visuels qui s’avèrent utiles pour

une présentation claire et attractive. Les informations textuelles pourront être présentées sur demande en

transformant une partie du document GML en un document HTML grâce à une feuille XSLT. L’architecture à

mettre en place sera donc la suivante :

SIG 1 Document GML _{SIG 1 <--> GML}Conversion SIG 2 Document GML Conversion SIG 2 <--> GML Serveur WWW Document SVG Conversion GML --> SVG Feuille XSLT Utilisateur distant Visualisation des informations graphiques en SVG Document HTML Feuille XSLT Conversion GML --> HTML Visualisation des informations textuelles en HTML

5.4 OUTILS

Il existe encore peu d’outil spécifiquement conçu pour manipuler GML. La société Safe Software commerciale

une suite de logiciels FME, qui permet de manipuler tous types de format de données géographiques, y compris

GML. L’outil Workbench ci-dessous permet de convertir des données d’un format vers un autre, en appliquant

des fonctions de calculs, des opérateurs géométriques et gère notamment les conversions de projection.

La société Galdos Software propose un outil qui permet de créer des feuilles de style visuellement pour mettre

en forme des documents GML en produisant du SVG. Cet outil, Galdos Map Style Editor, est disponible à :

http://mapstyles.galdosinc.com/MapStyle.html