SVG : de la publication de cartes à l'élaboration d'un serveur cartographique

Frédéric BARNAY

Courriel : frederic.barnay@geo2i.com

Gaëtan GABORIT

Courriel : gaboritg@ddrn.asso.fr

Résumé :

Le SVG permet la publication de cartes sur le web, dotées de fonctions interactives de base. Il peut également occuper une place centrale dans l'élaboration d'un véritable serveur cartographique, économique et performant. Utilisateurs et administrateurs disposent alors d'un outil de consultation et de création autonome.

Nous verrons ainsi que les documents SVG peuvent être rendus interactifs au moyen de gestionnaires d’évènement déclenchant des scripts côté client, ce qui autorise la création de fonctions élaborées (ex. saisie avec accroche). Le recours à une architecture client-serveur comprenant une base de données permet de retrouver les principales caractéristiques d’un SIG traditionnel. L’optimisation des échanges client-serveur est alors facilitée par un mécanisme d’ajout dynamique de nouveaux objets graphiques. Il est également possible d'utiliser le caractère extensible du SVG pour paramétrer l'ensemble.

Cette présentation s'appuie sur des exemples concrets, tirés d'applications en exploitation au sein de collectivités.

Mot-clés : Scalable Vector Graphic (SVG), XML, Système d’Information Géographique (SIG), webmapping, serveur cartographique.

Introduction

Le SVG (Scalable Vector Graphic) est une application du XML dédiée à la représentation d’informations graphiques en deux dimensions. Un document SVG peut ainsi associer des éléments vectoriels, du texte, des images bitmap. Si à l’origine le SVG n’était pas spécialement destiné à la cartographie en ligne, c’est néanmoins dans ce domaine qu’ont été élaborées les applications les plus abouties à ce jour.

En passant en revue les différentes étapes de nos travaux dans ce domaine, il nous est apparu qu’elles correspondaient assez précisément aux différentes caractéristiques du SVG, qui combinées entre elles, en font un «langage» bien adapté aux besoins et à la culture des géomaticiens.

Reprise en SVG de cartes existantes

Le SVG est un format texte, il est donc assez facile à générer avec n’importe quel programme manipulant des chaînes de texte, à partir d’un autre fichier texte comme le MIF de Mapinfo®. Une petite difficulté réside dans l’inversion de l’axe Y par rapport aux systèmes de coordonnées usuels. Bien qu’elle réclame quelques efforts, cette méthode est cependant préférable à l’exportation directe à partir d’un logiciel comme Adobe Illustrator®, qui ne conserve pas le système de coordonnées d’origine et produit un SVG touffu, difficilement manipulable par la suite. Se confronter ainsi dès le départ aux subtilités du format SVG permet d’aborder très rapidement des problèmes tels que l’optimisation de la taille du fichier (au moyen de l’utilisation des coordonnées relatives), la représentation des objets à trous, l’application d'un style à des groupes d’objets.

Manipulation des objets, gestion des évènements et interactivité

Le DOM (Document Object Modele ou modèle objet de document) est une spécification du W3C définissant la structure d'un document sous forme d'une hiérarchie d'objets, afin de simplifier l'accès aux éléments constitutifs du document. Il s’agit plus exactement d’un langage normalisé d'interface (API, Application Programming Interface), indépendant de toute plate-forme et de tout langage, permettant à une application de parcourir la structure du document et d'agir dynamiquement sur celui-ci. Ainsi Javascript et ECMAScript utilisent le DOM pour naviguer au sein d’un document SVG, récupérer des informations sur les objets, en modifier d’autres, et même créer de nouveaux objets. Ces actions sont déclenchées par des évènements liés en particulier au pointeur de la souris : onclick, onmouseover, onmouseout, onmousemove, etc. Deux informations capitales peuvent également être connues lors d’un évènement : la position du pointeur dans le système de coordonnées du document SVG et l’identifiant de l’objet sur lequel a lieu l’événement.

On dispose alors de tous les ingrédients nécessaires pour rendre un document SVG interactif. Dans le domaine de la cartographie il est ainsi possible de développer le jeu de fonctions traditionnelles telles que zoom, panoramique, affichage/masquage de couche, ouverture d’une pop-up contenant les attributs de l’objet cliqué et centrage de la carte sur celui-ci… Il est également possible de développer des fonctions plus complexes, actuellement utilisées dans des applications destinées à la gestion de réseaux, de voiries, d'espaces verts.

La création d’éléments avec accroche sur des éléments existants

