Session générique

(1) format de l'image FORMAT

(1) taille de l'image WIDTH & HEIGHT

(1) transparence de l'image TRANSPARENT (1) couleur du fond de l'image BGCOLOR (5) coordonnées GetFeatureInfo X & Y (2, 3) limites de la carte BBOX (4) format de la légende (4) couche de la légende (5) format GetFeatureInfo (5) couche GetFeatureInfo (1) couches de la carte LAYERS (1) système de références spatiales SRS (4) requête GetLegendGraphic (5) requête GetFeatureInfo

FIGURE 4.29 – Édition des paramètres WMS

Lorsque la session est lancée, les actions de l’utilisateur émettent des requêtes vers le service. Les éditeurs sont à l’intérieur de fenêtres flottantes qui se trouvent dans l’onglet. Il y a cinq façons pour l’utilisateur d’émettre une requête (les numéros correspondent avec ceux de la figure 4.29) :

1 l’utilisateur modifie la valeur d’un paramètre. Une requête GetMap est émise automatiquement ; 2 l’utilisateur effectue un zoom en traçant un rectangle sur la carte. Une requête GetMap est émise ;

4.3. Client : BrowserWMS

3 l’utilisateur modifie le niveau de zoom : zoom avant, zoom arrière, pleine échelle. Cette action est effectuée à l’aide des boutons de la barre d’outils de la fenêtre Carte. Une requête GetMap est émise ;

4 l’utilisateur lance une requête GetLegendGraphic avec le bouton de la fenêtre Légende. La fenêtre permet de sélectionner le format et la couche de la légende ;

5 l’utilisateur lance une requête GetFeatureInfo. Cette action est réalisée à l’aide d’un clic droit sur la carte. Un bouton apparaît et permet d’émettre la requête. Comme pour la légende, l’utilisateur peut sélectionner le format et la couche.

Le diagramme 4.30 contient les classes mises en jeu lors de la modification du paramètre BGCO- LOR, qui correspond à la couleur du fond de la carte. Les classes spécialisées qui apparaissent sur ce diagramme (IFStyle, ColorEditor et RPColor) ont leur équivalent pour les autres types de paramètres.

FIGURE4.30 – Classes mises en jeu lors de l’édition d’un paramètre

La classe SessionView gère une liste de fenêtres flottantes (classe IFBase qui dérive elle même de la classe Java InternalFrame). Ces fenêtres peuvent être déplacées, agrandies, réduites, cela n’a pas d’influence sur les autres classes du diagramme.

Chaque fenêtre contient un ou plusieurs éditeurs de type (EditorBase). Chaque objet EditorBase gère un paramètre : il synchronise les actions de l’utilisateur (boutons, boîtes de sélection, etc.) avec ce paramètre. À chaque interaction, la valeur du paramètre est modifiée et la classe SessionController est notifiée avec la méthode setValue de ParameterView. EditorBase n’a aucune connaissance du type ou de la logique du paramètre qu’il édite, il n’a qu’une vue de ce paramètre : les classes Parame- terView et ParameterRequest. Ce qui est lié au type et aux composants graphiques est délégué aux spécialisations (RPColor et ColorEditor), ce qui est lié à la logique à la classe SessionModel.

SessionModel contient la liste des paramètres à proposer et les valeurs qu’il peuve prendre. Il sait aussi comment «rédiger» la requête HTTP correspondant à leur état.

Lorsque SessionController est notifié, il interroge le modèle métier (SessionModel et SessionCon- nexion) afin de lancer une nouvelle requête GetMap. Il synchronise la vue avec la nouvelle carte. Dans certains cas la nouvelle requête peut ne pas produire de carte (aucune couche n’est sélection- née), dans ce cas la fenêtre affichant la carte est vide (c’est d’ailleurs le cas au début de la session, aucune couche n’est sélectionnée par défaut).

Cinq paramètres, même s’ils utilisent le même mécanisme au niveau abstrait sont un peu particuliers : – SRS et LAYERS sont liés : les couches ne sont pas toutes disponibles pour tous les systèmes de référence. Lorsque l’utilisateur modifie la valeur de SRS, les couches qui ne sont plus disponibles sont désactivées ;

– WIDTH et HEIGHT, qui donnent la taille de l’image sont édités simultanément à l’aide d’un cur- seur, afin d’assurer que l’échelle verticale et l’échelle horizontale coïncident. Les calculs sont ef- fectués à l’aide de la classe BBox ;

– le paramètre BBOX a pour valeur par défaut sa valeur maximale (union des BBOX spécifiées dans le fichier Capabilities). Ce paramètre est modifié lorsque l’utilisateur effectue un zoom. Là encore, ce sont les méthodes de la classe BBox qui permettent d’assurer la cohérence entre la résolution21

de l’image, et celle du territoire observé. À partir du rectangle que l’utilisateur dessine sur la carte lorsqu’il zoome, on calcule si la zone correspondant à sa sélection doit être étendue en hauteur ou en largeur. Ensuite, on centre par rapport à la sélection, ainsi l’intention de l’utilisateur est respectée. La figure 4.31 illustre ce mécanisme.

1. CONSERVATION DE

LA RÉSOLUTION

2. CENTRAGE DE

LA SÉLECTION

FIGURE4.31 – Modification du paramètre BBOX avec le zoom

Les deux autres requêtes, GetLegendGraphic et GetFeatureInfo sont lancées à l’initiative de l’uti- lisateur en appuyant sur un bouton pour la légende, en sélectionnant un point depuis la carte (voir figure 4.29). À chacune de ces requêtes, une nouvelle fenêtre flottante est affichée avec le contenu

4.3. Client : BrowserWMS

de la réponse. Ces fenêtres ne sont pas des éditeurs, et contrairement aux éditeurs elles peuvent être fermées (définitivement) si le contenu ne satisfait pas l’utilisateur, ou après avoir ajouté ce contenu au panier. La fenêtre de la carte a aussi cette fonctionnalité. La figure 4.32 montre comment l’utilisateur peut interagir avec le panier depuis la session.

ajouter au panier ouvrir le

panier

FIGURE4.32 – Interactions entre la session et le panier

L’utilisateur peut, à tout instant, fermer sa session, en lancer une autre, ou passer au dernier cas d’utilisation, l’édition.