SIG

Services web gographiques,

tat de lart et perspectives
Henri Pornon henri.pornon@ieti.fr
Pierrick Yalamas pierrick.yalamas@ieti.fr
Elise Pelegris elise.pelegris@hotmail.fr

Introduction
Quel gomaticien na pas entendu
parler de services web, dans
le contexte de louverture de son
SIG des partenaires externes,
de la mise en conformit avec les
exigences de la directive Inspire
ou encore de lurbanisation du
systme dinformation de son
organisme?
Cet article, qui prsente les rsultats dinvestigations menes par
IETI Consultants depuis plus dun an
sur le sujet a plusieurs objectifs:

Clarifier quelques aspects de
dfinition sur les services web
gographiques, notamment en les
positionnant dans le cadre plus
gnral des services web informatiques;

Figure 1: Un utilisateur accde, via un client

de services web des services proposs par
diffrents serveurs de services web.

44

Prsenter les conclusions dune
enqute et dun test dinteroprabilit ralis sur les solutions du
march;

Identifier les principaux enjeux
lis au dploiement de services
web dans le domaine de la gomatique.

Dfinitions
Quest-ce quun service web?

Les services web (on utilise souvent

le sigle WS-*) mergent au dbut
des annes 2000 dans le monde
des systmes dinformation dans
le contexte de la mise en uvre
dArchitectures Orientes Services
(SOA: Service Oriented Architecture),
dont lobjectif est de rendre plus
modulaire et moins propritaire
le dveloppement des logiciels
et applications informatiques, en
implmentant les fonctions applicatives lmentaires sous forme
de modules. Composs de services normaliss et interoprables,
ils sont susceptibles dtre ensuite
combins et rutiliss pour donner
naissance de nouvelles solutions
ou processus composites.
Dans cette architecture, un service
ralise un ou plusieurs traitements
exposs laide dune interface
dcrivant un message dentre
(lappel du service) et un message

Gomatique Expert - N 65 - Octobre-Novembre 2008

de rponse (le rsultat obtenu).

Ce service peut tre utilis par un
utilisateur humain, mais est surtout
destin tre appel par dautres
services ou par des logiciels. On
peut dvelopper des services dans
divers environnements informatiques, mais la plupart des services
sont aujourdhui dvelopps dans
des environnements web (do
lexpression de services web)
et doivent respecter quelques
standards que nous voquerons
plus loin.
Un service web peut donc tre
considr comme une fonctionnalit mise en place par un fournisseur sur un serveur distant,
accessible un outil client via le
web, sans intervention humaine
(automatisation), et ce quelle que
soit la technologie utilise (interoprabilit).
Les outils logiciels mis en uvre
peuvent donc avoir deux rles:

Les outils clients consomment
des services web;

Ces services web sont accessibles sur un ou plusieurs serveurs
de services web.
Notons dailleurs quun serveur
SIG peut tre simultanment client
de services web (pour accder
des donnes prsentes sur
dautres serveurs) et serveur
(pour mettre disposition ces

donnes, ventuellement traites,

dautres composants logiciels).
Quest-ce quun Service web
gographique?

Les services web gographiques

sont des services web permettant deffectuer des traitements
gomatiques ou gographiques
(gocodage), de renvoyer des
cartes ou de donner accs des
donnes gographiques (dbit dun
fleuve, altitude, nom dune zone
gographique). Ils constituent
en principe un sous-ensemble
des services web et doivent se
conformer aux mmes exigences.
Cependant, pour la plupart des
gomaticiens, au-del de la confusion entre services web et webmapping que nous voquons plus loin, le
terme services web voque surtout
les standards de lOpen Geospatial
Consortium (OGC) dcrits dans les
tableaux n1 et n2.
Ces standards ont pour objectif
de rendre les SIG interoprables entre eux plutt quavec les
autres composants des systmes
dinformation. Lide est donc

Acronyme

quune donne ou une fonction

