Cours de Webmapping et Projet client-serveur

0. Introduction
Ce que nous appelions les « nouvelles technologies de l'information et de la communication » (NTIC) il
y a encore peu, est désormais un ensemble d'outils largement utilisé quotidiennement par tout un
chacun, que ce soit dans le contexte professionnel ou bien privé. Les systèmes d'information
géographique ont intégré ces nouvelles technologies avec comme conséquence immédiate une
explosion du nombre d'utilisateurs.
Les solutions SIG web ont fait leur apparition il y a une bonne dizaine d'années. Toutefois elles n'ont
supplanté les solutions historiques bureautiques que relativement récemment, profitant de l'accessibilité
accrue au web. Ces solutions ont reposé dans un premier temps sur des architectures client-
serveur classiques puis depuis récemment sur des architectures orientées services. Elles ont
permis de mettre le SIG à la portée d'une communauté large d'utilisateurs et pour certaines d'entre elles
à la portée du grand public.
Ces architectures se caractérisent par la centralisation des données et des traitements sur des serveurs
et l'accès à ces ressources par le biais de clients, c'est-à-dire d'un programme conçu pour accéder et
interagir avec des données géographiques distantes. Cette interaction est portée par les mécanismes
standards du web que ce sont HTTP, les urls, AJAX, XHTML, ... mais aussi par des normes et des
développements propres au monde de la géomatique.
La mise en place de solutions SIG web a d'abord été un phénomène interne à l'entreprise et aux
administrations : les solutions intranet ont permis de donner l'accès au SIG à un coût acceptable à
l'ensemble des opérateurs ou bien des chargés d'études directement intéressés dans l'exercice quotidien
de leurs activités. Depuis 2005, et la généralisation de l'accès haut débit à l'internet, le phénomène
touche aussi le grand public (Google Earth, Google Maps, portails institutionnels des
collectivités locales et des services publics, ...).

1
Très vite les applications dites de webmapping se sont multipliées, chacune proposant de consulter
des données sur une thématique précise (le trafic routier, la météo, les risques environnementaux) à
travers un site web dédié.
Bien que favorisant l'accès à la donnée géographique, ce modèle de développement consistant à
développer une solution originale et indépendante pour chaque besoin a montré rapidement ses limites.
En effet, la véritable plus-value des SIG c'est d'être capable de mettre en relation sur un même
territoire des données issues de sources différentes. Il est intéressant de connaître la localisation des
zones sous la menace d'un aléa environnemental (crue, glissement de terrain) ; il l'est encore davantage
de croiser cette donnée avec la carte de répartition de la population : c'est le croisement de ces données
qui crée de l'information, que les pouvoirs publics vont pouvoir exploiter à des fins décisionnelles.
D'une manière générale, toutes les problématiques d'aménagement du territoire ne peuvent être traitées
qu'en croisant de nombreux critères, donc de multiples sources de données produites pour chacune par
des experts attitrés. Le besoin de décloisonner l'accès aux données thématiques est donc apparu et
avec lui la nécessité de rendre les SIG interopérables.
Pour toutes ces raisons, l'essor des SIG passe depuis quelques années par des architectures orientées
services, qui étendent le concept d'architecture client-serveur. Les données et les fonctionnalités ne
sont plus centralisées sur une seule et même machine mais au contraire distribuées sur plusieurs
serveurs. En outre, elles ne sont plus rendus accessibles comme élément d'un tout (le site web) mais
au contraire comme éléments indépendants et librement réutilisables dans différents contextes.
La mise en place de tels systèmes interopérables suppose que les différentes machines s'accordent
sur ce qu'est une donnée ou encore un traitement géographique. L'interopérabilité requiert donc
l'élaboration de normes. Cela n'implique pas la mise au point d'une solution technique unique mais
plutôt l'interfaçage des solutions à l'aide de langages communs. En matière de services webs, les
standards en question sont REST et SOAP. L'interopérabilité géographique a ses normes propres,
élaborées par une association de géomaticiens, l'Open Geospatial Consortium ou OGC qui sont
WMS, WFS ou encore WPS.
Dans cet esprit, la France s'est dotée en 2007 d'un portail national, le Géoportail dont le rôle est de
mettre à disposition de tout un chacun le socle de données de référence produit par l'IGN mais aussi de
cataloguer les sources d'information géographiques produites sur le territoire. Afin de favoriser la
réutilisation de ses services dans différents contextes utilisateurs, le Géoportail met également à
disposition des développeurs une interface de programmation, ou API. Une API accélère le processus
de développement d'une application de webmapping en permettant la réutilisation de fonctionnalités
SIG génériques préprogrammées. Sans compétence très avancée de programmation, il devient possible
de créer une application personnalisée permettant d'afficher des données géographiques métier sur un
fond de référence, de les interroger, d'effectuer des recherches par adresse, de saisir en ligne de
nouvelles données ou encore d'effectuer des traitements complexes (calcul d'itinéraires). Il existe
d'autres API géographiques et notamment la plus connue d'entre elles : l'API Google Maps.

1. Bases du Webmapping
1.1. Principes
Conformément à la règle des « 5A », on peut définir la partie logicielle du SIG comme un ensemble
organisé d'outils permettant l'abstraction, l'affichage, l'acquisition, l'archivage et l'analyse de données
géographiques.
Depuis 10 ans, on a vu apparaître des applications webs qui permettent d'accéder à des données
géographiques mais qui du fait de leurs fonctionnalités réduites ne sont pas à proprement parler des
SIG. Ces applications répondant à un besoin bien précis sont destinées à diffuser dans des navigateurs
des données cartographiques interactives.

2
Définition:
Par webmapping , on entend la diffusion par le biais d'un site web de données
cartographiques. L'accès à l'information doit être dynamique ce qui signifie que ce qui s'affiche doit
être le résultat d'un traitement déclenché à la demande de l'utilisateur.
Les technologies utilisées sont avant tout celles du web :
• architecture client-serveur, dans laquelle
o le client est un navigateur capable d'interpréter du code HTML
o le serveur est à la fois
▪ une machine qui archive des documents et des programmes susceptibles de les
générer à la demande
▪ un programme permettant le dialogue avec le client
• protocole HTTP pour les échanges entre le client et le serveur
• stockage des données dans des fichiers et des bases relationnelles (PostgreSQL, MySQL) interro-
geables à l'aide du standard SQL.
• les standards HTML, Javascript, AJAX, XML, SVG élaborés par le World Wide Web Consortium
(W3C) pour le développement de l'application à proprement parler
Par nature, le web permet l'acheminement d'un document hypertexte (pouvant contenir des images
donc des cartes) d'un serveur où il est stocké à un client où il est affiché. Le document peut aussi être
produit à la demande et ce en fonction de critères fixés par le client; dans ce cas, le client accède en
fait à un programme distant chargé de générer le document.
Cette apparente simplicité cache en fait une architecture logicielle multi-couches ainsi qu'une diversité
de solutions techniques possibles.

1.2. Fonctionnalités
Une application de webmapping permet a minima
• De cartographier à la demande des données géographiques (choix des couches, choix de l'emprise
géographique)
• D'afficher la carte dans un navigateur
Elle permet aussi le plus souvent
• D'imprimer la carte
• D'effectuer des mesures sur la carte
• D'interroger les données cartographiées afin d'accéder à leur sémantique
• D'afficher cette sémantique dans un navigateur
• D'effectuer des recherches portant sur la sémantique (quelles sont les communes dont la popula-
tion a diminué entre 1999 et 2010 ?) ou la géométrie des données cartographiées (où est située
l'école primaire la plus proche du 12 rue de la Paix ?)
• D'afficher les résultats de ces recherches dans un navigateur
• De localiser sur le fond de carte une adresse postale ou communale
3
Elle permet parfois
• De saisir de l'information et ainsi d'alimenter la base de données stockée sur le serveur
• D'effectuer des traitements complexes (calcul d'itinéraire)
Selon le niveau de fonctionnalités, on a affaire ou pas à un SIG stricto sensu. Dans tous les cas, elle ne
met à disposition que des outils qui font sens au regard d'un besoin précis. C'est une différence
fondamentale avec le SIG académique qui lui doit couvrir l'ensemble des besoins potentiels.
Prenons l'exemple du SIG en ligne du Secrétariat Général du Comité Interministériel à la Ville

C'est une application de webmapping type, développée à l'aide de la technologie MapServer permettant
d'accéder à la demande à des cartes statistiques sur tout le territoire Français et ce à différentes échelles
(région, département, commune, ilôts). Il s'agit essentiellement d'un outil de consultation. L'outil de
qualification d'une adresse selon qu'elle est ou pas en Zone Urbaine Sensible en fait toutefois un outil
d'aide à la décision. C'est vraiment un SIG.
Son interface est très académique. On y retrouve :
• une fenêtre cartographique
• une barre d'outils de navigation (pan, zoom)
• un gestionnaire des couches
• une mention de l'échelle courante
• un pavé de légende
Le dialogue utilisateur utilise essentiellement les outils de navigation mais aussi des controls de saisie
et des listes de choix pour spécifier les requêtes ainsi que des boutons commande pour les exécuter,
toute chose que l'on rencontre habituellement lorsqu'on navigue sur un site web.

4
 On pourrait multiplier les exemples de sites de webmapping à l'infini. Chaque collectivité, ministère ou
entité en charge d'un territoire communique par le biais d'un tel site. On citera simplement le géoportail
de la ville d'Issy-les-Moulineaux ainsi que celui de la ville du Havre (http://lehavre.fr/maps).

1.3. L'architecture d'une application web

