Configuration du Format des Pyramides Produites

Dans cette partie, nous détaillons uniquement la configuration de l’arborescence de dossiers et du

170 Marion Dumont fichier XML nécessaires à la visualisation de nos pyramides dans ZVTM. Il nous semble important de développer ici ces aspects techniques, car ils conditionnent l’utilisation de nos pyramides et donc la faisabilité de nos hypothèses d’amélioration. Nous détaillerons ensuite la modélisation de l’ensemble de l’interface et de notre test utilisateurs dans le Chapitre E.

Tout comme OpenLayers ou Leaflet, ZVTM peut lire les différentes tuiles de nos pyramides à partir d’une arborescence de dossiers spécifique, illustrée par la Figure 123. A la racine de cette arborescence, on retrouve le fichier de configuration scene.xml dont nous expliquons la structure dans la suite de ce paragraphe. Le premier niveau de l’arborescence correspond au level c’est-à-dire à un niveau spécifique de la pyramide, de 4 pour la carte au 1 : 25k à 0 pour la carte existante au 1 : 100k. Ensuite pour chaque niveau, les tuiles sont ordonnées en fonction de leur position dans la grille de tuilage, en commençant en bas à gauche par la tuile 0-0. Le deuxième niveau de l’arborescence correspond ainsi à la colonne de la grille de tuilage, puis on retrouve chaque tuile au format image, nommée selon l’identifiant de la ligne de la grille de tuilage sur laquelle elle est affichée. Dans l’exemple de la Figure 123, on obtient ainsi pour le niveau 0, c’est-à-dire la carte existante au 1 : 100k, 9 dossiers correspondant aux colonnes et 5 images correspondant aux lignes.

Figure 123. Arborescence de dossiers attendue par ZVTM pour les pyramides raster tuilées.

Le fichier scene.xml nous permet ensuite de configurer les intervalles d’échelles d’affichage de chaque niveau et les coordonnées de chaque tuile dans l’interface de visualisation. En pratique, tous les éléments graphiques affichés par ZVTM sont en effet définis dans un espace plan infini, observé par une caméra dont l’altitude par rapport à ce plan peut varier. L’utilisateur verra ainsi sur son écran ce que cette caméra voit de l’espace virtuel en fonction de sa position (x, y) dans un repère orthonormé, et de son altitude selon un axe vertical. Plus la caméra monte en altitude, plus les objets définis dans l’espace virtuel seront affichés petits. L’échelle d’affichage dans ZVTM est donc gérée par l’altitude de cette caméra, définie à partir de l’altitude 0 où se trouve l’espace virtuel.

Pour que les différents niveaux de nos pyramides apparaissent correctement dans ce système de visualisation, il faut qu’ils occupent la même emprise dans l’espace virtuel. Cependant, leur taille réelle est différente (en pixels), puisque le nombre de tuiles dans chaque niveau est différent. Moins les niveaux sont détaillés plus nous devrons agrandir la taille de leur tuile dans l’espace virtuel ZVTM, comme le montre la Figure 124. Nous devons donc maintenant définir les coordonnées de chaque tuile de chaque niveau dans l’espace virtuel, de manière à ce qu’elles apparaissent au bon endroit et

Juin 2018 171 à la bonne taille. Pour clarifier notre propos, nous parlons dans cette partie d’unité de l’espace virtuel (UEV) pour désigner une distance dans le repère orthonormé de l’espace virtuel ZVTM.

Figure 124. Illustration de la nécessité d’agrandir la taille des tuiles dans l’espace virtuel ZVTM en fonction du niveau de la pyramide, pour occuper une même emprise à l’écran.

Pour calculer les coordonnées des tuiles dans l’espace virtuel, nous avons pris comme référence la carte existante au 1 : 25k, qui sera notre premier niveau. Ses tuiles seront donc affichées avec une taille de 256*256 UEV dans notre interface de test. L’emprise occupée par la carte dans l’espace virtuel est donc de 256*36 UEV en largeur et 256*20 UEV en hauteurs, car le niveau 4 (carte au 1 : 25k) comprend 36*20 tuiles. Chacune des représentations de la pyramide doit occuper cette même emprise. Pour chaque niveau, nous avons donc divisé cette emprise par leur nombre de tuiles correspondant, pour définir la taille d’une de ses tuiles à l’écran, donnée dans le Tableau 4.