stocke dans un environnement
logiciel SIG puisse tre accessible
directement partir dun autre
environnement sans tlchargement ni conversion pralable.
Dans cette logique, un organisme
rend ses donnes accessibles via
le web laide dun logiciel serveur
respectant un standard de lOGC
(WMS, WFS), ce qui permet un
utilisateur disposant dun logiciel
client, respectant galement ce
standard, de visualiser, voire de
manipuler ces donnes comme si
elles se trouvaient sur son poste.
En dautres termes, lintrt des
standards de lOGC et des services
web gographiques est de permettre un utilisateur de SIG bureautique de combiner sur son poste
des donnes venant de plusieurs
sources distantes ou locales,
et de les traiter comme si elles
taient stockes sur son poste. Il
est galement possible de mettre
en ligne sur un outil SIG Internet/
Intranet des donnes provenant de
plusieurs sources sans avoir les
transfrer et les convertir prio-

Nom

diquement. Ceci confirme, dune

part, quun outil de webmapping
peut ou non utiliser des services
web gographiques, dautre part,
que le concept de service web
gographique ne saurait se limiter
la dimension du webmapping.
Distinguer services web
gographiques et webmapping

On parle de webmapping pour

voquer un ensemble dapplications cartographiques dynamiques
et interactives disponibles sur le
web permettant principalement
un utilisateur de visualiser des
cartes contenant plus ou moins
dinformations gographiques. Le
terme dynamique signifie que
des fonctions comme le zoom, le
choix de laffichage des couches
ou encore des gadgets comme
les info-bulles sont disponibles.
On parle de webSIG quand les
fonctions incluent de plus des
requtes attributaires et spatiales
ou encore des gotraitements plus
labors.
Il ne faut pas confondre webmapping ou webSIG et services web

Usage
Fournit une carte au format image, pouvant correspondre la superposition de plusieurs couches
de donnes.
Permet la publication de catalogues de mtadonnes (relatives des donnes ou des services) et
la recherche parmi les entres de catalogues.

Anne de
publication 1

Version
actuelle

2000

1.3

1999?/2000?

2.0.2

WMS

Web Map Service

CS-W

Catalog Service

CT

Coordinate
Transformation

Transformation de coordonnes.

2001

1.0

WFS

Web Feature Service

Fournit et permet la mise jour de donnes

gographiques au format GML.

2002

1.1

WCS

Web Coverage Service

Fournit une couverture, cest--dire de

linformation gographique numrique reprsentant des phnomnes variant dans lespace et le
temps (par exemple MNT, images satellite...).

2003

1.1

Location Services

Services de base pour les applications mobiles:

affichage de carte, gocodage, calcul ditinraire

2004

1.1

SOS

Sensor Observation
Services

Gestion de capteurs et collecte de donnes de ces

capteurs.

2007

1.0.0

SPS

Sensor Planning Services

Service de planification de linterrogation de

capteurs (et rcupration de donnes associes).

2007

1.0.0

WPS

Web Processing Service

Services de gotraitement.

2008

1.0

OpenLS

1 Nous donnons ici lanne de publication de la version 1.0 du standard (sauf exception pour le KML o la premire version adopte a t la 2.2).
Tableau n1: Principaux standards de services de lOGC.

Gomatique Expert - N 65 - Octobre-Novembre 2008

45

Acronyme

Nom

Usage

Anne de
publication

Version
actuelle

1.2.0

Simple Feature

Format de stockage de et daccs aux donnes

gographiques vectorielles.

GML

Geography Markup
Langage

Format dchange de donnes gographiques

vectorielles.

2000

3.2.1

SLD

Style Layer Descriptor

Permet aux utilisateurs de fournir des informations sur la symbologie et les styles pour
laffichage dune carte (donnes WMS ou WFS).

2002

1.1.0

Filter Encoding

Dcrit un encodage XML pour les expressions de

requtes.

1.1.0

Web Map Context

Sauvegarde dun tat de la carte affiche par le

client, la carte pouvant tre constitue de plusieurs couches issues de diffrents serveurs.

2003

1.1

SensorML

Sensor Model Langage

Langage de modlisation pour les capteurs.

2007

1.0.0

CityGML

City Geography Markup

Language

GML application schema pour le stockage et

lchange de modles de donnes 3D urbains.

2008

1.0.0

KML

Anciennement Keyhole
Markup Langage

Format permettant laffichage de donnes gospatiales.

2008

2.2

SF

FE
WMC

Tableau n2: Standards de formats de l'OGC.

gographiques, mme si les outils

