Etude exploratoire XML / SVG IDL_CERTU1/ETU_001 / 1.1 - Lara

Edité le 11 juin 2002 Etude exploratoire XML / SVG CERTU7.2 MISE EN ŒUVRE D’UN SERVEUR SPATIALCette étude a pour but d’étudier l’apport de XML et de SVG pour la publication de cartes sur le web. Ilexiste cependant d’autres technologies qui remplissent le même rôle. Il est donc intéressant de les comparer pourdéterminer lesquelles sont les plus adaptées.Dans nos deux maquettes, l’ensemble des données graphiques est transféré au client qui les afficheensuite en mode autonome. Il est possible cependant pour des gros volumes de données de stocker les donnéessur un serveur, avec une indexation spatiale, et de fournir au client uniquement les données qu’il souhaiteafficher. La mise à disposition des données spatiales dans une telle architecture peut se faire selon trois modes.7.2.1 Mode client / serveurL’accès aux données se fait au travers d’un outil SIG installé sur le poste client. Cette installation comprend lelogiciel fournit par l’éditeur, la couche client du SGBD et souvent une couche de liaison entre les deux.Par exemple :Oracle 8i + Spatial % Net 8 % MapInfo DBMS % MapInfoLa mise en place de cette solution correspond à une utilisation très différente de notre besoin. Son déploiementest lourd et son coût beaucoup plus élevé. Ces outils permettent alors d’utiliser des fonctions SIG complexesainsi que des fonctions d’éditions.7.2.2 Mode Intranet par imagetteCe mode de diffusion correspond plus à notre besoin : le client n’a besoin que d’un navigateur Web, qui afficheles imagettes (au format GIF ou JPEG) qui sont construites par le serveur à la demande. Cette solution est miseen œuvre sur beaucoup de sites Internet d’aide à l’itinéraire. Elle présente les caractéristiques suivantes :- aucune donnée vectorielle ne circule entre le client et le serveur,- elle ne nécessite pas la mise en œuvre d’applet ou de plug-in sur le client,- les actions de l’utilisateurs sont interprétées par du code JavaScript, et systématiquement envoyées auserveur qui les traite (sélection d’un objet, bulle d’information, déplacement, zoom…).Le niveau d’interactivité dans cette architecture dépend du réseau : toutes les modifications d’affichage sur lacarte nécessitent la génération d’une image et son téléchargement, opération qui peut être longue comme trèsrapide sur un réseau local. Des développements complémentaires peuvent alors « simuler » la manipulation dedonnées vectorielles et rendre l’application ergonomique. Cependant, ces développements complémentaires sontgénéralement plus lourds et plus complexes qu’avec la manipulation réelle de vecteurs.7.2.3 Mode Intranet par applet javaIl existe deux possibilités pour la mise en œuvre d’applet java : une applet fonctionnelle qui contient la logiqueapplicative, et une applet légère qui ne prend en charge que la visualisation.Note : L’utilisation des applet est parfaitement adaptée à la visualisation d’imagettes même si sa plus-value estmoins évidente que dans l’affichage de vecteurs. C’est donc cette dernière configuration que nous étudions ici.Cette solution est un mélange des deux solutions précédentes :- L’affichage s’appuie sur une applet,- le client est un navigateur Web,- les données échangées entre le client et le serveur sont vectorielles.L’affichage est pris en charge par une applet Java qui est téléchargé par le poste client à sa première utilisation.Cette applet est fournie par l’éditeur SIG et est capable d’interpréter un format de description de donnéesvectorielles propriétaire, généré à la demande par un serveur d’application.SWORD - Nos réf. : IDL_CERTU1/ETU_001 / 1.1 Diffusion : contrôlée Page : 75/81