Niveau 4 3 2 1 0

Taille de tuile 256*256 UEV 341*341 UEV 512*512 UEV 731*731 UEV 1024*1024 UEV

Tableau 4. Taille des tuiles dans l’espace virtuel ZVTM en fonction de leur niveau d’affichage.

Comme on pouvait malheureusement s’y attendre, nous tombons ici sur l’une des limites de notre approche. Ce calcul ne donne pas un nombre de pixels entiers pour les niveaux 3 et 1 qui sortent du quadtree. Nous devons donc arrondir à l’entier supérieur, créant des décalages d’affichage entre les différents niveaux de la pyramide. Par manque de temps, nous avons choisi ici de ne pas revenir en arrière sur notre configuration. Si ces problèmes d’affichage sont susceptibles de perturber nos utilisateurs au premier abord, nous espérons qu’une phase d’entrainement permettra de dépasser ce biais. Il est clair qu’en dehors de notre cadre expérimental, il faudra trouver une autre solution pour afficher des représentations intermédiaires dans un système de visualisation multi-échelle. Sur cette plage d’échelle, il serait sans doute possible d’utiliser une évolution standard de la taille des tuiles pour nos cinq niveaux (256, 512, 1024, 2048, 4096) en adaptant seulement leur échelle d’affichage. Cependant, cette pratique diminuerait rapidement la résolution des tuiles et risquerait de poser des problèmes de lisibilité à petite échelle (contenu pixellisé).

En ce qui concerne leurs coordonnées, nous choisissons de placer les tuiles dans l’espace virtuel à partir de l’origine du repère. Dans l’exemple de la Figure 125, représentant le tuilage du niveau 2, la

172 Marion Dumont tuile noire est ainsi positionnée par rapport à son centroïde. Il suffit alors de multiplier les indices de sa position (7 ; 4) par la taille des tuiles à ce niveau (512*512 UEV), puis d’ajouter la moitié de la taille d’une tuile pour trouver les coordonnées du centroïde.

Figure 125. Illustration de la méthode de calcul des coordonnées du centroïde de la tuile en noir : on multiplie les indices de colonne-ligne à la taille des tuiles au niveau 2 (512 UEV) puis on ajoute la moitié de la taille d’une tuile (256 UEV).

Il nous faut maintenant définir les plages d’altitudes sur lesquelles chacun des niveaux de nos pyramides seront affichés, à partir des échelles d’affichage visées. Pour cela, nous appliquons la formule illustrée par la Figure 126, découlant du théorème de Thalès. La taille t’ d’un élément graphique à une altitude a est ainsi définie en fonction de sa taille t dans l’espace virtuel et de la focale de la caméra f, fixée à 100 par défaut et que nous avons adoptée telle quelle. Ici, t’ correspond à la taille à laquelle on souhaite que nos tuiles soient visualisées, c’est-à-dire à 256*256 UEV.

Figure 126. Méthode de calcul de la taille t’ d’un élément graphique à une altitude a, en fonction de sa taille t dans l’espace virtuel et de la focale de la caméra (100 par défaut).

Ainsi pour chaque niveau, l’altitude à laquelle nos tuiles seraient affichées à pleine résolution est indiquée dans le Tableau 5 (altitude théorique). Pour assurer un zoom continu, nous définissons pour chaque niveau de la pyramide une plage d’altitudes, correspondant à un intervalle d’échelles d’affichage. Pour cela, en naviguant dans nos pyramides nous avons affiné les plages d’altitudes de manière empirique en vérifiant la lisibilité et l’efficacité de chaque niveau et en optimisant la progressivité des changements de représentations. Nous avons également défini ces plages d’altitudes pour notre pyramide initiale, qui ne comporte que trois niveaux, pour les trois cartes