sont parfois les mmes. La diffrence se situe dabord au niveau
des usages: dans le premier cas,
lutilisateur joue un rle important,
dialogue avec le logiciel et il sagit
donc dune relation human to
machine. Dans le cas des services
web, le but est que deux systmes
puissent dialoguer et changer,
de manire automatise et sans
intervention humaine. Les services web suivent donc une relation
quon qualifierait de machine to
machine et une application de
webmapping peut dailleurs faire
appel un service web pour aller
chercher des donnes demandes par lutilisateur, sans que
celui-ci sache o sexcutent les
traitements et o sont stockes
les donnes.
Le deuxime lment qui diffrencie webmapping et service
web est li cette diffrence de
relation. Une relation machine
to machine implique que les
systmes amens communiquer
entre eux puissent le faire, quelle
que soit leur nature: ils doivent
tre interoprables. Et cette
interoprabilit ncessite une
normalisation, une standardisation
des changes. Le webmapping na
pas pour vocation damener diffrents systmes communiquer

46

de faon automatique et ne pose

donc pas les mmes problmes de
standardisation.
Il est primordial de saccorder sur
une dfinition lorsquon parle de
services web gographiques car
les confusions et abus de langage
existent et sont frquents.
Services web et standards informatiques associs

Pour assurer linteroprabilit

des composants logiciels client et
serveur de services web, plusieurs
standards ont t dfinis.
Dans le monde des services
web informatiques, les standards sont ceux du W3C (World
Wide Web Consortium), dont les
plus connus sont le protocole
dchange SOAP (Simple Object
Access Protocol) et WSDL (Web
Service Description Langage) pour
la description du service. Le standard UDDI (Universal Description
Discovery and Integration), ayant
pour vocation initiale de standardiser la cration dannuaire de
services a eu du mal simposer
et reste trs peu utilis. Dautres
standards (WS-*) ont galement t dvelopps par lOasis
(Organization for the Advancement
of Structured Information Standards)
pour grer divers aspects tels que

Gomatique Expert - N 65 - Octobre-Novembre 2008

la qualit de service ou la scurit

par exemple.
Les services web dcrits par un
document WSDL et changeant
des messages au format SOAP
peuvent ainsi sintgrer dans
un systme dinformation plus
gnral.
noter que le protocole SOAP,
vritable standard du domaine
des services web, est contest
pour plusieurs raisons: il est assez
verbeux du fait de lusage de XML,
ce qui peut entraner des problmes de performances (au traitement et lacheminement) et est
considr comme lourd mettre
en place (outils informatiques
requis pour son dploiement).
Cest la raison pour laquelle a
merg Rest (REpresentational State
Transfer), style darchitecture logicielle (cest le style architectural
du web) base sur le constat que
le protocole web HTTP fournit
lensemble des mthodes (Get,
Post, Put, Delete) permettant de
manipuler des ressources
prsentes sur Internet identifies
par leurs URI (Uniform Resource
Identifier). Cette Architecture
Oriente Ressources constitue
une alternative aux Architectures
Orientes Services fondes sur
les standards WSDL et SOAP.

Les standards propres au domaine

de la gomatique sont, bien
entendu, les standards de lOGC
dcrits sommairement dans les
tableaux n1 et 2. Ces standards
ont pour objectif, comme nous
lavons vu, de favoriser linteroprabilit entre diffrents outils SIG.
Remarquons que, mme si cela est
en train dvoluer, les standards
de lOGC se situent plutt dans la
logique Rest que dans la logique
SOAP.
Services web et urbanisation
des systmes dinformation

Pour conclure cette prsentation

trs gnrale, il faut signaler que
les architectures SOAP poursuivent
la mme logique que les dmarches durbanisation des systmes
dinformation, visant transformer les systmes dinformation
traditionnels constitus de silos
applicatifs faiblement connects
et peu communicants, en systmes
dinformation modulaires, ouverts
et communicants.
On pourrait ainsi, dans cette
logique (mais on en est encore
loin), informatiser un processus
dinstruction des procdures durbanisme en combinant des services
fournis par un SIG (pour tout ce
qui est cartographique) avec des
services fournis par un logiciel
mtier dinstruction des procdures durbanisme ainsi que dautres
composants informatiques dans
un processus mtier pilot par un
outil dorchestration. Aujourdhui,
on utilise, le plus souvent, ces
deux logiciels en les connectant
par une interface partiellement
ou totalement propritaire, mais
cette interface sera trs prochainement remplace par lappel dun
service web gographique partir
de lapplication dinstruction des
procdures durbanisme.
Dans cette perspective, les SIG
sont soumis la mme contrainte
que les autres environnements
logiciels du march: ils vont
devoir mettre disposition tout
ou partie de leurs fonctions sous