Le web ce sont des machines communiquant en réseau à l'aide d'un langage commun. Parmi ces
machines, on distingue celles qui proposent des ressources, les serveurs, et celles qui les utilisent, les
clients. Les ressources peuvent être par exemple des documents hypertexte, des images, des fichiers
XML ou encore des programmes (PHP, Java, ASP.NET, Python, Perl, ...) chargés de les générer à la
demande.
Quand un client accède à une ressource c'est généralement pour consulter un document. Parfois, le
client utilise aussi le web pour modifier des données stockées sur le serveur. Dans ce cas, il accède
nécessairement à une ressource de type programme.
Pour atteindre une ressource, le client doit utiliser le protocole de communication HTTP : ce dernier
définit une sémantique très simple (GET, POST, PUT et deux ou trois autres commandes) permettant
de formuler des requêtes qui sont interprétées côté serveur par un programme spécifique : le serveur
web. Les requêtes sont acheminées en mode texte par le réseau. La communication n'est donc pas
sécurisée (il existe pour cela HTTPs).

Définition:HTTP :
HyperText Transfer Protocol, protocole de communication entre client et serveur permettant d'accéder
à des ressources distantes. A été conçu à l'origine pour échanger des documents hypertextes HTML.
Une requête HTTP est composée d'un en-tête (HEAD) et d'un corps (BODY). Les solutions de
webmapping reposent sur des requêtes GET et POST.
Sur le web, une ressource est identifiée par son url (chaîne de caractères). Lorsque le client souhaite
atteindre une ressource distante, il émet donc une requête HTTP mentionnant l'url de la ressource ; la
requête comporte aussi dans certains cas une liste de paramètres valués que la ressource devra
exploiter.

Définition:URL :
Uniform Resource Locator. Chaîne de caractères normalisée destinée à être utilisée par tout client web
pour atteindre une ressource
Si le client souhaite récupérer un document statique, i.e. qui est stocké physiquement sur le serveur il
envoie une requête GET sans paramètre. Si, et c'est le cas qui nous intéresse en webmapping, il
souhaite obtenir un document fabriqué à la demande, alors il peut envoyer au serveur web une
requête GET ou bien une requête POST, mais avec paramètres. Les deux fonctionnent, ce qui les
différencie c'est la façon dont les paramètres sont transmis. Dans une requête GET, les paramètres sont

5
 passés dans l'URL de la ressource, donc dans la partie HEAD de la requête au contraire de POST qui
stocke les paramètres dans le BODY.
Pour faire court, disons que POST offre un premier niveau de sécurité en masquant les échanges
d'informations entre le client et le serveur.

Côté serveur, c'est le serveur web (Apache, IIS, ...) qui traite la requête HTTP.

Définition:Serveur web :
Programme chargé de traiter les requêtes HTTP adressées par les clients. Le serveur web décode les
requêtes et retourne les documents demandés.
Si la ressource est un document archivé, il lui suffit de le localiser et de l'envoyer en retour au client,
non sans avoir vérifié que ce dernier dispose bien des droits d'accès. C'est en fait un peu plus complexe,
puisque par définition les documents du web sont à tiroir : un document hypertexte contient le plus
souvent des liens vers d'autres documents. Le traitement de la requête client nécessite donc de
rassembler en cascade un ensemble de documents et de les acheminer en retour au client. Si la
ressource est un programme, alors le serveur web localise le programme en question, lui transmet les
paramètres de la requête et lui délègue le traitement à proprement parler. L'architecture d'un site web
dynamique suppose donc côté serveur l'existence d'une extension au serveur web destinée à exécuter
le script en question (extension php ou Tomcat/Java pour Apache, ASP.NET pour IIS, ...).

Définition:Site web dynamique :

Page web qui permet au client d'obtenir un document à la demande. La fabrication à la demande est
prise en charge par un script exécuté par une extension au serveur web.
Dans l'immense majorité des cas, pour fabriquer le document à la demande, le script utilise les valeurs
des paramètres transmis par le client et extrait les données correspondantes depuis un système de
gestion de bases de données sécurisé (base de données MySQL ou PostGreSQL) ; les données sont
ensuite traitées et formatées pour être lues par le client (HTML, XML,...). Ce qui constitue de fait une
troisième couche logicielle. On parle d'architecture n-tiers.

Définition:Architecture n-tiers :
Modèle d'organisation en couches des différentes composantes logicielles d'un site web dynamique.
Le fichier PowerPoint animé ci-dessous illustre les mécanismes de communication de base entre un
client et un serveur de page web. Chaque diapositive est commentée.

6
Un SERVEUR, c'est un ordinateur, c'est-à-dire des capacités
de stockage et de traitement, accessible à distance par un
réseau.
Un serveur Internet est accessible par le réseau Internet.
Un serveur met à disposition d'autres ordinateurs
dits CLIENTS un certain nombre de ressources qu'il stocke.
Les clients sont connectés au même réseau que le serveur.
L'architecture client-serveur permet de PARTAGER la
même ressource entre un très grand nombre d'utilisateurs.
HTTP est un protocole d'échange d'information dans une
architecture client-serveur. Il permet de définir un
mécanisme de dialogue entre client et serveur.
L'accès aux ressources est à l'initiative du client.
Le serveur fournit automatiquement la ressource demandée
Le fonctionnement d'un serveur suppose toutefois la présence
d'un administrateur pour des opérations ponctuelles liées à la
mise à jour des ressources, à la sécurité, au bon
fonctionnement d'ensemble.
Quelle sont les ressources accessibles au client et stockées
sur un serveur ?

7
Internet est avant tout fait pour mettre à
disposition des clients des
documents HTML.
Dans le cas le plus simple, le site web
auquel se connecte le client ne contient
qu'un seul fichier HTML.
Pour l'atteindre, le client tape dans son
navigateur l'URL du document HTLM
en question.
Le navigateur envoie une
requête HTTP au serveur mentionné
dans l'url pour obtenir le document. Une
requête HTTP permet un échange
d'informations entre un client et un
serveur. Elle comporte donc deux
temps : la demande et la réponse à la
demande.
Sur le serveur, un programme est chargé
de traiter les requêtes des clients : c'est
le serveur web. Son rôle est de décoder
la requête HTTP puis de prendre les
dispositions pour récupérer la ressource
demandée.
Ici, la ressource demandée est un fichier
HTML stocké sur le disque dur du
serveur. Il lui suffit donc de le localiser
puis d'envoyer son contenu en guise de
réponse à la requête HTTP.
Le navigateur réceptionne les
informations. La requête HTTP est close.
Le navigateur interprète le code HTML
et affiche le contenu correspondant.

8
 Dans la plupart des cas, une page web
HTML contient des références vers
d'autres fichiers de données que le
navigateur client doit également
demander au serveur pour afficher le
contenu complet de la page.
C'est le cas ici : la page web HTML
contient un fichier image stocké sur le
serveur.
Le dialogue client serveur se passe en
plusieurs étapes : tout d'abord
récupération du document HTML de la
page voulue ; interprétation du code par
le navigateur puis demande du fichier
image figurant dans le document ;
réception du fichier image ;
recomposition du document puis
affichage de la page complète.
Lorsqu'une page est dynamique elle
permet au client d'interagir avec elle.
Le mécanisme le plus simple repose sur
les formulaires HTML.
Un formulaire c'est un ensemble
d'éléments (inputs) HTML proposant
une interaction avec l'utilisateur (saisie
de texte, clic sur image, clic sur bouton) ;
certains éléments du formulaire (bouton,
image) ont la propriété de pouvoir
déclencher l'envoi d'une requête HTTP
vers le serveur. Cette requête vise le
script associé au formulaire : elle
transmet au script les informations saisies
par l'utilisateur.
Ici, le client se connecte à une page
web multiplication.html qui contient
deux inputs de saisie de nombres et un
bouton pour déclencher la requête.
Le script appelé est un script
PHP : calcul.php, les valeurs transmises,

9
les deux nombres dont le script doit faire
la multiplication.
Comme précédemment, le serveur web
traite la requête HTTP ; il localise le
script stocké sur son disque dur et
délègue à l'extension logicielle
appropriée l'exécution du script. Ici c'est
l'application PHP qui est chargée de
l'exécuter. Le résultat du traitement est un
document HTML qui contient le résultat
de la multiplication.
Le serveur web récupère ce document
dynamique et l'envoie en guise de
réponse à la requête.
Le navigateur réceptionne, interprète le
code et affiche l'information.
Dans la majorité des cas, la génération
dynamique d'un document HTML en
réponse à une interaction client nécessite
d'extraire de l'information dans un
Système de Gestion de Bases de
Données.
Côté serveur, au serveur web et à
l'extension logicielle chargée d'exécuter
le script, s'ajoute donc une nouvelle
couche logicielle : le SGBD. On parle
d'architecture n-tiers.
Ici, le client se connecte à une page
web affiche.commandes.html qui permet
de saisir le nom et le prénom d'un client
d'une société. Un clic bouton permet
d'initier le dialogue HTTP entre le
navigateur et le script commandes.php
Comme précédemment, côté serveur
c'est l'application PHP qui exécute le
script ; le but étant de dresser la liste de
toutes les commandes passées par le
client en question ; l'application PHP doit
obtenir cette information à partir d'une
autre application s'exécutant sur le
10
 serveur, le SGBD. Pour extraire
l'information souhaitée, le script PHP
utilise le langage universel
d'interrogation des BD, SQL.
Une fois l'information obtenue, le script
la met en forme et crée ainsi un document
HTML qu'il adresse au serveur web.

1.4. L'architecture d'une application de