Le principe est le suivant : il s’agit de saisir de nouveaux objets en s’appuyant sur des objets existants. Au préalable, une fonction va dupliquer ces objets en les décomposant : polylignes et polygones vont ainsi être reproduits sous forme de lignes simples et de cercles (pour les sommets).

A ces lignes et ces cercles sont alors affectés :

des évènements (survol, sortie de survol et clic) liés au pointeur de la souris de l’utilisateur,
une largeur correspondante à la distance paramétrée de l’accroche,
un style transparent (invisible) permettant de laisser croire à l’utilisateur que l’accroche se déclenche à distance de l’objet support.

Lors du survol d’une ligne transparente, les coordonnées du pointeur sont récupérées par les fonctions getClientX et getClientY. Une projection orthogonale permet alors de calculer les coordonnées précises du point le plus proche du pointeur appartenant à la ligne. Pour les cercles représentant les sommets, il suffit de récupérer les coordonnées du centre. Ces coordonnées servent à l’affichage d’un cercle et lorsque l’utilisateur clique sur celui-ci, elles sont utilisées pour créer/modifier le nouvel objet.

Exemple 1 : saisie d’un symbole avec accroche sur une polyligne

L’objet violet représente selon les explications ci-dessus la ligne invisible réagissant au pointeur de l’utilisateur. Sur cette copie d’écran, la fonction d’accroche n’est pas activée car le pointeur ne survole pas la ligne.

Le pointeur de l’utilisateur survole la ligne invisible : un cercle de couleur apparaît, son centre correspond aux coordonnées calculées par la projection orthogonale. Il signale à l’utilisateur que l’accroche est activée.

L’utilisateur vient de cliquer sur le cercle rouge, un symbole est alors créé très précisément sur le tronçon.

Exemple 2 : saisie d’un polygone avec accroche sur un autre polygone

Les objets violets représentent les lignes et cercles invisibles réagissant au pointeur de l’utilisateur. Sur cette copie d’écran, la fonction d’accroche n’est pas activée car le pointeur ne survole aucun de ces objets.

Lorsque le pointeur de l’utilisateur survole un cercle associé à un sommet, un cercle de couleur bleu apparaît.

Lorsque le pointeur de l’utilisateur survole un objet invisible ligne, un cercle de couleur rouge apparaît aux coordonnées calculées par la projection orthogonale. Il signale à l’utilisateur que l’accroche peut s’effectuer sur la ligne.

Grâce à la fonction d’accroche, le polygone ainsi créé est accolé de manière très précise avec celui ou ceux qui ont servi à sa construction.

Création et modification de réseaux topologiques.

Un réseau topologique est un graphe constitué d’arcs et de nœuds, représenté en SVG par des lignes et des symboles. L’intérêt d’un réseau topologique est de connaître l’enchaînement des différents arcs afin de parcourir le graphe et d’effectuer différents calculs : plus court chemin entre deux nœuds, calcul d’exutoire, de bassin versant…

Lors de la saisie, si le point de départ d’un nouvel arc est saisi sur un nœud existant, les coordonnées de ce dernier sont alors utilisées pour la création du nouvel élément. Chaque arc possède également deux attributs importants : l’identifiant du nœud amont et l’identifiant du nœud aval (nous examinerons plus loin l’ajout de nouveaux attributs aux éléments SVG).

Outre la création d’éléments, la gestion d’un réseau topologique nécessite d’autres fonctions comme le déplacement d’un nœud commun à plusieurs arcs. Le déplacement dynamique d’un symbole représentant un nœud, rendu possible par la modification de ses coordonnées en récupérant celles du pointeur, doit s’accompagner de la modification des arcs qui ont ce nœud comme nœud amont ou aval. Au début du déplacement du symbole du nœud, il convient donc de parcourir l’arbre des lignes représentant les arcs du réseau, et de stocker dans un tableau javascript les identifiants des lignes liées à ce nœud. Le déplacement simultané du symbole et de ces lignes est alors simple, et le rendu à l’écran particulièrement fluide.

Exemple 3 : déplacement d’un nœud dans un réseau topologique

L’utilisateur réalise un « cliquer – déplacer » sur un nœud du réseau, tous les éléments attachés à ce nœud vont suivre le déplacement en temps réel. Ce travail est effectué sur le poste client.

L’utilisateur finit le déplacement de l’objet en relâchant le bouton de la souris. Le réseau est mis à jour.