forme de services exposs dans

une interface et respectant les
standards informatiques (nous
entendons ici les standards tels
que SOAP, WSDL et les autres standards WS-*), de faon permettre
leur intgration dans des architectures informatiques urbanises.
Peu de gomaticiens ont identifi
cette dimension des services web,
qui aura dans les annes venir un
impact important sur le dploiement et lvolution de leurs SIG,
du fait des dmarches durbanisation des systmes dinformation
en cours.

Des services web

gographiques
interoprables?
Les paragraphes prcdents
montrent que linteroprabilit
des services web gographiques
peut sapprcier de deux points
de vue: interoprabilit dans les
environnements SI, qui ncessite
le respect des standards services
web informatiques (WSDL,
SOAP), interoprabilit dans les
environnements SIG, qui ncessite
le respect des standards de lOGC
(WMS, WFS). Sur ce deuxime
point en particulier, ds linstant
o lon sintresse la possibilit
daccder des donnes par des
services web gographiques, la
question de linteroprabilit des
clients et des serveurs se pose.
Nous avons donc ralis une
enqute et une srie de tests
dinteroprabilit avec lobjectif de
rpondre plusieurs questions:

Quels sont les logiciels permettant de mettre effectivement en
place des services web OGC?

Quelles garanties dinteroprabilit?

Quelles diffrences de mise en
uvre?

Quel respect des standards
associs?

Au-del de ces standards, les
outils logiciels permettent-ils de
mettre en place de vrais servi-

ces web respectant les standards

W3C?

Si oui, quels sont ces services?

Dans les deux cas, quel niveau
de comptence est requis pour la
mise en place des services?

Quel niveau de documentation
est disponible?
Nous prsentons ici les principales conclusions de lenqute
ralise lautomne 2007 et du
test dinteroprabilit ralis au
printemps 2008.

Enqute auprs
des diteurs
de SIG
Une premire enqute auprs des
diteurs de logiciels SIG a permis
de les classer en quatre catgories,
du point de vue de la mise en place
de serveurs de services web (voir
liste complte des diteurs contacts dans le tableau n3).
Une premire catgorie est constitue dditeurs ayant dvelopp
des services web avant lapparition
des standards OGC et dont les
outils permettent de mettre en
place des services aux standards
W3C (notamment, proposant
une interface SOAP et dcrits
par WSDL). Ils sont en gnral
fortement impliqus dans lOGC,
ses dispositifs de certification et
respectent ses standards ds que
ceux-ci sont stables: en gnral,
WMS, WFS, WCS et CS-W, parfois
SLD, FE ou WMC.
Une deuxime catgorie est
constitue dditeurs implmentant les standards OGC ds quils
sont stabiliss et quils prsentent
un vritable intrt: en gnral,
WMS est pris en compte, WFS
(T) est en cours dimplmentation
et WCS ignor pour linstant. Les
standards associs sont en cours
dimplmentation. Leurs outils ne
permettent en gnral pas dexposer les services via une interface

Gomatique Expert - N 65 - Octobre-Novembre 2008

47

Fournisseur (Serveur)
Autodesk (Mapguide)
Goconcept
Geomod
IONIC Software
Khops (Jmap)
Mapgears (Mapserver)
Star-Apic (NeXt)

Standards tests
WMS
WMS
WMS et WFS
WMS et WFS
WMS
WMS
WMS

Outils clients tests

ArcGIS 9.2
Mapinfo ProFEssional 9.0
QGIS 0.9
gvSIG 1.1.2
Udig 1.1 RC14
Socit

Rponse

ACXIOM

OUI

AUTODESK

OUI

BENTLEY

OUI

ESRI

OUI

SIRAP

OUI

STAR-APIC

OUI

NETAGIS

OUI

GEOCONCEPT