Juin 2018 173 existantes. Précisons ici que ces intervalles forment une partition de la plage d’altitudes globale. Aux bornes de ces intervalles (altitude 25, 85, 140 et 240), c’est systématiquement le niveau le moins détaillé qui est représenté, car il est affiché au-dessus.

Niveau 4 3 2 1 0

altitude théorique 0 33 100 185 300

plages d’altitudes utilisées (5 niveaux) 0-25 25-85 85-140 140-240 240-310 plages d’altitudes utilisées (3 niveaux) 0-25 - 25-140 - 140-310

Tableau 5. Altitudes théoriques calculées et plages d'altitudes utilisées pour les différents niveaux de nos pyramides alternatives (5 niveaux) et pour la pyramide initiale (3 niveaux).

En pratique, nous avons adapté un script python existant pour produire automatiquement le fichier de configuration scene.xml à partir de ces paramètres. La structure de ce fichier est illustrée par la Figure 127.

Figure 127. Extrait du fichier de configuration scene.xml pour une pyramide à cinq niveaux.

Les niveaux sont définis en premier lieu, par un indice depth indiquant leur ordre dans la pyramide et deux propriétés floor et ceiling définissant le « plancher » et le « plafond » de leur plage d’altitudes. Puis pour chaque niveau, on va définir les coordonnées et le chemin du fichier image correspondant à chacune de ses tuiles. Pour cela, on définit un conteneur Région par un identifiant unique, une taille et un centroïde. Lorsque l’utilisateur se déplace dans l’interface de navigation, une requête est effectuée sur ces régions pour identifier celles en intersection avec l’emprise vue par la caméra et devant être affichées. Enfin, chaque tuile est définie comme une Resource, notamment par :

174 Marion Dumont  un identifiant unique,

 une taille et les coordonnées de son centroïde pour les positionner dans l’espace virtuel,

 un type de format et le chemin relatif vers le fichier source,

 un paramètre définissant le type d’interpolation utilisé pour calculer les échelles intermédiaires en zoom continu, ici bi-cubique, qui nous a paru le plus efficace visuellement. Dans cette partie, nous avons présenté les processus de production de notre matériel de test. Nous avons ainsi choisi d’étudier la transition de représentation du bâti entre les cartes Scan Express définies au 1 : 25k et au 1 : 100k, qui utilisent respectivement le niveau d’abstraction du bâti individuel et de l’aire urbaine. Nous avons proposé trois représentations intermédiaires pour les thèmes géographiques autres que le bâti, en simplifiant les données initiales et leur symbolisation. Puis, nous avons proposé quatre transitions de représentation alternatives pour le thème du bâti, produites par des processus de généralisation différents : typification, AGENT/CartACom, agrégation et variante avec préservation des repères visuels. Nous avons également présenté les méthodes automatiques utilisées pour produire nos pyramides raster tuilées à partir des résultats de ces processus de généralisation. Pour visualiser ces pyramides et mener notre expérience, nous utilisons le système de visualisation multi-échelle ZVTM et son API ZUIST. Développé par des chercheurs en IHM, ce système a l’avantage de proposer des outils pour la création et le contrôle d’une interface de test utilisateurs. Il nous sera donc particulièrement utile pour mener à bien notre expérience, que nous présentons dans le chapitre suivant.

Juin 2018 175

Chapitre E

Test utilisateurs

Pour vérifier les hypothèses C1/C2/C3 énoncées au Chapitre C et évaluer la fluidité de navigation dans

les pyramides créées au Chapitre D, nous réalisons maintenant un test utilisateurs. Pour cela, après

avoir rappelé les objectifs de cette expérience, nous nous appuyons sur la littérature en cartographie,

en sciences cognitives et en IHM (§E.1) pour définir la tâche cartographique multi-échelle que nous

utilisons (§E.2). Puis nous dressons le plan d’expérience en expliquant comment nous avons configuré

(§E.3) puis implémenté ce test (§E.4). Enfin, nous analysons et interprétons ses résultats, puis faisons

176 Marion Dumont