Ces créations et modifications d’éléments s’effectuent sur le poste client. L’enregistrement en local d’un fichier SVG ainsi modifié est certes possible mais ne présente que peu d’intérêt. Par contre en s’appuyant sur une architecture client-serveur, il est possible de tirer pleinement profit des fonctionnalités qui viennent d’être décrites et d’élaborer des applications riches et performantes.

Développement d’applications client-serveur

Les échanges client-serveur

Sur le web, en mode de fonctionnement standard, une requête envoyée au serveur aboutit au chargement d’un nouveau document. Dans le domaine de la cartographie en ligne, cette technique n’est évidemment pas optimale : l’ajout d’une nouvelle couche nécessite le chargement d’un nouveau document comprenant toutes les couches déjà affichées, complétées par la nouvelle. L’idéal serait de pouvoir charger les éléments de la nouvelle couche et de les ajouter au document en cours. Précédant les nouvelles recommandations du W3C, Adobe® a implémenté les fonctions correspondantes dans la version 3 de son visualisateur SVG. Les méthodes GetURL et PostURL permettent d’envoyer une requête au serveur et d’en récupérer le résultat, sous forme d’une chaîne de texte. Si cette chaîne est elle-même du SVG, l’objet graphique correspondant peut directement être ajouté au document en cours grâce à la méthode ParseXML.

Le stockage des éléments graphiques dans une base de données

Côté serveur, il faut alors disposer d’outils permettant de sélectionner et de trier rapidement les objets graphiques à renvoyer au client. Le recours à un SGBDR s’impose alors, couplé à un langage de script serveur pour effectuer tous les traitements souhaitables (ex. MySQL et PHP). Il est dès lors possible de s’affranchir du format SVG en terme de stockage, pour lui préférer par exemple le WKT de l’OpenGIS, utilisé par des programmes dotés de fonctions spatiales (intersections, union, modification du système de projection, etc.). A terme, il s’agit également de pouvoir alimenter avec une même base de données des clients divers : SVG, Macromedia Flash®,…

Dans les exemples de création/modification d’objets étudiés précédemment, il sera ainsi possible de renvoyer au serveur la définition de ces objets, et de modifier ou de créer de nouveaux enregistrements dans la base de données.

La généralisation du chargement dynamique par l’ajout de nouveaux attributs aux éléments SVG

Une fois maîtrisées ces différentes techniques, l’étape suivante consiste à réduire les fichiers SVG de l’application à de simples squelettes génériques, auxquels on ajoutera tous les éléments nécessaires à la volée, côté client. La question se pose alors du mode de gestion des paramètres nécessaires à la réalisation d’une carte spécifique. Le caractère extensible du SVG offre ici une solution intéressante en autorisant l’ajout d’attributs aux éléments SVG, en plus de ceux définis dans la DTD.

Voici un exemple d’attributs supplémentaires déclarés dans l'entête du fichier svg

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN"

"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd" [

<!ATTLIST g

table CDATA #IMPLIED

champid CDATA #IMPLIED

clausew CDATA #IMPLIED

displaymin CDATA #IMPLIED

displaymax CDATA #IMPLIED

corstrokewidth CDATA #IMPLIED

corfontsize CDATA #IMPLIED

lib CDATA #IMPLIED

menulib CDATA #IMPLIED

depaffich CDATA #IMPLIED

corsymb CDATA #IMPLIED

ib1 CDATA #IMPLIED

ib2 CDATA #IMPLIED

Passons maintenant en revue les paramètres qui correspondent à ces attributs :

table : nom de la table contenant les éléments à ajouter dans cette couche
champid : champ de table servant à la construction de l’id des éléments à ajouter. Cet id aura la forme table-valeur id.
clausew : clause SQL permettant de sélectionner des enregistrement dans la table.
displaymin : seuil minimal de visibilité de la couche.
displaymax : seuil maximal de visibilité de la couche.
corstrokewidth : attribut permettant une correction automatique de l’épaisseur des contours selon le niveau de zoom. La formule de calcul de l'épaisseur des contours est la suivante : (largeur de l'emprise courante/corstrokewidth)^0,7.
corfontsize : attribut permettant une correction automatique de la taille des caractères selon le niveau de zoom. La formule de calcul de la taille des caractères est la suivante : (largeur de l'emprise courante/corfontsize)^0,7.
lib : cet attribut est utilisé de deux manières différentes. Si sa valeur commence par symb, la représentation sera un symbole. Dans le cas contraire il s’agit du champ de table dont le contenu s'affichera dans la carte sous forme de texte.
menulib : cet attribut entraînera la création d’une ligne dans le menu de gestion des couches
depaffich : par défaut la valeur est true. S'il est à false, la couche n'est pas chargée à l'initialisation et la case correspondante dans le menu n'est pas cochée.
corsymb : attribut permettant une correction automatique de la taille des symboles selon le niveau de zoom. La formule de calcul du facteur d'échelle appliquée aux symbole est la suivante : (largeur de l'emprise courante/(100*corsymb))^0,95. A noter que cette correction est appliquée à la définition des symboles, non aux symboles instanciés eux-mêmes.
ib1 : champ de table alimentant la ligne 1 de l’infobulle.
ib2 : champ de table alimentant la ligne 2 de l’infobulle.