OUI

INTERGRAPH

OUI

IONIC

OUI

EMC3

NON

INFO TP

NON

SIMALIS

NON

GEOMOD

NON

Tableau n3: Enqute auprs des diteurs

de SIG. Serveurs et clients tests.

SOAP et/ou de les dcrire par un

document WSDL.
Une troisime catgorie est constitue dditeurs peu avancs dans
limplmentation des standards
OGC. Les standards ne sont pas
supports (certains sappuient
sur des outils libres pour offrir
des services WMS ou WFS) et ces
outils ne permettent bien entendu
pas non plus de mettre en place
des services web bass sur les
standards W3C.
La quatrime catgorie regroupe
les outils dvelopps au sein de
la communaut Open source, qui

48

permettent de mettre en place des

services web aux standards OGC,
mais ne permettent pas la mise en
place de services web bass sur les
standards W3C.

par loutil client SIG dautre part.

Les fonctionnalits offertes par le
serveur sont facilement obtenues
par une approche Rest, en faisant
une requte getCapabilities.

Interoprabilit

Cette comparaison permettait

de mieux cerner lorigine des
ventuelles difficults constates:
service mis en place par le serveur,
relation client/serveur ou outil
client?

Le but des tests raliss tait

de vrifier la capacit dutiliser
ou consommer des services web
gographiques et de tester linteroprabilit entre serveurs
de services web et outils SIG
clients, propritaires et libres,
en se plaant du point de vue
de lutilisateur. Nous cherchions
donc, par exemple, consommer
avec divers SIG bureautiques des
services WMS mis en place avec
divers serveurs SIG. Nous souhaitions notamment voir sil existe
des diffrences dinteroprabilit
entre les serveurs certifis par
lOGC et ceux qui ne le sont pas.
Seuls des services web gographiques respectant les standards OGC
WMS et WFS ont t tests. Du
ct client, cinq outils SIG ont t
choisis. Les URL des serveurs nous
ont t transmises par leurs fournisseurs (nous avons test toutes
celles mises notre disposition).
Le but tait non seulement de
tester linteroprabilit, mais galement de vrifier comment le client
et le serveur communiquent,
partir dune srie doprations
susceptibles dtre ralises sur
des donnes fournies sous forme
vectorielle (associe au standard
WFS) ou en format image (associ
au standard WMS): affichage/
slection, gestion des systmes
de projection, gestion des formats
dimage, gestion des tables attributaires, requtes attributaires et
spatiales, mtadonnes, gestion des
erreurs
Nous avons galement dcid
dinclure dans nos protocoles une
comparaison entre les fonctionnalits offertes par loutil serveur
dune part et celles disponibles

Gomatique Expert - N 65 - Octobre-Novembre 2008

Les tests ont rvl que linteroprabilit client/serveur qui existe

sur le plan thorique nest pas
toujours effective sur le plan pratique. Les problmes identifis se
situent pour plus dun tiers des cas
(37% pour le WMS et 37,5% pour
le WFS) au moment de laffichage
de la couche: bien que loutil client
se connecte au serveur, la couche
choisie ne saffiche pas.
Nous avons relev de relles
diffrences entre les serveurs
certifis (compliant) par lOGC et
les serveurs affirmant seulement
respecter les standards WMS et/ou
WFS. Les couches mises disposition par les serveurs certifis par
lOGC saffichent avec tous les outils
SIG clients. Les rsultats des tests
montrent par ailleurs que les diffrences observes sont plus imputables la faon de consommer
les services web des logiciels SIG
clients qu des diffrences entre
les serveurs. Nous nous sommes
ainsi rapidement rendu compte
que les rsultats taient souvent
identiques pour un mme outil
client accdant divers serveurs
et que les diffrences sont dans la
plupart des cas dues la faon dont
les outils clients filtrent les informations disponibles sur le serveur.

Les enjeux
des services web
Quel intrt pour le gomaticien
de se proccuper de compatibilit
avec les standards gomatiques de lOGC ou du W3C? Pour

le gomaticien, les enjeux lis aux

services web se situent deux
niveaux, celui du dploiement ou
de lvolution des outils gomatiques dune part, celui de lintgration des outils gomatiques dans
le SI dautre part.