webmapping
Dans le cas d'une application de webmapping classique, on retrouve l'architecture en couches décrite
précédemment.
Toutefois, le traitement de la requête SIG formulée par le client nécessite de disposer côté serveur d'un
programme spécifique : c'est le serveur SIG. C'est lui qui va être capable de produire à la demande
une carte dans le système de coordonnées souhaité ; c'est lui encore qui va identifier l'école primaire la
plus proche du 12 rue de la Paix ; c'est lui également qui va proposer l'itinéraire le plus rapide pour aller
de Champs sur Marne à Versailles le 21 juillet 2010 à 17h30.

Définition:Serveur SIG :
Programme s'exécutant côté serveur chargé de traiter la requête géographique formulée par le client.
Se présente dans deux configurations possibles : une extension au serveur web, i.e. un exécutable
capable de communiquer directement avec le serveur web ou bien une API ou bibliothèque de fonctions
utilisable dans un script pris en charge par une extension au serveur web
Tout comme vu précédemment, les données sont stockées dans une base de données spatiales (MySQL,
PostGIS, Oracle, ArcSDE, ...) et extraites à la demande.
Si on reprend l'exemple du portail du Secrétariat Général du Comité Interministériel à la Ville, pour
obtenir une carte des revenus par IRIS pour la ville de Paris le cheminement peut être décomposé
comme suit :

C'est le mécanisme qui est décrit dans le fichier Powerpoint animé et commenté ci-dessous :

11
 La première génération de sites de webmapping
fonctionnaient selon le mécanisme dynamique
n-tiers décrit précédemment.
L'utilisateur se connecte à une page web qui
contient dans un formulaire HTML une carte
sous forme d'une image (JPEG, PNG,...).
Lorsqu'on clique sur l'image pour se déplacer
ou zoomer on déclenche le script de traitement
associé au formulaire. On peut également
déclencher le dialogue HTTP après avoir choisi
d'activer certaines couches d'information et
cliqué sur un bouton de validation.
Ici, c'est un script PHP, webmap1.php qui est
exécuté sur le serveur. Ce dernier doit générer
une nouvelle carte conformément aux souhaits
formulés par l'utilisateur. Cela étant, PHP seul
ne dispose pas des capacités pour produire une
telle carte. Il s'en remet donc à une application
tiers, le serveur carto qui lui sait faire.
Pour générer la carte, il y' a deux solutions : soit
elle est recréée à la demande ; il faut alors
extraire les données utiles dans un SGBD puis
les symboliser ; soit un cache à déjà été calculé
et il suffit de récupérer les tuiles correspondant
à l'étendue à cartographier.
C'est le premier des 2 cas qui est décrit ici
Dans une telle architecture, le serveur génère à la volée des cartes au format image (JPEG, PNG, BMP,
...) que le client peut directement afficher. C'est la solution historique qui a montré un certain nombre
de faiblesses et notamment la lenteur d'ensemble du système. En effet dans ce schéma, tous les
traitements sont pris en charge par le serveur. Selon la charge de ce dernier et dans une moindre
mesure selon les temps de transfert sur le réseau, le temps d'obtention d'un document peut être plus
ou moins important.
Une première solution consiste à répartir différemment le travail entre le client et le serveur. Au lieu de
fournir une image prête à l'affichage, le serveur peut envoyer des données géographiques vecteur, i.e.
des objets géométriques décrits par des coordonnées et qualifiées par un certain nombre de valeurs
d'attributs.
Il existe plusieurs façons de formater des données vecteur en vue de leur utilisation sur un client
web. SVG et Flash sont deux solutions populaires. SVG est un format vecteur lu nativement par
12
 certains navigateurs (Firefox) qui permet de dessiner des objets géométriques simples. Flash est une
solution propriétaire qui s'est imposée comme la référence pour la mise en œuvre d'animations sur le
web ; Flash permet notamment le dessin vectoriel. Pour générer des flux de données Flash, il faut
acheter une licence d'utilisation. En outre pour qu'un navigateur puisse interpréter les données, il faut
l'équiper d'un plug-in, le Flash Player, qui lui est librement téléchargeable.

Définition:Flux de données entre le client et le serveur :

Image ou vectoriel. Les flux images permettent d'acheminer une donnée directement exploitable par le
navigateur (une carte) ; les flux vectoriels (plus légers) nécessitent d'être traités par le client.
De nombreux sites utilisent ces technologies qui fournissent d'excellents résultats dans certaines
conditions (nombre d'entités géométriques à dessiner peu important).

Exemple:
Prenons l'exemple du portail des transports de la ville de Dijon, utilisant la technologie
Flash.(http://www.divia.fr/carte/index.php?verif=1)

Une autre solution pour contourner les problèmes de réactivité consiste à s'affranchir du tout
dynamique au sens strict du terme et à pré-cartographier les données. On définit plusieurs échelles
dites de référence pour lesquelles on va cartographier les données. Ensuite, pour chaque échelle (on
parle encore de niveau), on découpe la carte selon une grille régulière de façon à former une mosaïque
d'imagettes. On dit qu'on crée un cache de données côté serveur.

Définition:Site de webmapping avec cache de données :

Pré-cartographie des données et archivage d'une pyramide à n niveaux d'imagettes côté serveur
Ça diminue considérablement le temps de réponse puisque le rôle du serveur SIG se limite ensuite à
fournir les imagettes ou dalles intersectant l'emprise à cartographier. Les serveurs de données grand
public, type Google ou Géoportail fonctionnent tous selon ce principe.
Le mécanisme est illustré dans le fichier PowerPoint animé et commenté ci-dessous :

13
 Vous devez cliquer sur l'astérix pour télécharger le powerpoint

On détaille le mécanisme d'une page de

webmapping 1ère génération avec fabrication à
la demande à partir d'un cache d'images
cartographiques.
Contrairement au cas précédent, pour recréer la
carte telle que l'utilisateur l'a demandée, il n'est
pas nécessaire d'aller chercher les données dans
le SGBD ; il suffit au serveur carto de trouver
les tuiles pré-calculées recouvrant l'emprise à
cartographier. Cela fait, le serveur carto indique
l'emplacement des images à l'application PHP
qui à son tour crée le document HTML attendu.
Celui-ci est reçu par le navigateur client qui
constate qu'il contient de nombreuses images. Il
demande au serveur de lui fournir chacune
d'entre elles.
Une fois toutes reçues, il les assemble et affiche
la page complète.

1.5. L'architecture d'une solution

webmapping AJAX
Les évolutions récentes des technologies web ont pleinement profité aux applications de webmapping.
Elles ont résolu en partie les problèmes de lenteur évoquées au paragraphe précédent.
Dans la conception historique du web, quand un client accède via une URL à la page d'un site dynamique
il envoie une première requête HTTP et doit patienter jusqu'à réception et affichage de tous les éléments
de la page. Ensuite, chaque fois qu'il se déplace sur la carte, qu'il zoome ou bien qu'il valide un formulaire
de recherche, le client envoie une requête dans le but de régénérer le document complet. Or, la page
HTML d'une application de webmapping est un document souvent complexe : elle comporte en effet
plusieurs éléments qui doivent ainsi être recréés à chaque interaction ; pendant ce temps le client attend
... ou pas d'ailleurs car souvent il se lasse.
Récemment, la technologie AJAX (Asynchronous Javascript and XML) a révolutionné l'expérience
utilisateur. AJAX consiste en fait à introduire dans la page HTML du site du code Javascript dont le
rôle est de dialoguer en arrière plan avec le serveur. Ce dialogue consiste comme précédemment à
accéder à des ressources dynamiques mais aussi, et c'est ça qui améliore les choses, à traiter localement
côté client les réponses retournées. Dès lors, une interaction utilisateur ne provoque plus la régénération
du document complet mais affecte simplement l'élément du document qui doit être modifié. Ce

14
 mécanisme repose également sur la description sous forme d'objets du document HTML, description
plus connue sous le terme de DOM (Document Object Model).

Définition:AJAX :
Mécanisme de communication optimisée entre le client et le serveur reposant sur des échanges
asynchrones (en arrière plan) n'interrompant pas le dialogue. Evolution nécessaire du web dynamique
connue sous l'appellation web 2.0. Un objet Javascript inclus dans la page HTML est chargé d'adresser
les requêtes au serveur ainsi que de décoder les réponses.
En 2010, tous les sites de webmapping utilisent AJAX et plus particulièrement l'objet Javascript
XMLHTTPRequest dont le rôle est d'envoyer des requêtes GET ou POST au serveur mais aussi de traiter
les réponses obtenues.
AJAX a permis d'imaginer de nouveaux moyens d'échanger les données géographiques entre le serveur
et le client. Désormais, certaines couches d'informations sont transférées en mode vecteur au coup par
coup en fonction des demandes du client et c'est le client qui les cartographie. Le travail du serveur
consiste alors à générer dynamiquement un flux texte formaté en XML (ou GML, KML) en réponse à la
requête HTTP contenant les objets demandés. D'autres formats sont utilisés comme JSON (ou plutôt
GeoJSON) dont le parsage est naturel en Javascript ou encore Flash qui reste un standard très apprécié.

Définition:XML :
Format d'échanges en mode texte. Son format à base de balises lui confère une grande souplesse. GML
et KML sont des spécifications dérivées adaptées aux échanges de données géographiques. Format
verbeux qui dans bien des cas peut être avantageusement remplacé par JSON (Javascript Object
Notation).

Définition:Flash :
Technologie propriétaire client-serveur d'Adobe utilisée pour produire des pages web interactives et
animées. L'environnement de développement Flash (Flex Builder) permet de concevoir et compiler des
objets interactifs s'intégrant dans une page web. Le résultat de la compilation est un fichier swf. Un
navigateur, équipé du plug-in Flash Player, est capable d'exécuter le fichier swf.
A noter également, l'existence du format KML (Keyhole Markup Language) utilisé initialement par
Google pour échanger des données avec les clients webs Google Maps et le client lourd Google Earth.
Ce format est devenu de fait un standard pour les échanges de données géographiques sur le web et
est désormais placé sous l'aile de l'OGC.
Seules les couches comportant peu d'objets ou bien les interactions du type requête peuvent être
rendues interactives par des échanges vectoriels. Les couches dites de référence (carte topographique,
photos aériennes) sont elles envoyées sous forme d'images tuilées ainsi qu'on l'a expliqué auparavant.
Le mécanisme AJAX est résumé dans le fichier PowerPoint animé et commenté suivant.

Vous devez cliquer sur l'astérix pour télécharger le powerpoint

15
La seconde génération de sites de webmapping
fonctionnent selon les principes du web 2.0.
L'utilisateur se connecte à une page web qui
n'est plus désormais vue comme un tout
indissociable mais comme un ensemble
d'objets dotés de capacités d'interaction
propres avec le serveur de la page web.
Les input de formulaires qui déclenchaient un
script chargé de recréer toute la page sont donc
désormais obsolètes.
La page web permet d'interagir avec les
données cartographiques à l'aide d'éléments
d'interfaces web 2.0 appelés controls. Ce sont
par exemple les outils classiques de navigation
(déplacement, zoom).
Chaque fois que l'utilisateur interagit avec la
carte à l'aide d'un control, ce dernier envoie une
requête HTTP en arrière plan à un script stocké
sur le serveur de la page. Le script est chargé de
fournir une réponse au control qui l'a
invoqué. La réponse attendue n'est plus
désormais une nouvelle page web, c'est-à-dire
un nouveau document HTML, mais un flux de
données géographiques.
Ce flux peut-être image (JPG, IMG) ou vecteur
(XML, GML, KML, GeoJSON,...)
Le traitement côté serveur nécessite toujours
l'utilisation des mêmes couches logicielles
(serveur carto, serveur de bases de données). Il
est possible aussi de fonctionner avec ou sans
cache de carte.
Après traitement, le serveur web renvoie au
control le flux de données.
S'il s'agit d'un flux image, le control remplace
l'ancienne image par la nouvelle.
S'il s'agit d'un flux vecteur, selon le format dans
lequel arrivent les données, il faut ou pas les
traduire sous forme de structures que le plug-in
sait traiter.
16
 Ici le plug-in utilisé est Javascript (ça pourrait
être Flash ou Sylverligt ou...).
Le plug-in traite ensuite l'information (dessin,
mise en forme dans un tableau de valeurs,...) et
rafraîchit l'affichage des éléments de la page
modifiés par le traitement.