Voici un extrait d’un fichier SVG avec des éléments comportant de tels attributs :

</g>

La couche OCS est affichée jusqu’à ce que l’emprise de la carte atteigne 200 000 mètres de large. Une ligne correspondante sera affichée dans le menu de gestion des couches. Cette couche est composée de différentes sous-couches : la première est une version généralisée d'une des sous-couche suivante et s’affiche lorsque l’emprise est comprise entre 30 000 et 200 000 mètres. A plus grande échelle, cette première sous-couche disparaît et les autres sous-couches s’affichent : elles comportent des éléments issus de la table ocs, sélectionnés selon Les différentes valeurs du champ nature.

Lors du chargement du fichier, les attributs des différentes couches sont stockés dans le tableau javascript layerArr. Ce tableau est parcouru une première fois pour générer le menu de gestion des couches.

On déclenche ensuite la fonction layerLoad qui récupère tout d’abord les coordonnées de la viewbox de la carte principale, afin de ne charger que les éléments qui intersectent avec la viewbox. Elle parcourt ensuite chaque élément du tableau layerArr et en fonction des différents paramètres associés à une couche, envoie éventuellement une requête au serveur qui retourne alors un fragment SVG, lequel est parsé (analysé) puis ajouté au document SVG. Cette fonction est lancée à l’initialisation de la carte, mais également à chaque modification de l'emprise affichée (suite à un panoramique ou un zoom), et à chaque action sur les cases à cocher de la liste des couches.

Côté serveur, une table stocke l’identifiant des éléments chargés par chaque utilisateur, ce qui évite de recharger un élément déjà présent dans le document SVG.

Dans la version complète de l’application, ce système est appliqué à la carte principale comme à la vue de contrôle. Les fragments SVG qui paramètrent l’ensemble sont eux-mêmes stockés dans une table, et chargés à la volée dans un squelette SVG très réduit. Bien que le serveur soit fortement sollicité, cette solution est opérationnelle avec un nombre important d’utilisateurs simultanés. Sur le poste client, une session de navigation avec de multiples zooms et panoramiques entraîne le chargement de plusieurs milliers d'éléments. Sur un PC de bureau standard (Pentium IV 2Ghz, 256 Mo de RAM, IE5, ASV3), nous avons testé le chargement de plus de 50 000 objets durant la même session. Dans ce cas l'espace mémoire utilisé par le processus sur le poste client devient très important (> 60 Mo). Par ailleurs, un problème peut survenir lors de l'affichage simultané d'environ 10 000 objets, avec l'utilisation de l'infobulle. Il semble que le rafraîchissement ne puisse être appliqué à un si grand nombre éléments. On observe alors la disparition sur les zones couvertes par l'infobulle, des caractéristiques d'épaisseur des contours des tracés. Il convient de noter que ce problème survient uniquement lorsque l'anti-aliasing est activé.

Conclusion

Les techniques abordées ici démontrent les capacités du SVG pour le développement de solutions cartographiques en ligne évoluées et performantes. Plusieurs structures publiques et privées les utilisent aujourd’hui, dans des applications liées à la gestion de territoires et d'équipements.

Bibliographie

CHANG Yi-Hong & CHUANG Tyng-Ruey, 2003, Embedding Domain Semantics in SVG, in

SVG Open / Carto.net Developers Conference,Vancouver, Canada, juillet 2003. Disponible à www.svgopen.org/2003/papers/embeddingDomainSemanticsInSVG.

NEUMANN Andreas & WINTER Andréas, 2000-2003, La cartographie en mode vectoriel sur le Web : les possibilités de SVG, in carto.net, disponible à www.carto.net/papers/svg/index_f.shtml

WATT Andrew et alter, 2002, SVG Unleashed, Sams Publishing, Indianapolis, 1117 pages.