Figure 4: Exemple dune requte directe en Get (ici un GetCapabilities sur un service mis
en place par un outil Goconcept).

Enjeux lis au dploiement ou

lvolution des outils gomatiques

Les standards OGC peuvent apporter une rponse la demande dinteroprabilit entre les outils SIG
en interne, mais aussi et surtout
dans le contexte de la diffusion
de donnes vers des partenaires
externes. En interne, en effet,
dautres solutions dinteroprabilit comme le partage dune mme
base de donnes spatiales sont plus
flexibles, mme si, dans certains
cas, la diffusion de services web
standardiss partir de loutil SIG
Intranet est une faon de les rendre
accessibles dautres SIG. En
revanche, pour un organisme qui
souhaite mettre une partie de ses
donnes disposition dorganismes
externes, la diffusion sous forme
de services web conformes aux
standards OGC facilitera lutilisation
des donnes par les partenaires
externes, en cumulant les avantages
et en vitant une partie des inconvnients des deux autres modes de
diffusion couramment utiliss.
Le premier consiste pour le partenaire rcepteur tlcharger les
donnes de lmetteur et les
intgrer dans son SIG. Ceci lui
donne une grande autonomie dans
lusage des donnes et lui permet
de disposer de toutes les fonctions
de son SIG, mais loblige rditer
lopration priodiquement pour
bnficier des mises jour des
donnes. Dans le second, le partenaire accde un site Internet ou
Extranet sur lequel il peut consulter
des donnes jour, mais ne dispose
que des fonctions auxquelles on
veut bien lui donner accs.
La mise disposition de donnes
sous forme de services web standardiss offre au partenaire les
deux possibilits: il peut utiliser

Figure 5: Exemple de filtre par linterface cliente: le rsultat de la requte getCapabilities (

gauche) montre que les donnes peuvent tre transmises aux formats PNG, GIF, JPEG, BMP,
TIFF alors que le client (saisie dcran de linterface droite) ne parle que PNG.

les donnes comme si elles taient

intgres son SIG (et parfois
mme en faire une copie locale),
mais accde toujours aux donnes
les plus rcentes. Le seul inconvnient est que la disponibilit
des donnes est lie celle du
serveur qui les met disposition
et aux performances des moyens
de communication utiliss.
De fait, il est souhaitable quun
organisme squipant dun outil
Intranet susceptible dvoluer vers
une logique Extranet ou Internet
vrifie la capacit du serveur SIG
mettre en ligne des services web
conformes aux standards OGC.
Faut-il exiger pour autant la certification OGC ou raliser des tests
dinteroprabilit? Nous avons
vu que les diffrences se situent
aujourdhui plus au niveau des
clients que des serveurs, ce qui
limite fortement lintrt de tests
dinteroprabilit si lorganisme ne
connat pas les outils clients des
partenaires qui accderont ses
donnes.
Une autre volution importante
concerne les plates-formes partenariales dployes dans divers territoires (dpartements et rgions
notamment). Bon nombre de ces
plates-formes offrent aujourdhui
des services de tlchargement

et de webmapping. Elles vont bien

entendu devoir voluer pour
fournir aussi des services web
conformes aux standards de lOGC
(Prodige, la plate-forme dveloppe
par les SGAR Rhne-Alpes et Pays
de Loire permet, par exemple,
dj de mettre disposition des
services respectant les standards
WMS, WFS et WMC). Cependant,
de plus en plus dorganismes diffusent dj et diffuseront demain
des donnes sous forme de services web, ce qui pose la question
du primtre de la plate-forme
partenariale. Doit-elle stocker des
donnes, accessibles par lensemble des partenaires sous forme
de tlchargement, webmapping
ou services web, ou bien doit-elle
jouer un rle de portail et de
mta-annuaire permettant ses
utilisateurs daccder aux donnes
accessibles sur les sites des partenaires (pointage vers des services
web dj existants)?

Urbanisation des SI
Les dfauts des SI actuels (silos)
peuvent tre corrigs ou attnus
dans les nouvelles architectures
base de services web, dans lesquels
les applications sont remplaces par
des composants mtier exposs
sous forme de services, communi-

Gomatique Expert - N 65 - Octobre-Novembre 2008

49

quant entre eux par des protocoles