1.6. Actualité des données

Un des avantages du SIG web pour l'utilisateur final c'est de ne pas se soucier de la gestion de la donnée
(stockage, mise à jour). Celle-ci est du ressort de l'administrateur du site qui met à jour périodiquement
les données.
Nous avons vu précédemment que la plupart des sites pré-calculaient les cartes à diffuser de façon a
accélérer les temps accès à l'information. La mise à jour de ces sites suppose donc que les caches soient
recalculés à chaque mise à jour. Cette opération étant très longue, elle doit être programmée à une
fréquence raisonnable (tous les 3 mois pour le Géoportail).
Pour les couches d'informations légères en revanche, il est tout à fait envisageable de mettre à jour les
données avec une fréquence beaucoup plus grande et même de mettre en place des applications web
quasi temps-réel.
Les technologies actuelles (communication téléphoniques ou Wifi) permettent en effet d'envoyer la
position géographique d'un objet (un véhicule, un navire, un animal, ...) en temps réel sur un serveur ;
ainsi qu'un certain nombre d'informations annexes également communiquées par des capteurs terrain
(identifiant de l'objet, nature, date et heure, vitesse, ...). Ces données sont reçues par le serveur,
qualifiées et archivées. Elles peuvent être stockées directement dans des formats vectoriels de type XML
ou JSON, prétraitées et converties en images, ou encore, et c'est le cas le plus fréquent, insérées dans
une base de données spatiales. Dans tous les cas, l'opération d'archivage étant très brève, elles peuvent,
en quasi temps réel, être diffusées vers des clients à l'aide des solutions vues précédemment.

Remarque:
C'est typiquement ce qui se passe ici avec cette application de suivi du trafic maritime mondial
(http://www.marinetraffic.com/ais/fr/default.aspx).

17
Remarque:
Ou encore avec le portail dédié au trafic routier en Ile de France (http://www.sytadin.fr/)

2. Webmapping orienté services

Introduction
Nous avons vu qu'une première vague de solutions webs, reposant sur les technologies client-serveur,
a permis de mettre à disposition des données à travers des sites autonomes.
Dans ce type d'architecture, chaque serveur stocke ses propres données et propose ses propres outils
SIG pour interagir avec elles. Une conséquence immédiate est qu'il n'y a pas de mutualisation
envisageable ce qui est dommageable à plusieurs titres :
• pas d'exploitation simultanée possible des informations données par deux sites différents
• redondance des données pour les couches communes à plusieurs sites
• redondance des développements.
Pour y remédier, les sites de webmapping ont évolué récemment vers des architectures orientées
services.

2.1. Principe des services web

Dans une application de webmapping orientée services, il y a toujours un client, le navigateur, qui
cherche à accéder à des ressources distantes par le biais d'un site web. La différence c'est qu'en fait il
n'y a pas UN serveur mais plusieurs serveurs : le serveur de la page web du site est lui-même client
d'autres serveurs.

18
 On dit que l'architecture est distribuée : de fait, le traitement des requêtes HTTP client est pris en
charge par plusieurs machines connectées au réseau. Chaque machine est invoquée pour fournir une
partie de l'information utile à la génération dynamique du document demandé par le client.
Dans une telle architecture, le serveur web n'est plus uniquement un programme capable de diffuser
une information directement visualisable dans un navigateur c'est aussi un programme chargé de fournir
des ressources exploitables par d'autres programmes.
Le propos d'un serveur de services n'est pas de donner accès à l'utilisateur final à une application métier
complète mais plutôt de fournir des traitements ou des données atomiques (calculer un itinéraire,
accéder à la couche orthophoto du RGE) à d'autres serveurs. Ces traitements atomiques sont
appelés services. Lorsque les services sont accessibles via le web on parle de services web.

Définition:Service web (1)

Une brique logicielle dotée d'une interface permettant l'interaction avec des composants situés sur
d'autres machines connectées au web. L'interaction se fait à l'aide soit d'URLs normalisées (REST, WMS,
WFS) soit par échanges de messages XML (SOAP).
Dès lors, sur le web, deux types de serveurs coexistent :
• les serveurs de pages web qui compilent et diffusent l'information à travers les pages HTML clas-
siques
• les serveurs de services qui alimentent les premiers.
A noter qu'un même serveur peut jouer les 2 rôles : c'est le cas du serveur cartorisque du Ministère de
l'Ecologie et de l'Aménagement et du Développement durable qui propose à la fois
• une application classique de webmapping
• des services utilisables par des serveurs tiers (comme le géoportail par exemple)

Ce concept de service invite à repenser le mode de développement des applications de webmapping.

Ce ne sont plus des applications aux fonctionnalités développées sur mesure ex. nihilo, mais plutôt des
assemblages sur mesure de composants déjà programmés.

19
Définition:Widget :
C'est un composant d'interface pré-programmé et disponible à l'emploi pour le développeur d'une
interface web. Cela étend considérablement les possibilités d'interaction natives du HTML. Un calendrier
est un exemple très courant de widget.
Avec deux avantages immédiats : la réutilisation des briques à volonté et le mariage de ressources
jusque là indépendantes. Nombreux sont les sites web qui diffusent des informations issues de serveurs
différents. Le Monde.fr communique par exemple des informations relatives à la météo du jour, au trafic
routier, au cours de la bourse qu'il obtient auprès d'autres serveurs.

Définition:Mashup :
Une application web qui diffuse des informations hébergées sur plusieurs serveurs.
La mise en place de services interopérables ne va néanmoins pas de soi : elle nécessite le respect de
normes. Le serveur de ressources (données ou traitements) doit donc veiller à les diffuser selon des
standards ou normes partagées.
Les deux modèles actuels permettant la publication de services web sont REST et SOAP. Les services
REST sont invocables par le biais d'une simple URL normalisée. La communication REST utilise donc
exclusivement HTTP, sans aucun ajout de couche logicielle. Les services SOAP nécessitent en revanche
des interfaces côté client et serveur pour émettre et interpréter des flux XML normalisés.

Définition:REST et SOAP :
Deux protocoles d'invocation de services web. REST est le plus utilisé pour sa simplicité de mise en
œuvre. REST consiste en l'exposition de chacun des services d'un même serveur par le biais d'une URL.
SOAP est plus complexe à mettre en œuvre, car il nécessite l'ajout d'une couche logicielle
supplémentaire côté client et côté serveur. Un service SOAP est invoqué par une requête POST
contenant un message XML.
Dans les deux cas, on peut dire que SOAP et REST jouent le rôle d'interfaces entre le client et le serveur,
en normalisant la ressource.

Définition:Service web (2) :

Composants logiciels auxquels on accède à distance à travers des interfaces normalisées REST ou SOAP.
La découverte et la réutilisation des services est grandement facilitée par la mise en œuvre
d'API, Application Programming Interface.

Définition:API :
C'est une interface de programmation, qui permet à un client d'accéder dans un environnement de
développement donné (Javascript ou Flex/Flash pour l'API Géoportail) à un ensemble de services fournis
par un même serveur.
Ces nouveaux outils intéressent au premier plan la géomatique. Ainsi que souligné précédemment, la
bonne gestion des territoires implique la prise en compte de multiples informations. Il faut bien sûr des
données de référence : cartes topographiques, photographies aériennes, modèles numériques de
terrain, parcelles cadastrales, adresses postales. Mais aussi, selon le type d'études à mener, des données
relatives aux risques environnementaux, des données socio-économiques sur les populations, des
données sur l'occupation des sols, sur la nature du sous-sol, ... Cette nouvelle logique de services permet
à chaque producteur de données de les diffuser de manière facilement réutilisable. Elle permet aussi de
rendre accessibles par un navigateur des traitements géographiques (changement de systèmes de
coordonnées, recherche sur critère spatial, calcul d'itinéraires, calcul de zones de chalandises, ...) qui
jusque là nécessitaient un SIG bureautique.
L'interopérabilité géographique a suscité et suscite encore de nombreux travaux. L'OGC a ainsi élaboré
toute une série de normes relatives à la façon de diffuser l'information géographique sous toutes ses
formes (vecteur, image, raster, traitement) par le biais du web.

20
 2.2. Les normes OGC
Afin de garantir l'interopérabilité des données et des traitements entre les différentes solutions SIG,
l'OGC a élaboré plusieurs protocoles d'échanges de données géographiques compatibles avec les
protocoles standards de services évoqués plus haut (REST, SOAP).

Définition:OGC :
Open GeoSpatial Consortium, association internationale fondée en 1994 dans le but de promouvoir
l'interopérabilité des Systèmes d'Information Géographiques.
L'intérêt de ces normes a été bien compris par les producteurs d'information géographique. Les
administrations et les collectivités notamment en matière d'environnement les utilisent de plus en plus
pour publier leurs données.

Exemple:
Avec CARMEN qui fédère pour le compte du Ministère de l'écologie et de l'environnement l'ensemble
des services fournis par chacune des entités placées sous sa tutelle (les Directions Régionales de
l'Environnement, les Agences de l'EAU, ...) :
http://carmen.ecologie.gouv.fr/spip.php?article78#resultat

2.2.1. WMS
Le protocole WMS (Web Map Service) permet à un client d'obtenir une carte créée à la demande par un
serveur à l'aide d'une url normalisée

Définition:WMS :
Service web de carte accessible par une url normalisée. Un serveur WMS doit répondre à 3 requêtes
types :
• GetCapabilities
• GetMap
• GetFeatureInfo
La requête GetCapabilities permet au client d'obtenir sous forme d'un fichier XML le détail des services
fournis par le serveur WMS. Cette information est nécessaire pour formuler correctement les requêtes
destinées à récupérer les données géographiques. Elle permet de connaître le nom des couches de
données, les systèmes de coordonnées dans lesquels on peut les obtenir, la sémantique disponible.
Ce qui suit est une requête adressée au serveur français geosignal. Vous pouvez constater que la
syntaxe est celle d'une url comportant l'adresse d'un programme et les paramètres à traiter par le
programme.
http://www.geosignal.org/cgi-bin/wmsmap?version=1.1.1&service=WMS&request=GetCapabilities
Le serveur renvoie le fichier XML suivant (extrait) :

21
La requête GetMap permet de récupérer une carte créée dynamiquement par le serveur WMS. Il est
nécessaire de spécifier un certain nombre de paramètres pour décrire la carte que l'on souhaite obtenir
ainsi que le montre la requête suivante :
http://www.geosignal.org/cgi-
bin/wmsmap?version=1.1.1&service=WMS&request=GetMap&SRS=EPSG:27582&BBOX=500000,2500
000,600000,2600000&WIDTH=600&HEIGHT=600&LAYERS=Autoroutes,Nationales,Departementales&
STYLES=&FORMAT=image/jpeg
qui permet d'obtenir l'image JPEG suivante cartographiant les réseaux d'autoroutes, nationales et
départementales sur un carré de 100 kms de côté dans le nord de la France :

22
 Dans l'exemple précédent, le client n'intervient pas sur le choix des symboles utilisés pour rédiger la
carte.
Il existe une norme, SLD (Styled Layer Descriptor) qui permet de décrire un ensemble de règles de
symbologie sous forme d'une ressource utilisable en paramètre de la requête WMS GetMap. SLD permet
donc au client de définir la facture graphique de la carte.
La requête GetFeatureInfo permet d'obtenir les informations attributaires portées par le (ou les)
objet(s) localisé(s) là où on a cliqué sur la carte. A noter que cette requête ne peut aboutir que pour les
couches renseignées comme queryable par la requête GetCapabilities.

Exemple:
L'exemple suivant montre comment récupérer la sémantique d'une autoroute qui passe par le centre de
notre carte (la carte mesure 600 pixels de côté et on clique sur le point de coordonnées 300, 300) :
http://www.geosignal.org/cgi-
bin/wmsmap?version=1.1.1&service=WMS&request=GetFeatureInfo&WIDTH=600&HEIGHT=600&srs
=EPSG:27582&BBOX=500000,2500000,600000,2600000&X=300&Y=300&QUERY_LAYERS=Autoroute
s&LAYERS=Autoroutes
Le serveur renvoie le fichier texte suivant :

23
2.2.2. WMS - C
Le solutions de mise en cache côté serveur pour accélérer le traitement des requêtes de cartographie
image dynamique ont été reprises sous forme d'une norme OGC : WMS Tile Caching ou WMS-C.
Le principe consiste à pré-calculer à différentes échelles une cartographie des données proposées et à
les tuiler en imagettes de taille réduite. Au final l'ensemble constitue une pyramide d'images à n niveaux,
chaque niveau contenant des tuiles (souvent de 256 pixels par 256 pixels).

Définition:WMS-C :
Service web de carte caché accessible par une url normalisée. Nécessite de calculer une pyramide
d'images multi-résolutions côté serveur. Un serveur WMS doit répondre à 3 requêtes types :
• GetCapabilities
• GetMap
• GetFeatureInfo
Pour obtenir une carte à la demande, comme précédemment le client va envoyer une requête getMap
au serveur WMS. Il suffit d'ajout le paramètre TILED = true et surtout de demander les données dans
une emprise géographique correspondant exactement à celle d'une dalle (éventuellement de plusieurs).

2.2.3. WFS
Le protocole WFS (Web Feature Service) permet à un client d'obtenir des entités géographiques vecteur
(géométrie et sémantique) non cartographiées au moyen d'une simple url normalisée.

Définition:WFS :
Service web vectoriel accessible par une url normalisée. Un serveur WFS doit répondre à 5 types de
requêtes :
• GetCapabilities
• DescribeFeatureType
• GetFeature
• LockFeature
• Transaction
Il existe dans les faits deux types de serveurs WFS :
• les serveurs basiques qui ne répondent qu'aux trois premières requêtes
• les serveurs transactionnels (WFS-T) qui les prennent toutes en charge.
Les premiers ne permettent au client que la consultation des données tandis que les seconds autorisent
les modifications.
Tout comme précédemment, la requête GetCapabilities permet d'accéder aux métadonnées du
service ainsi que le montre la requête suivante adressée au serveur cartorisque pour le département du
Tarn et Garonne
http://cartorisque.prim.net/wfs/82?service=wfs&version=1.1.0&request=getcapabilities

24
La requête DescribeFeatureType permet d'accéder à la structure (i.e. les champs) d'une couche
proposée par le service.
http://cartorisque.prim.net/wfs/82?service=wfs&version=1.1.0&REQUEST=describefeaturetype&TYPE
NAME=ATLAS_INONDATION_ZONE_INONDABLE

La requête GetFeature permet quant à elle d'obtenir sous forme d'un flux GML des entités
géographiques.
http://cartorisque.prim.net/wfs/82?service=wfs&version=1.1.0&REQUEST=GetFeature&TYPENAME=A
TLAS_INONDATION_ZONE_INONDABLE
La requête précédente renvoie au client un flux GML contenant toutes les entités de la couche
ATLAS_INONDATION_ZONE_INONDABLE pour le département 82.

Il est possible de restreindre la recherche en introduisant des critères sémantiques ou spatiaux.

Ici on ne s'intéresse qu'aux entités qualifiées de crue exceptionnelle pour le champ DEGRE :
http://cartorisque.prim.net/wfs/82?service=wfs&version=1.1.0&REQUEST=GetFeature&TYPENAME=A
TLAS_INONDATION_ZONE_INONDABLE&Filter=%3CFilter%3E%3CPropertyIsEqualTo%3E%3CProper
25
 tyName%3EDEGRE%3C/PropertyName%3E%3CLiteral%3Ecrue%20exceptionnelle%3C/Literal%3E%
3C/PropertyIsEqualTo%3E%3C/Filter%3E
Enfin, ici, on restreint spatialement la recherche dans une emprise rectangulaire de 10 kms de côté
renseignée dans le système EPSG 2154, c'est-à-dire en RGF93 / Lambert 93
http://cartorisque.prim.net/wfs/82?service=wfs&version=1.1.0&REQUEST=GetFeature&TYPENAME=A
TLAS_INONDATION_ZONE_INONDABLE&srs:EPSG:2154&BBOX=580000,6320000,%20590000,%2063
30000
Contrairement aux données images services en WFS, les données vectorielles doivent être traitées par
le client avant d'être affichées. Ce dernier doit les symboliser pour les dessiner à l'écran ; il doit lire la
sémantique pour l'afficher sous forme d'info-bulles par exemple.
On ne détaillera pas les deux autres requêtes mais il faut savoir que les serveurs WFS transactionnels
offrent de grandes possibilités : ils permettent à quiconque dispose d'une connexion internet et des
droits appropriés de mettre à jour à distance, éventuellement en situation de mobilité, des données
partagées. Cette technologie est utilisée par tous les portails collaboratifs, dont le plus connu d'entre
eux OpenStreetMap.

Définition:OpenStreetMap :
Projet web collaboratif mondial, visant à mettre à disposition de tous sans restriction d'utilisation une
cartographie de référence. La mise en œuvre repose sur les contributions volontaires de particuliers
numérisant les données à partir de photographies satellites ou bien communiquant leurs relevés GPS.
Le projet bénéficie également de l'apport de certains Etats ou entreprises.

2.2.4. WCS
Le protocole WCS (Web Coverage Service) permet à un client d'accéder à des données géographiques
de type grilles, c'est-à-dire à des données qui varient de manière continue dans l'espace géographique.
Il peut s'agir par exemple de modèles numériques de terrain, de données climatiques ou encore socio-
économiques. Il ne faut pas confondre ces données avec celles obtenues sous forme d'image par le
protocole WMS. Ce qu'on obtient en réponse ce n'est pas une image RVB mais bien une grille portant
la sémantique des données.

Définition:WCS :
Service de grilles. Un serveur WCS doit répondre aux 3 requêtes suivantes :
• GetCapabilities qui renvoie une description du service
26
 • DescribeCoverage qui renvoie une description complète pour chaque couverture
• GetCoverage qui renvoie une couverture dans différents formats

2.2.5 WPS
Le protocole WPS (Web Process Service) permet à un client d'exécuter un géotraitement, c'est-à-dire
un calcul de nature géographique, distant.

Définition:WPS :
Service de géotraitement. Permet d'exécuter un calcul géographique paramétré (entrée-sortie) distant
en invoquant un web service. Un serveur WPS doit répondre aux 3 requêtes suivantes :
• GetCapabilities
• DescribeProcess
• Execute
Le traitement en question peut être très simple (calculer la zone des 100m autour d'un point) ou très
complexe (simuler la propagation d'un feu de forêt à partir des conditions initiales de lieu et de vents).
Le protocole existe mais son utilisation reste encore confidentielle. D'ailleurs, les modèles complexes
exigent des temps de calcul qui ne sont pas compatibles avec la logique d'interaction des solutions
webs.

2.3. Les clients de services webs OGC

Les normes OGC précédemment décrites couvrent tous les types de données géographiques et la plupart
des usages. Elles permettent à tout programme capable d'accéder à une ressource distante par le biais
d'une url de consommer le service.
Il apparaît qu'aujourd'hui toutes les solutions SIG ont cette capacité, du moins pour ce qui concerne
WMS et WFS. C'est le cas notamment des clients bureautiques du commerce (suite ArcGIS, Mapinfo,
Géoconcept, ...) mais aussi des clients bureautiques libres (Jump, Quantum GIS, gvSIG, ...).
Ce qui ouvre des perspectives intéressantes, dans la mesure où pour réaliser une étude ou bien pour
créer une carte sur son poste bureautique il n'est plus désormais nécessaire de disposer en propre de
toutes les données.
Les serveurs cartographiques qui vont être décrits au chapitre suivant peuvent également être clients
de ces services.
Enfin, les développeurs de solutions de webmapping disposent aujourd'hui d'APIs clientes qui ont toutes
cette capacité. C'est le cas de l'API propriétaire Google Maps, mais aussi de l'API libre OpenLayers qui
permet d'invoquer tous les services OGC.

3. Les serveurs de publication des

services géographiques
Introduction
On trouve des solutions commerciales et des solutions libres. Force est de constater que les solutions
libres sont à la pointe en ce qui concerne l'interopérabilité.

27
3.1. Les serveurs commerciaux
3.1.1. ArcGIS Server
C'est le serveur SIG commercialisé par ESRI, société américaine leader sur le marché des solutions SIG.
C'est une solution complète permettant à la fois de publier des services géographiques mais aussi de
déployer des applications de webmapping.
ArcGIS Server a sa propre terminologie de services géographiques. Il permet de publier
• des map services, ou services de carte 2D. C'est la diffusion au format image d'un document mxd,
c'est-à-dire d'une carte créée avec ArcMap. C'est l'équivalent d'un service WMS (WMS-C)
• des globes services, ou services de carte 3D
• des geodata services, ou services de données. Equivalent à un service WFS.
• des image service. Equivalent à un service WCS.
• des geoprocessing services, ou services de géotraitement. Equivalent à un service WPS.
• des geocode services, ou services de géocodage. C'est la diffusion d'un géotraitement particulier :
le géocodage
• des geometry services. C'est la diffusion de géotraitements élémentaires tels le changement de
systèmes de coordonnées ou encore le calcul de buffer.
ArcGIS Server est indissociable d'ArcGIS bureautique qui permet de créer les ressources (bases de
données, cartes, modèles de géotraitement, méthode de géocodage, ...) qui sont publiées ensuite sous
forme de services. L'étape de publication est simplifiée autant que possible à travers des interfaces
utilisateurs. Les données doivent être stockées dans des formats lus nativement par la suite Esri
(shapefile, géodatabase ArcSDE, géotraitements ModelBuilder ou Python).
Les services qu'on publie avec ArcGIS Server sont avant tout destinés à être consommés dans des clients
ESRI : clients lourds type ArcGIS bureautique clients riches développés sur mesure avec les APIs client
(Javascript, Flash/Flex, Silverlight) ou encore clients légers développés avec les APIs serveur (Web ADF
Java ou Web ADF ASP.NET) mises à disposition.
Par défaut les services publiés sont des web services ; ArcGIS Server propose deux interfaces REST et
SOAP pour les consommer. Il est toutefois possible de supprimer l'accès à ces interfaces et ainsi de
restreindre leur utilisation à un intranet.
A condition d'autoriser l'accès web, certains services peuvent être rendus interopérables : c'est le cas
des map services qui peuvent être publiés en WMS ou encore des geodata services en WFS.
ArcGIS Server existe en environnement Windows, Linux ou encore Sun Solaris.
ESRI commercialise également des services consommables directement dans des clients ArcGIS Server
: c'est le produit ArcGIS online qui permet entre autres d'accéder à des fonds cartographiques ou images
de référence sur le monde entier. Certains services sont en accès libre.

3.1.2. MapGuide
C'est la solution SIG web conçue par AutoDesk. Le code source a été placé sous l'aile de l'OSGEO en
2006, si bien que MapGuide est aujourd'hui disponible sous forme d'une solution libre.

28
Définition:OSGEO :
Open Source GeoSpatial Foundation, organisation internationale dont le but est d'héberger et de
promouvoir les logiciels SIG Open Source.
Tout comme ArcGIS Server, il permet à la fois de publier des services géographiques mais aussi de
déployer des applications de webmapping.
Sa force principale c'est d'être capable d'exploiter la plupart des formats de données géographiques.
MapGuide est livré avec un client prêt à l'emploi (AJAX) permettant d'interagir de manière fluide avec le
serveur.
Le client peut être personnalisé ou bien redéveloppé à l'aide des APIs serveur (php, .Net, Java) et cliente
(Javascript) fournies.
MapGuide Server existe en environnement Windows ou Linux.

3.2. Les serveurs libres

Introduction
Nous en décrirons deux, MapServer et GéoServer, sur lesquels reposent de très nombreuses solutions
de webmapping.

3.2.1. MapServer
C'est le serveur de carte historique utilisé par les premières applications de webmapping. Il a d'abord
servi à produire des cartes à la demande au format image. Il a ensuite évolué pour permettre également
la publication de services web conformes aux normes OGC.
Le serveur est utilisable sous deux formes :
• une application CGI (Common Gateway Interface) exécutable à distance par le biais d'une url
• une API MapScript utilisable dans plusieurs environnements de développement serveur (PHP, Perl,
Python, Java,...).
Son rôle principal est de produire des cartes dynamiques à partir de données stockées dans différents
formats (shapefiles, tables Mapinfo, tables de SGBD spatial). Chaque service de carte utilise un fichier
texte, dit mapfile, décrivant le contenu.

Définition:Mapfile :
Texte structuré en blocs imbriqués. Tout mapfile contient au moins un bloc MAP décrivant les
paramètres généraux de la carte contenant lui-même tous les autres et notamment les blocs LAYER,
contenant les données à cartographier, mais aussi un bloc WEB indiquant où stocker sur le serveur les
images générées et un certain nombre d'autres blocs optionnels (PROJECTION, REFERENCE, LEGEND,
...).

29
Pour invoquer Mapserver en tant qu'application CGI, il suffit par exemple dans un navigateur de taper
l'url suivante :

Pour invoquer Mapserver à l'aide d'une API MapScript, par exemple PHP, on créera dynamiquement un
document HTML contenant la carte à l'aide d'un script PHP

Afin de créer une application de webmapping permettant un vrai dialogue utilisateur (choix des couches
de données par exemple) il convient de modifier dynamiquement (i.e. par le script PHP) le contenu du
mapfile.
Le rôle du serveur ne se limite pas à extraire des données et à les cartographier telles que. Il peut
notamment effectuer un changement de système de coordonnées.

30
 On constate que la reprojection à la volée nécessite d'ajouter des blocs PROJECTION.

Définition:EPSG :
Base de données mondiale recensant tous les systèmes de coordonnées utilisés pour localiser des objets
à la surface terrestre. Identifie chaque système par un numéro unique. Mécanisme d'identification repris
par tous les logiciels SIG Open Source.
• epsg : 4326 identifie le système de coordonnées géographiques utilisant le système géodésique
mondial WGS84
• epsg : 27572 identifie le systèmes de coordonnées métriques Lambert zone 2 associé au système
de référence NTF
• epsg : 2154 identifie le système métrique Lambert 93 associé au système de référence RGF93
• epsg : 900913 identifie le système métrique Web Mercator utilisé par exemple pour la diffusion des
fonds Google et OpenStreetMap.

Attention:
Selon la version des logiciels de Webmapping, ce système epsg : 900913 peut ne pas être connu. Ainsi
MapServer 2.3.1 pour Windows, qui utilise le programme libre proj4 pour la gestion des systèmes de
coordonnées, ne connaît pas epsg :900913. Il faut donc éditer le fichier epsg et ajouter à la main la
définition proj4 de ce système :
## spherical Mercator Google Maps
<900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0
+k=1.0 +units=m +nadgrids=@null +no_defs <>
MapServer est également capable d'exploiter de nombreuses sources de données (bases de données
spatiales ou services web OGC).
L'exemple suivant montre la connexion à une base de données PostGIS pour extraire des bâtiments que
l'on superpose aux limites départementales. On extraie ici tous les bâtiments stockés dans la table mais
31
on pourrait très bien n'en récupérer qu'une partie en ajoutant un critère de sélection à la requête SQL
du mapfile.

La publication de services webs OGC repose elle aussi sur le mapfile. MapServer implémente les normes
WMS, WFS et WCS.
Pour publier des données selon la norme WMS, il convient de respecter un certain nombre de règles :
• ajout d'un bloc PROJECTION dans le bloc MAP et dans chaque bloc LAYER
• ajout d'un bloc METADATA dans le bloc WEB et dans chaque bloc LAYER.

32
C'est l'exécutable CGI qui traite ensuite les requêtes WMS. Pour obtenir les métadonnées du service à
l'aide d'une requête getCapabiblities il suffit de reprendre l'url indiquée dans le bloc METADATA. Bien
sûr il existe des techniques permettant de masquer le chemin d'accès au mapfile.

Pour exécuter une requête getMap, on peut comme précédemment taper une url dans un navigateur
ou encore utiliser un client OGC ainsi qu'indiqué au chapitre précédent. C'est ce que nous faisons ici
avec le SIG libre Quantum GIS. Dans la barre d'outils principale, on peut établir une nouvelle connexion
WMS :

Enfin, en l'état du mapfile, le serveur WMS n'est pas encore prêt à répondre à une
requête GetFeatureInfo. Il faudrait ajouter des informations complémentaires.
Il est également possible de configurer MapServer en serveur WFS. Comme précédemment un certain
nombre de blocs et paramètres additionnels doivent être ajoutés.
33
MapServer est devenu au fil du temps un serveur cartographique complet capable de générer des flux
images (png, jpeg,..) ou vecteur (svg, flash) destinés à alimenter des clients de toute nature (web,
bureautique). Toutefois, il existe aujourd'hui d'autres solutions plus satisfaisantes que ce soit pour la
création du service à proprement parler ou encore plus spécifiquement pour la mise en oeuvre de
services transactionnels.

3.2.2. TileCache
C'est une implémentation open source de la norme WMS-C. Il s'agit d'un script Python exécuté en CGI
par le serveur web permettant de créer un cache disque associé à un serveur WMS.
Les couches d'informations servies par TileCache sont exploitables par l'API cliente OpenLayers.

3.2.3. GeoServer
GeoServer est l'alternative à MapServer. De conception plus récente, son ergonomie est meilleure ainsi
que sa compatibilité avec les standards récents (epsg : 90013 par exemple) ou encore avec les dernières
normes élaborées par l'OGC (WFS-T), à tel point que c'est le serveur de référence l'OGC pour les normes
WFS et WCS.
C'est la solution à retenir pour mettre en place des applications de webmapping permettant de modifier
les données.
C'est un logiciel libre écrit en langage Java. Il ne peut donc fonctionner que sur un serveur web équipé
d'un serveur d'application Java (ex : Tomcat pour Apache). Il existe en environnement Windows ou
Linux.
GeoServer structure les données en espaces de travail, entrepôts et couches. Les espaces de travail
regroupent des entrepôts de données, un entrepôt étant un ensemble de source de données de même
34
nature (vecteur ou raster). Une couche permet de définir la symbologie à appliquer à une source de
données d'un entrepôt. La définition des styles utilise le standard SLD.
Là où la configuration des services se fait dans un fichier texte pour MapServer, ici on dispose d'une
interface.

Les formats en sortie sont beaucoup plus nombreux que pour MapServer : flux KML, GeoJSON,
GEORSS,...
Une interface OpenLayers permettant de prévisualiser les données est également intégrée à l'interface.
Enfin, GeoServer permet de gérer la sécurité d'accès aux données et services à travers la création de
profils utilisateurs et l'attribution de droits.

3.2.4. Les frameworks de webmapping

Il en existe plusieurs, dont la plupart sous l'aile de l'OSGEO. Les plus utilisés en 2010 sont sans doute
CartoWeb et MapFish.
Ils permettent à la fois de publier des services mais surtout de créer les applications de webmapping
qui les consomment. Ce sont des alternatives à ArcGIS Serveur ou bien à MapGuide.
En ce qui concerne MapFish, c'est un outil de webmapping client - serveur reposant côté serveur sur un
environnement Python (Pylons) et côté client sur un environnement Javascript en intégrant notamment
l'API OpenLayers évoquée dans le chapitre suivant, mais aussi deux autres APIs Javascript utilisées en
webmapping pour créer et implémenter une interface Homme-Machine : extJS et GEOExt.
Il est conseillé d'utiliser un framework de ce type lorsqu'on se lance dans le développement d'une
solution webmapping libre de façon à bénéficier au maximum de composants déjà programmés (et bien
programmés !).

35
 Ces solutions sont toutefois assez volatiles. Il convient avant de se lancer de vérifier que la solution
choisie est une solution d'avenir.
Pour ce qui des solutions web propriétaires, elles aussi s'appuient sur des frameworks. C'est le cas de
l'API Javascript ArcGIS qui repose sur le framework Javascript Dojo. La logique est la même que pour
les solutions 100% libres : il s'agit d'utiliser des composants déjà développés et partagés par une large
communauté pour produire rapidement la mise en page et les fonctionnalités de son application web.
le framework donne accès à des widgets évolués (éléments de formulaires de saisie avec validation
intégrée, outils pour générer des tableaux personnalisables, des graphiques,..) qu'il s'agit simplement
d'agencer. Le framework permet aussi de bénéficier d'un code optimisé et exploitable par les différents
navigateurs.

4. Les API clients pour consommer les

services géographiques
4.1. API Google Map
C'est la plus connue, car pionnière, des APIs client. Mentionnons toutefois que Yahoo et Microsoft propose
le même type de services.

Actuellement en version 3, elle permet de créer des applications de webmapping personnalisées

consommant des services Google exécutables dans tout navigateur y compris sur des smartphones
(iPhone, Android, Windows Phone). Particuliers et professionnels l'utilisent. L'API est libre à condition
que le site développé soit en accès public et que les services offerts soit valorisés sur des fonds de carte
Google.
Depuis 2005, Google donne accès par le biais de Google Earth et du site Google Maps à une couverture
mondiale de données routières, physiques et photographiques avec une résolution excellente en
Amérique du Nord et en Europe, du moins pour ce qui concerne les grandes villes. L'utilisateur peut non
seulement visualiser la donnée mais aussi accéder à des traitements SIG comme la localisation par
adresse, la recherche de services à proximité d'un lieu, et bien sûr le calcul d'itinéraire.
L'API définit une interface de programmation permettant aux développeurs de solutions web de
bénéficier de tous ces services existants. De nombreux mashups Google sont ainsi apparus depuis 2006.
Le portail des transports de l'agglomération lyonnaise en est un exemple :

36
Exemple:

L'API regroupe un ensemble de classes Javascript (il existe aussi une version Flash et des versions pour
smartphones), qui permettent de créer des objets capables d'utiliser les services Google. Les données
sont localisées en coordonnées géographiques (latitude, longitude) dans le système WGS 84.
C'est un mode de développement très souple, puisqu'il ne nécessite aucune installation préalable. Tout
juste faut il indiquer l'URL de l'API dans la page HTML pour pouvoir bénéficier des fonctions déjà
programmées.
Conformément au style d'architecture AJAX, le client Javascript va être chargé de dialoguer avec le
serveur Google pour relayer sous forme de requêtes HTTP les interactions souris ou clavier de
l'utilisateur.
La facilité de mise en oeuvre tient au fait que les classes d'objets de l'API sont dotées des capacités
nécessaires à ce dialogue. Parmi elles, on trouve la classe centrale MAP qui est capable de réagir aux
évènements clic, double clic, changement d'échelle, déplacement,.... Mais aussi d'autres classes d'objets
comme Marker permettant de dessiner des objets ponctuels sur un objet Map, eux aussi capables de
réagir à des interactions utilisateurs (clic ou déplacement souris par exemple)
Au-delà de la visualisation des fonds Google et de la prise en charge de l'interaction avec ces fonds,
l'API propose de nombreuses fonctionnalités dont
• le dessin en superposition des fonds de carte Google de données géométriques ponctuelles (classe
Marker), linéaires (classe Polyline), surfaciques (classe Polygon)
• le chargement de couches de données servies par d'autres serveurs que Google
• la localisation d'adresses (classe Geocoder),
• le calcul d'itinéraires,
• l'accès à des vues obliques (Street View)
L'API est très bien documentée, on accède en ligne à la description exhaustive de toutes
les classes ainsi qu'à des tutoriels de prise en main.
37
http://code.google.com/intl/fr/apis/maps/documentation/javascript/reference.html
Pour afficher une carte Google dans une application de webmapping, il suffit de créer et stocker sur son
serveur un document HTML comportant les quelques lignes de code suivantes.

La partie body du document contient les 2 éléments de la page : le titre et la carte. La partie head
contient les directives de style, une référence vers l'API Javascript ainsi que le code Javascript fabriquant
la carte.
On constate que pour créer une carte dynamique Google, il faut une div, c'est-à-dire une division de la
page HTML, identifiée par une chaîne de caractères (ici « laCarte ») dans laquelle le code Javascript
affiche les données. Ce mécanisme d'identification des différents éléments d'une page est fondamental
pour AJAX puisqu'il permet d'atteindre chaque élément indépendamment des autres.
Pour utiliser l'API, il suffit d'ajouter à la partie HEAD <script
type="text/javascript"
src="http://maps.google.com/maps/api/js?sensor=false"></script>. Le paramètre sensor de
l'URL permet au client d'envoyer à Google sa géolocalisation. Ici, Google n'exploite pas la localisation
du client ; c'est utile lorsque le client est mobile.
La fabrication de la carte dynamique est prise en charge par la procédure initialize exécutée après
réception du document HTML. Il consiste à instantier un objet de type Map à l'aide de la classe
38
google.maps.Map de l'API. Pour créer un tel objet, l'API a besoin de certains renseignements : échelle
d'affichage sous forme d'un niveau de zoom (les données Google sont tuilées rappelez vous !), position
géographique du centre de la carte, type de carte (ROADMAP, HYBRID, TERRAIN et SATELLITE)
Ici le centrage est codé en dur. On pourrait autoriser l'utilisateur de notre application à saisir ces
coordonnées géographiques afin qu'elles soient utilisées par l'API pour le centrage. Ou même mieux, lui
laisser saisir un nom de lieu et demander à l'API de convertir cette adresse en coordonnées.

Le code est un peu plus complexe que précédemment. Il y a toujours une fonction Javascript Initialize
appelée après réception de la page par le client, mais aussi une autre fonction centreCarte. Au
chargement la carte est centrée sur Paris (France). Un control de saisie permet à l'utilisateur d''indiquer
un autre lieu et un bouton « Centrer la carte sur l'adresse » permet de centrer l'affichage sur le lieu
saisi. La fonction centreCarte est associée à l'évènement clic sur le bouton.
En plus d'un objet google.maps.Map on instancie également un géocodeur (google.maps.Geocoder) et
un marker figurant le nouveau centre de la carte (google.maps.Marker).
Pour ajouter en superposition des données archivées sur le serveur, il y aurait plusieurs possibilités mais
le plus simple serait d'ajouter une couche de type KML, l'API proposant de créer des objets de cette
nature. Rien n'impose toutefois d'archiver sur le serveur les données dans ce format. On peut imaginer
que le KML soit fabriqué de manière dynamique. C'est même assez simple à mettre en oeuvre si on a
39
pris soin de stocker ses données dans une base PostGis, ce dernier disposant de fonctions d'export
pouvant être invoquées en SQL.

4.2. API OpenLayers

Il s'agit également d'une API Javascript. Toutefois, à la différence de l'API Google elle est totalement
libre (diffusée par l'OSGEO). Par ailleurs elle permet d'accéder à toute la panoplie de services
géographiques existants aujourd'hui (commerciaux ou libres) et parmi eux les services OGC.
Cette API rencontre un très grand succès notamment pour toutes les applications institutionnelles. L'API
Géoportail en est une sur-couche.
Le mécanisme de développement d'une solution webmapping est identique au cas précédent, les
possibilités de mashup étant néanmoins plus nombreuses. Tout comme pour l'API Google Maps, l'API
propose plusieurs classes d'objets, parmi lesquelles la classe principale OpenLayers.Map et d'autres
dont OpenLayers.Layer.* permettant d'afficher dans la carte OpenLayers des données de nature
diverse.
L'exemple de code HTML suivant montre comment afficher dans un objet OpenLayers.Map les flux de
données OpenStreetMap et Google.

40
41
Comme précédemment, le code de création de la carte est déclenché après réception de la page HTML.
Il consiste à instantier un objet OpenLayers.Map en indiquant dans le constructeur de l'objet le système
de coordonnées (ici c'est EPSG 900913 ; on a choisi ce système, car ensuite on va ajouter les fonds de
carte Google et OpenStreetMap qui l'utilisent). On indique également l'emprise maximale de notre carte.
On constate qu'OpenLayers propose des classes d'objets pour définir une localisation géographique
(OpenLayers.LonLat) ou encore une emprise (OpenLayers.Bounds).

42
Attention:
OpenLayers distingue 2 types de couches, les couches de base et les overlays. Une seule
couche de base peut être active à la fois. Ici, les fonds Google et OpenStreetMap
apparaissent comme couches de base, tandis que les départements et les markers sont des
overlays.
L'API est documentée en ligne mais de manière beaucoup moins satisfaisante que l'API Google
http://openlayers.org et http://softlibre.free.fr/ol/htlm/index-fr.html

4.3. API Géoportail

C'est une API client dérivée d'OpenLayers existant en environnement Javascript ou Flash et permettant
d'accéder via des classes d'objets aux données du Géoportail ainsi qu'à certaines fonctionnalités de
traitement sur ces données. Son propos est avant tout de permettre la réutilisation dans des contextes
utilisateurs différents des données de référence du RGE®. Pour le reste l'API propose des fonctionnalités
comparables à celles vues précédemment : affichage de données géographiques, navigation dans les
données, superposition de données utilisateur formatées dans des formats fichier standards ou bien
servies par des serveurs OGC, dessin.
Le fait qu'elle dérive d'OpenLayers lui donne la capacité d'exploiter les flux WMS et WFS, et notamment
tous ceux diffusées par les collectivités Françaises (cf. projet Carmen).
L'API est en plein épanouissement avec en 2010 la mise en ligne d'une version pour l'iPhone.

Les quelques lignes de code suivantes montrent comment générer une carte de France avec toutes les
couches du Géoportail. Pour utiliser l'API, on la référence dans le code Javascript ; toutefois, il est
nécessaire de s'enregistrer au préalable afin d'obtenir une clé à inscrire ensuite dans le paramètre key de
l'url.

43
Exemple:

L'API est documentée en ligne :

https://api.ign.fr/geoportail/index.do

Conclusion
En 2010, les producteurs de données SIG deviennent de plus en plus des fournisseurs de services
interopérables tandis que les consommateurs, toujours plus nombreux, utilisent ces services par le biais
d'applications construites rapidement à partir d'APIs logicielles.
En l'espace de dix ans, le paysage logiciel des SIG a sensiblement changé : là où il n'y avait que des
solutions propriétaires sous licence (Esri, Mapinfo, Intergraph) il y a aujourd'hui aussi des solutions
libres, qu'utilisent tant les producteurs que les consommateurs. Là où il n'y avait que des utilisateurs
professionnels et des outils logiciels très sophistiqués et coûteux, il y a maintenant beaucoup de monde,
avec en première ligne le citoyen et le client lambda.
L'explosion annoncée du marché des smartphones doit permettre un nouvel essor des SIG. Ces
téléphones sont en effet capables de se connecter au web par le biais des réseaux téléphoniques ou du
44
 Wifi ; ils sont en outre dotés de moyens propres de localisation ce qui en fait autant de clients pour les
architectures distribuées évoquées dans ce cours. Avec eux, de nouveaux usages vont naître : réception
d'information exploitant la géolocalisation mais aussi remontée d'information vers des bases
centralisées. Une application iPhone permettant la notification de problèmes sur la voirie aux services
techniques municipaux a ainsi été montrée aux journées ESRI 2010. Tout citoyen devient producteur
d'information géographique.

Références sur le Web

Extrait de Alexandre PAUTHONNIER, 2010. Département De Cartographie ET D'Analyse de L'Informa-
tion Géographique, cours ENSG France.

Cours et Travaux Dirigés

http://www.geotests.net/cours/sigma/webmapping/ - Site de Laurent Jégou qui enseigne les technologies webs appli-
quées à la géomatique. Cours, documents de synthèse et TD en ligne.

Développement SIG
http://www.osgeo.org - Site web de la fondation géospatiale OpenSource. C'est le point d'entrée pour accéder aux diffé-
rentes solutions logicielles libres de la géomatique. On trouve à la fois des serveurs cartographiques, des APIs clients et
des SIG bureautiques.

Développement Web
http://www.w3.org/ - Site web officiel du World Wide Web Consortium, association chargée d'élaborer les standards du
web.

Développement Web
http://www.w3schools.com/ - Site satellite du W3C offrant de nombreuses ressources pour s'initier aux technologies du
web.

Développement Web
http://www.siteduzero.com/ - Des cours et des tutoriels pour apprendre tout seul. Un très bon tutoriel sur les services
webs.

Développement webmapping par API client

http://code.google.com/intl/fr/apis/maps/index.html - Le site dédié aux utilisateurs des APIs Google Maps.

Développement webmapping par API client

http://openlayers.org - Le site dédié aux utilisateurs de l'API OpenLayers.

Développement webmapping par API client

https://api.ign.fr/geoportail/index.do - Le site dédié aux utilisateurs de l'API Géoportail.

Interopérabilité des SIG

http://www.opengeospatial.org/ - Site web officiel de l'Open GeoSpatial Consortium, association internationale chargée
d'élaborer des normes visant à améliorer l'interopérabilité des solutions logicielles géomatiques.

Mise en place de serveurs géographiques

http://mapserver.org - Site satellite de l'OSGEO dédié au serveur Mapserver

Mise en place de serveurs géographiques

http://geoserver.org - Site satellite de l'OSGEO dédié au serveur Geoserver.

Sites d'échanges et de connaissances en géomatique

http://georezo.net - Des forums actifs en particulier sur le webmapping. Egalement un wiki collaboratif

45
 Sites d'échanges et de connaissances en géomatique
http://geotribu.net - Portail collaboratif sur les nouvelles technologies et la géomatique.

46