standardiss (SOAP, WSDL).
Si la DSI souhaite mettre des
ressources gomatiques disposition dautres composants du SI de
lorganisation dans une logique de
services web, il est ncessaire de
mettre en place de vrais services
web bass sur WSDL et SOAP-XML,
ce qui ncessite de mobiliser de
vritables comptences en SI (DSI,
appel un intgrateur spcialis).
Notons dailleurs que les standards
de services web gographiques de
lOGC sont actuellement plutt
sur une logique Rest, mme si
des volutions sont en cours. Un
service web WMS mis en place
nest donc pas ncessairement
dcrit par un document WSDL et
nexpose pas forcment le service
sous forme de message SOAP. Il
est galement souhaitable quune
dmarche durbanisation du SI ou
dinterconnexion des silos applicatifs ait t lance.

Identifier
des services web
gographiques
Il ny a aujourdhui pas de rponse
satisfaisante cette question.
lorigine du dveloppement

des services web, il tait prvu

de documenter les services web
disponibles dans des annuaires
UDDI, avec lide trs utopique
que les organismes dveloppant
ces services les documenteraient
dans de tels annuaires pour partager la ressource avec dautres.
En fait, ces annuaires sont trs
peu nombreux et trs peu renseigns pour de multiples raisons.
Il est donc difficile aujourdhui
de faire connatre ses services
notamment daccs aux donnes
(sauf aux partenaires directement
destinataires de ces donnes) et
bien entendu difficile didentifier
un service et une donne accessible par ce moyen quand on est
utilisateur.
La place importante prise par
Google comme intermdiaire dans
laccs la donne tend faire
voluer la problmatique de catalogage de donnes gographiques
vers une problmatique dindexation de ces donnes, conduisant le
format KML devenir un standard
de documentation.
Le WSDL reste cependant incontournable partir du moment o
les services web Gographiques
doivent tre utiliss dans des
architectures SOA ou urbanises.

Conclusion
Avec le dveloppement des services web (gographiques ou non)
et des architectures urbanises, le
monde des systmes dinformation
vient une fois de plus rappeler aux
gomaticiens que leurs outils et
leurs dmarches ne peuvent pas
rester lcart des autres outils
informatiques. De plus en plus, les
SIG doivent sintgrer au systme
dinformation, donc adopter les
concepts et disposer des passerelles appropries. De ce point de
vue, le travail de standardisation
effectu par lOGC, qui vise surtout
rendre les SIG interoprables
entre eux, apporte une rponse
aux gomaticiens, mais ne peut
satisfaire totalement les informaticiens. Lvolution vers les architectures urbanises est inluctable
et ne passera pas par WMS ou
WFS, mais par WSDL, SOAP et les
autres standards du W3C, ainsi que
par la mise disposition de fonctions SIG sous forme de services
standardiss, ce que permettent
dj quelques diteurs de SIG.
Ceci ncessite que la diffrence
entre webmapping et services web
dune part, et le dcalage entre
les approches informatiques
et gomatiques des services
web dautre part, soient assimils
par les gomaticiens.

Bibliographie
Bonnet P.; Cadre de Rfrence web Services Whiteside A.; OpenGIS web services architec Meilleure Pratique; Orchestra Networks; sept ture description, version 0.1.0; OGC Inc.; 17 nov
2005
2003 (dernire mise jour 23 fv. 2005)
Doyle A., Reed C.; Introduction to OGC web Richardson L., Ruby S.; Restful web Services;
OReilly; 2007; 446p.
Services; OGC Inc; 30 mai 2001; pdf 11p
Fournier-Morel X., Grojean P., Plouin G. et al.; webOGRAPHIE
SOA Le guide de larchitecte; Dunod, sgli; Dfinition WS-* (Wikipdia): http://en.wikipedia.
org/wiki/WS-%2A#web_Services_Interoperability_
2006; 302p
Kadima H., Monfort V.; Les web Services organization_.28WS-I.29_Specifications

Techniques, dmarches et outils XML, WSDL, SOAP, Standards de lOGC: http://www.opengeospatial.

UDDI, RosettaNet, UML; Dunod, 01 Informatique; org/
Standard du W3C: http://www.w3.org/
2004; 411p

50

Gomatique Expert - N 65 - Octobre-Novembre 2008