Navigation – Plan du site

AccueilNuméros134À voir, à lireChallenges GEODATA 2021GASPAR —Geoviz Application for Se...

À voir, à lire
Challenges GEODATA 2021

GASPAR —Geoviz Application for Searching And Rescuing People

Matthieu Viry

Texte intégral

1. Contexte

1Les Pelotons de Gendarmerie de Haute-Montagne (PGHM) sont des acteurs majeurs du secours en montagne en France. Lorsqu’ils sont alertés pour rechercher une personne perdue ou blessée, le système propre à la Gendarmerie (GendLoc1) n’est pas toujours suffisant et reste dépendant des limites liées à l’équipement du téléphone de la victime (téléphone non équipé d’un récepteur GPS ou équipement défectueux, problème de transmission, etc.). Dans ce cas, le requérant (c’est-à-dire la personne prévenant les secours, qui n’est pas nécessairement la victime) est alors amené à fournir, en langage naturel, des éléments permettant de localiser au mieux la victime (description de son environnement immédiat, itinéraire suivi, etc.). Le traitement de ces informations par les secouristes est une tâche complexe et laborieuse, nécessitant parfois de consulter des sources variées : cartes topographiques, topoguides décrivant des itinéraires, etc. Cette tâche est d’autant plus compliquée que la position de la victime est décrite avec des éléments imprécis ou relatifs à des objets de référence parfois ambigus.

2Le raisonnement mis en œuvre par les secouristes lors de la recherche de victimes consiste en la formulation d’hypothèses, sur la base des informations fournies par le requérant. L’exemple suivant présente des informations obtenues à l’issue d’un échange entre un requérant et les secouristes lors d’une alerte réelle ayant eu lieu en août 2014.

3Nous pouvons ainsi apprendre que la victime :

  • a quitté Le Bourg-d’Oisans sur un chemin,

  • a marché pendant plusieurs heures en direction d’une station de ski,

  • est tombée de plusieurs mètres,

  • voit une partie de plan d’eau,

  • est sous une route et entend des véhicules,

  • est sous une ligne électrique,

  • était au soleil, mais est maintenant à l’ombre.

4À l’exception du nom de la ville de départ, Le Bourg-d’Oisans, aucun des éléments auxquels la victime se réfère n’est nommé de façon précise, ne permettant ainsi pas aux secouristes de savoir à quel élément réel du terrain il est fait référence.

  • 2 http://choucas.ign.fr/
  • 3 ANR-16-CE23-0018 : Intégration de données hétérogènes et raisonnement spatial pour l’aide à la loca (...)

5Obtenir rapidement une localisation précise de la victime est toutefois un élément essentiel au bon déroulement de l’opération de secours. Cette problématique représente le point de départ du projet CHOUCAS2 (Olteanu-Raimond et al., 2017), financé par l’Agence nationale de la recherche (ANR)3. Au sein de ce projet, différents lots scientifiques se répartissent les tâches nécessaires à lever les verrous permettant l’amélioration de la recherche de victime en montagne :

  • Le Lot 1 est principalement chargé d’identifier les concepts mobilisés par les secouristes lors du traitement de l’alerte tel qu’il peut être effectué devant une interface informatique.

  • Le Lot 2 développe les méthodes permettant d’identifier automatiquement les entités spatiales à partir du discours de la victime.

  • Le Lot 3 met au point les méthodes de calcul permettant de spatialiser un élément de localisation imprécis et de calculer la zone dans laquelle se trouve la victime.

  • Le Lot 4 s’occupe du développement d’une interface permettant la saisie et la restitution de l’ensemble de ces éléments dans une interface utilisateur.

  • Le Lot 5 est en charge de forer, structurer et mettre à disposition les données de références à partir de sources hétérogènes.

6Les propositions que nous décrivons ici s’inscrivent dans le Lot 1 et dans le Lot 4 : après avoir formalisé les différents concepts nécessaires aux secouristes, nous proposons une interface de géovisualisation permettant d’assister un utilisateur secouriste lors du processus de localisation d’une victime à partir d’éléments de discours imprécis.

7Nous présentons, dans la section 2, les modèles mis au point dans le cadre de l’ANR CHOUCAS et en particulier celui dédié à formaliser le domaine de la recherche de victimes en montagne. Nous présentons ensuite (section 3) l’organisation générale de l’interface avant de nous concentrer sur les représentations graphiques proposées à l’utilisateur (section 4).

2. Données et modèles sous-jacents

8Avant de nous lancer dans le développement d’une application répondant aux besoins exprimés par le projet CHOUCAS, des travaux ont été menés afin de formaliser les éléments du domaine de la recherche de victimes en montagne qui interviennent dans le traitement préalable de l’alerte par un secouriste. Cette formalisation, conduite en utilisant le Web Ontology Language (OWL) se nomme l’Ontologie d’Alerte Choucas — OAC (Viry et Villanova-Oliver, 2020). Cette formalisation découle de l’analyse de cas réels d’alertes, de l’identification des besoins en termes de saisie et de restitution des informations et de la mise en évidence des concepts sur lesquels s’appuie le raisonnement des secouristes.

9Les principaux objectifs qui ont guidé ce travail sont de garantir l’interopérabilité des développements réalisés dans le projet CHOUCAS et de favoriser les échanges entre les partenaires du projet.

  • 4 Les termes en italiques sont issus de l’OAC.

10Nous présentons ici plusieurs des concepts structurant ce modèle (figure 1) à commencer par l’alerte4 en elle-même, qui décrit l’ensemble du processus de recherche de victime, de son déclenchement par l’appel d’un requérant jusqu’à sa fin (qu’il s’agisse de la découverte de la victime ou de l’abandon des recherches, par exemple). La notion de requérant est importante puisque c’est la personne avec laquelle le secouriste est en contact téléphonique. Cette personne peut également être la victime, mais cela n’est pas toujours le cas (ce sont parfois des proches d’une personne n’étant pas rentrée qui donnent l’alerte auprès des secouristes).

Figure 1. Vue d’ensemble de l’Ontologie d’Alerte Choucas

Figure 1. Vue d’ensemble de l’Ontologie d’Alerte Choucas

Image extraite de Viry et Villanova-Oliver (2020)

11Afin de permettre de localiser la victime, le requérant donne au secouriste des indices (i.e. des éléments de localisation imprécis) concernant la localisation de la victime. Ces indices peuvent correspondre à la description de l’environnement immédiat de la victime, qu’il soit actuel ou passé ou de l’itinéraire suivi, par exemple. La notion d’indice est centrale dans notre modèle puisque c’est elle qui lie la victime à des informations spatiales et temporelles permettant de la localiser. Chaque indice est ainsi qualifié par un instant ou une durée de validité (cela correspond, par exemple, aux cas où la victime est « passée sur un pont il y a une heure », mais « voit actuellement une portion de plan d’eau »). De plus, notre modèle comporte des propriétés d’ordonnancement permettant de décrire la chronologie entre les indices même lorsqu’il n’est pas possible de qualifier avec précision l’instant auquel ils sont valides. Concernant les informations spatiales, un indice doit être qualifié par une relation de localisation, définie entre deux Entités Spatiales (ES), respectivement un site et une cible. L’OAC ne définit pas de sous-classes ou d’instances de relations de localisation. En effet, dans le cadre du projet CHOUCAS, une ontologie est dédiée à la formalisation des différents types de relation de localisation : il s’agit de l’Ontologie des Relations de Localisation — ORL (Bunel, 2021) qui décrit une quarantaine de relations (telles que à l’est de, à la même altitude que, sous et proche de, etc.).

12Les Entités Spatiales qui sont mises en lien par une relation de localisation peuvent être de différentes natures : soit un objet précis et identifiable de manière non ambiguë (par exemple « le lac Achard », il s’agit alors d’une ES repère), soit un ensemble d’objets correspondants, par exemple, à une catégorie exprimée oralement (par exemple, « un lac », il s’agit alors d’un ensemble d’ES candidates puisque tous les lacs de la zone sont ainsi pris en compte). Les noms de catégories de ces entités spatiales ne sont pas définis dans OAC, mais dans une ontologie dédiée réalisée par les partenaires du projet : il s’agit de l’Ontologie des Objets de Référence — OOR (Olteanu-Raimond et al. 2020).

13Enfin, un indice a vocation à être traduit en une Zone de Localisation. Il s’agit de la portion du territoire qui peut contenir la victime au regard de l’indice exprimé. Le type de cette Zone de Localisation dépend de la nature de l’indice : si ce dernier est exprimé par l’affirmative (« voir une portion de plan d’eau ») il s’agit d’une Zone de Localisation Compatible (ZLC) alors qu’il s’agit d’une Zone de Localisation Incompatible si l’indice est exprimé par la négative (« ne pas être sur un pont »).

14Toutefois, un seul indice est rarement suffisant pour localiser avec précision un individu. C’est pourquoi, dans le cadre d’une hypothèse de recherche, nous proposons de prendre en compte plusieurs indices et de les croiser pour obtenir ce qui est appelé, la Zone de Localisation Probable (ZLP, voire figure 2).

15Une hypothèse de recherche correspond à la définition d’une Zone Initiale de Recherche (ZIR, il s’agit d’une large portion du territoire dans laquelle la recherche s’effectue, par exemple, un massif montagneux comme « la Chartreuse ») et à la prise en compte d’un ou plusieurs indices, dont la ZLP est calculée au sein d’une ZIR (c’est-à-dire que la ZIR en question est utilisée comme bounding box pour effectuer le calcul).

Figure 2. Exemple d’indices transformés en Zones de Localisation Compatible et fusionnés en une Zone de Localisation Probable

Figure 2. Exemple d’indices transformés en Zones de Localisation Compatible et fusionnés en une Zone de Localisation Probable

16Si l’OAC est utilisée pour guider le développement de l’interface utilisateur, les deux autres ontologies développées par les partenaires du projet CHOUCAS, OOR et ORL, sont également mobilisées par des briques que nous utilisons :

  • une base de données Neo4j contenant des objets du territoire provenant de diverses sources de données et catégorisés en utilisant les termes de l’OOR,

  • un service web, nommé Ruitor (Bunel 2021) utilisant les termes de l’ORL pour décrire les relations de localisation et utilisant le pattern définit par l’OAC pour qualifier un indice (ZIR, site, relation de localisation, confiance).

17Nous présentons dans la section suivante le développement de l’interface de GASPAR qui matérialise les principaux concepts de l’OAC, ainsi que les liens avec les briques utilisant les ontologies OOR et ORL.

3. Une interface basée sur l’OAC

18Différents choix technologiques ont été effectués dès les prémices du développement de l’application. En effet, il a été choisi de développer une application web, notamment en raison de la richesse et du dynamisme de l’écosystème web en ce qui concerne la création de cartes interactives et le développement d’interfaces utilisateurs. De plus, ce choix s’explique également pour des raisons d’interopérabilité, nous permettant de développer une application ne dépendant pas d’un système d’exploitation particulier, mais seulement d’un navigateur web. Il s’agit là d’une préoccupation qui trouve son origine dès les débuts du Web et qui vise à améliorer l’acceptation par l’utilisateur tout en évitant les difficultés classiques de la distribution de logiciels (Rice et al. 1996).

19L’application que nous proposons, GASPAR5, prend ainsi la forme d’une Single Page Application (SPA) et est constituée de code HTML, CSS et JavaScript utilisant différentes bibliothèques bien connues telles que OpenLayers6 et Itowns7. Elle permet d’exposer des fonctionnalités de la base de données graphe Neo4J via une architecture web légère qui délègue la majorité des traitements de données au client web, excepté les traitements de données spatiales. Ceux-là sont mis à disposition sous forme de services appelés par une requête HTTP, et permettent, par exemple le rééchantillonnage de couche raster, la création de contours vecteurs à partir d’un raster, l’intersection de formes vectorielles.

20Cette architecture dite « REST », classique dans le monde du développement web, s’appuie également sur les services offerts par d’autres serveurs web (figure 3). Il s’agit du service Ruitor (pour la spatialisation des indices en ZLC, et la fusion des ZLC en ZLP) et du service NERC (qui permet d’annoter du texte afin d’extraire les entités nommées étendues du discours du requérant).

21Les principaux composants d’interface permettant de saisir et de gérer les informations relatives à l’alerte sont :

  • Définition et gestion de la ZIR (figure 4, A)

  • La table des indices et hypothèses (figure 4, B)

  • Le bloc-notes d’indices (figure 4, C)

  • Arbres des objets du territoire (figure 4, D)

  • Carte (figure 4, E)

  • Vue terrain (figure 4, F)

Figure 3. Architecture de GASPAR et des services utilisés

Figure 3. Architecture de GASPAR et des services utilisés

Figure 4. Capture d’écran de GASPAR lors du traitement d’une alerte

Figure 4. Capture d’écran de GASPAR lors du traitement d’une alerte

22D’autres composants ne sont pas visibles en permanence dans l’interface et s’ouvrent lorsque cela est nécessaire, il s’agit notamment de la fenêtre de saisie d’indice. Cette dernière est visible lors de l’instanciation d’un indice (ce point est détaillé en section 3.3 - figure 9).

23L’utilisation des différents composants de GASPAR s’inscrit dans une séquence d’actions de la part de l’utilisateur, du début d’une alerte, matérialisée par la définition de la Zone Initiale de Recherche, jusqu’à l’obtention d’une Zone de Localisation Probable permettant de localiser la victime. Cette séquence d’actions, présentée plus en détail dans cette section, implique une séquence d’échanges entre les différents services présentés en figure 3 :

  • l’utilisateur définit la ZIR, cela a pour effet de charger l’ensemble des objets du territoire présent dans cette zone à partir de la BD Neo4j ;

  • l’utilisateur identifie le (ou les) objet(s) de référence nécessaire(s) à la création de chaque indice, cela peut être fait grâce à une sélection directe sur la carte ou dans un arbre présentant les objets du territoire, mais également à partir de la saisie d’un indice en langage naturel grâce à un appel au service NERC qui permet d’annoter le texte pour identifier les entités nommées ;

  • l’utilisateur utilise ce (ou ces) objet(s) afin de configurer l’appel au service de spatialisation (Ruitor) et obtient en retour la ZLC correspondante qui est affichée dans l’interface ;

  • dès lors que deux indices ou plus sont présents, le calcul de fusion (Ruitor) est effectué, permettant d’obtenir la ZLP de la victime qui est affichée dans l’interface.

3.1 Définition de la Zone Initiale de Recherche

24Lors du démarrage de l’application, aucune ZIR n’est sélectionnée (figure 5) et c’est au secouriste d’en définir une, en fonction des premiers indices recueillis dans le cadre d’une alerte. La définition d’une ZIR peut être effectuée en utilisant l’emprise de la carte affichée à l’écran ou en utilisant des outils de dessin permettant de tracer un rectangle, un cercle, un polygone par ses sommets ou un polygone à main levée.

Figure 5. Zone Initiale de Recherche non définie

Figure 5. Zone Initiale de Recherche non définie

Figure 6. Zone Initiale de Recherche définie

Figure 6. Zone Initiale de Recherche définie

25Une fois cette opération effectuée, l’utilisateur dispose d’un retour immédiat, d’une part dans le composant dédié à la ZIR, grâce au changement d’état du composant et à l’indication de la taille de la ZIR sélectionnée (figure 6), et, d’autre part, sur le composant cartographique où la ZIR est représentée (cf. Section 4.1.1).

26C’est également la définition de la ZIR qui va déclencher un appel à la base de données contenant les objets du territoire afin de charger dans l’interface l’ensemble de ceux qui intersectent la ZIR.

27Cela permet à l’utilisateur de disposer de tous les objets de référence dans l’interface. Ces derniers sont affichés dans un composant appelé l’arbre des objets du territoire (figure 7). Ces objets sont ainsi disponibles immédiatement pour être utilisés dans la création d’un indice.

Figure 7. Arbre des objets du territoire

Figure 7. Arbre des objets du territoire

3.2 Consignation des indices

28La consignation des indices donnés en langage naturel peut être effectuée dans un bloc-notes de saisie (figure 8).

Figure 8. Bloc-notes vers fenêtre d’indice

Figure 8. Bloc-notes vers fenêtre d’indice

29Ce bloc-notes permet, pour chacune des entrées, d’instancier l’indice correspondant en tentant de pré-remplir la boite de saisie des indices avec les informations du bloc-notes (figure 8). Dans ce but, il est nécessaire d’analyser les éléments du discours afin de les identifier. Cela est possible grâce au service NERC, développé par les partenaires du lot 2 (Moncla et Gaio, 2015) et permettant d’annoter les extraits de discours afin notamment d’identifier les entités nommées étendues (ENE, pour Extended Named Entities). Ce mécanisme d’annotation est basé sur le format TEI (Text Encoding Initiative) qu’il étend.

30Cette consignation est optionnelle et a vocation à permettre au secouriste de ne pas perdre de temps à utiliser un autre support de note. Ce composant bloc-notes d’indice vise à diversifier les possibilités de création d’indices afin de ne pas contraindre l’utilisateur à un seul type d’utilisation. Il est, en effet, également possible de créer des indices directement à partir de l’arbre des objets ou à partir de la carte.

31Ainsi, quel que soit le mode de sélection des objets de référence utilisés dans un indice et visant à pré-remplir la fenêtre de création d’indices, la même fenêtre est ouverte (section suivante) et les indices instanciés apparaissent ensuite dans la table de gestion des indices et des hypothèses.

3.3 Saisie et transformation des indices

32Un élément primordial, afin de pouvoir accompagner le raisonnement du secouriste, est de lui faciliter la saisie des indices devant être transformés en ZLC. En effet, l’instanciation d’un indice repose sur des éléments de vocabulaire de l’ensemble des ontologies présentées précédemment : elle fait, en particulier, appel au choix d’une relation de localisation (parmi la quarantaine disponible) et au choix d’un ou plusieurs objets du territoire. Ces éléments sont saisis dans une fenêtre dédiée (figure 9). Il est ainsi possible de décomposer l’instanciation d’un indice en plusieurs éléments :

  • la relation de localisation à utiliser (cet élément est indispensable et doit être unique) ;

  • l’objet du territoire (il peut aussi s’agir d’un point défini par ses coordonnées ou d’une catégorie d’objets du territoire) auquel il est fait référence (cet élément est indispensable) ;

  • la confiance (i.e. le crédit) que donne le secouriste à l’indice en question (cet élément est indispensable, mais peut être laissé sur sa valeur par défaut) ;

  • l’instant (ou la durée) à laquelle (ou durant laquelle) l’indice est valable (il est ainsi possible de saisir l’indice « j’étais à côté d’une fontaine il y a une heure », sans que celui-ci ne rentre dans le calcul de la ZLP actuelle) ;

  • la couleur d’affichage de l’indice (cet élément est également indispensable, mais il est possible de le laisser sur sa valeur par défaut).

Figure 9. Fenêtre d’instanciation d’un indice

Figure 9. Fenêtre d’instanciation d’un indice

33La sélection d’une relation de localisation (figure 10) est assistée par un composant disposant d’une part, d’autocomplétion et, d’autre part, d’un mécanisme de filtrage des relations affichées (ce filtrage pouvant également être effectué sur le nom du type de relation de localisation, affiché sous forme d’un badge de couleur comme « proximité » dans la figure 10).

Figure 10. Aide à la saisie et au choix d’une relation de localisation

Figure 10. Aide à la saisie et au choix d’une relation de localisation

34Une fois l’indice créé et la ZLC correspondante calculée, l’indice apparaît dans la table des indices et hypothèses (figure 11) ainsi que sur la carte. Cela permet d’interagir avec l’indice de différentes manières : contrôle de son affichage (transparence et contour) et choix de la (ou des) hypothèse(s).

Figure 11. Table des indices et hypothèses

Figure 11. Table des indices et hypothèses

3.4 De multiples cartes pour représenter de multiples hypothèses

35La table des indices et des hypothèses (figure 11) permet de créer plusieurs hypothèses de recherche (jusqu’à trois par défaut). Saisir dans ce composant que des indices participent à une autre hypothèse de recherche a pour effet d’ouvrir un nouveau composant cartographique (voir section suivante pour les représentations qu’il propose), dédié à la nouvelle hypothèse dans un onglet dédié de l’interface. Ainsi, la figure 11 présente trois indices, mais également trois hypothèses, nécessitant une lecture verticale du tableau : la première hypothèse utilise les trois indices, la deuxième hypothèse utilise les indices #2 et #3 alors que la troisième hypothèse utilise les indices #1 et #2. Dans ce cas de figure, trois cartes, correspondant aux trois hypothèses, sont affichables dans l’interface. Cette possibilité (non illustrée ici pour des raisons de place) permet à l’utilisateur de comparer deux hypothèses (ou plus) côte à côte grâce aux possibilités de réorganisation de l’interface offertes par GASPAR.

4. Représentations graphiques

36Différents objets spatiaux doivent ainsi être présentés à l’utilisateur : la ZIR, les objets du territoire (récupérés à partir de la BD Neo4j et chargés dans l’interface pour l’ensemble du territoire couvert par la ZIR) ainsi que les ZLC et les ZLP retournées par le service Ruitor. Les données produites par le service Ruitor se présentent sous forme de raster dont les valeurs des cellules sont comprises entre 0 et 1. Ce type de données présente un fort intérêt dans le cadre du projet CHOUCAS puisqu’il rend possible d’exprimer, dans chaque cellule, la valeur d’appartenance à la zone (qu’il s’agisse d’une ZLC ou d’une ZLP) décrite par la couche en question. Ce type de données peut, toutefois, être particulièrement délicat à représenter de manière à bien percevoir la valeur prise par chaque cellule de la couche. Ce point est particulièrement vrai lorsque plusieurs couches de ce type doivent être représentées simultanément dans un même composant cartographique.

37Nous présentons ci-après les choix de représentation effectués, ainsi que les interactions qui leur sont liées.

4.1 Vue cartographique 2D

38Le principal composant de représentation de l’information géographique est une carte interactive créée grâce à la bibliothèque OpenLayers. Ce composant cartographique, qui affiche par défaut un fond de carte topographique, a vocation à afficher les différentes zones traitées par l’application, c’est-à-dire la ZIR, les différentes ZLC, la ZLP ainsi que les objets de référence. Cependant ces derniers ne sont pas affichés en permanence pour ne pas créer d’occlusion visuelle, mais uniquement lors de leur survol (ou du survol de leur catégorie d’appartenance) dans l’arbre des objets (figure 7), lors de la création d’un indice à partir du fond de carte ou lors du survol d’un indice déjà saisi.

4.1.1 Représentation de la Zone Initiale de Recherche

39La ZIR est la zone définie par le secouriste dès le début de l’alerte. Nous choisissons de matérialiser cette zone par un masque de couleur blanc-gris ayant une opacité de 80 % (figure 12). Cette matérialisation sur la carte rend explicite une opération préalablement réalisée de manière implicite (que ce soit par le secouriste ou dans la précédente version du prototype qui n’était pas basée sur l’OAC, cf. Viry et al. 2019). Elle permet de concentrer le regard sur l’intérieur de la ZIR sans toutefois priver le secouriste du contexte environnant.

Figure 12. Représentation de la ZIR

Figure 12. Représentation de la ZIR

40Enfin, en ce qui concerne le traitement de l’alerte, c’est l’emprise de la ZIR qui est utilisée comme boite englobante pour délimiter les calculs de spatialisation d’indices et de fusion réalisés par le service Ruitor. Nous pensons que, au-delà de la définition même du concept de ZIR, la matérialisation choisie retranscrit cet aspect de manière instinctive à l’utilisateur.

4.1.2 Représentation des Zones de Localisation Compatible

41Les ZLC sont les zones qui correspondent à la spatialisation de chaque indice.

42S’il est important de représenter ces ZLC, leur importance est moindre que les ZLP (cf. figure 2). Nous proposons, à ce titre, de présenter ces zones à l’utilisateur de deux manières :

  • en faisant figurer la valeur de chaque cellule grâce à la transparence de la couleur sélectionnée ;

  • en faisant figurer le contour délimitant valeurs nulles et valeurs positives.

Figure 13. Représentation d’une ZLC (indice « proche d’un sommet »)

Figure 13. Représentation d’une ZLC (indice « proche d’un sommet »)

43Ces deux modes de représentation interviennent selon le contexte de visualisation. La première ZLC reçue est affichée via ces deux modalités. Lors de l’ajout des indices suivants, et de la réception des ZLC correspondantes, seule la représentation en contours est conservée (que ce soit sur la 1re ZLC ou sur les suivantes). L’utilisateur a toutefois le choix d’afficher manuellement la représentation qui utilise la transparence lorsqu’il le souhaite. Notre choix s’explique par le fait que la présence de deux indices ou plus déclenche automatiquement le calcul de la ZLP, i.e. la zone calculée par le croisement des ZLC et au sein de laquelle la victime est susceptible d’être située. Cette ZLP, dont la représentation est présentée en section 4.1.3 est la zone la plus importante à montrer au secouriste, il est donc important que ce soit cette couche d’information qui soit la plus prégnante visuellement.

44Nous pensons toutefois que la conservation par défaut de l’affichage des contours de chacune des ZLC permet de visualiser le rôle de chacune d’entre elles dans la création de la ZLP (voir figure 15 dans la section suivante). De plus, leur affichage grâce aux contours peut inciter le secouriste à les afficher entièrement s’il souhaite plus d’informations sur l’emprise spatiale d’une ZLC spécifique.

4.1.3 Représentation de la Zone de Localisation Probable

45Nous proposons de représenter la ZLP de deux manières différentes en fonction de la résolution d’affichage actuelle. Nous développons ici une proposition effectuée précédemment pour représenter la ZLC lorsque celle-ci était au format vecteur (Viry et Villanova-Oliver, 2021) en l’adaptant désormais à des données raster.

46Le premier niveau d’affichage correspond à la « vue d’ensemble » d’une hypothèse de recherche (figure 14). Dans ce cas de figure, nous représentons la ZLP par un figuré plein de couleur rouge. Ce figuré ne rend volontairement pas compte de la valeur de chaque cellule, mais seulement du fait que les cellules contiennent une valeur non nulle.

47Le second niveau d’affichage correspond au détail d’une ZLP et de ses éventuels fragments (figure 15). La représentation choisie pour ce niveau de détail est une représentation en symboles proportionnels, où la valeur de chaque pixel est traduite par la surface du cercle affiché. Un pixel possédant une valeur de 1 sera ainsi représenté par un cercle dont le diamètre est égal à la taille du pixel. Les pixels qui possèdent une valeur inférieure à 0,05 ne sont pas représentés. Cette représentation permet à l’utilisateur de lire la valeur d’appartenance de chaque pixel à la ZLP.

48De plus, nous proposons d’afficher, pour cette couche, la valeur du pixel survolé par le curseur dans une infobulle attachée au composant cartographique. Par cela, nous reconnaissons qu’il peut être difficile de percevoir la valeur exacte de chaque pixel avec les représentations que nous proposons et nous souhaitons rendre cette valeur accessible à l’utilisateur.

49Les différents éléments qui composent notre proposition de représentation de la ZLP se veulent, ainsi, être une implémentation du mantra bien connu de la visualisation d’information proposé par Shneiderman (1996) : « Overview first, zoom and filter, then details-on-demand ».

Figure 14. Représentation de la ZLP

Figure 14. Représentation de la ZLP

Vue d’ensemble.

Figure 15. Représentation de la ZLP

Figure 15. Représentation de la ZLP

Vue détaillée avec affichage des contours des ZLC ayant participé à son calcul.

4.2 Vue terrain 3D

50L’autre composant de représentation de l’information géographique est une vue terrain, sur un globe, obtenue grâce à l’utilisation de la bibliothèque Itowns8.

51La nature différente de la vue présentée à l’utilisateur nous pousse à faire des choix légèrement différents pour la restitution des éléments de l’alerte. En effet, dans GASPAR, la vue terrain 3D est affichée comme un composant complémentaire à la carte et non pas comme un composant de première classe. La vue terrain 3D n’est ainsi pas ouverte par défaut, mais seulement à la demande de l’utilisateur. Elle ne supporte pas d’interactions visant à sélectionner les objets du territoire pour créer des indices et ne représente pas les ZLC. Y figurent les deux zones les plus importantes : la ZIR et la ZLP (figure 16).

52En raison de la représentation du modelé géomorphologique et des reliefs du terrain, la représentation en symboles proportionnels est difficilement réalisable. Nous choisissons donc de rendre compte de l’incertitude grâce à la création de contours à 5 niveaux venant mettre en évidence les portions du territoire pour lesquelles la valeur de la ZLP est supérieure à zéro. Cette représentation utilise une progression séquentielle de couleurs issue de ColorBrewer (Brewer, Hatchard et Harrower, 2003), nommée OrRd, où la couleur froide représente une faible valeur et où la couleur chaude représente une forte valeur.

Figure 16. Représentation de la ZIR et de la ZLP dans la vue terrain 3D

Figure 16. Représentation de la ZIR et de la ZLP dans la vue terrain 3D

5. Bilan et perspectives

53Afin de répondre aux enjeux soulevés par la localisation de victimes en montagne, le projet CHOUCAS propose des méthodes et des outils permettant de mettre à disposition des données de référence provenant de sources variées, d’analyser et d’annoter le discours d’un requérant, de spatialiser un indice imprécis en une zone de localisation et de fusionner ces zones. Les enjeux auxquels nous répondons avec l’application GASPAR sont ceux de la capture des indices de localisation et de la restitution des zones de localisation dans un environnement de géovisualisation permettant le traitement complet d’une alerte.

54La principale perspective qui se dégage des travaux menés jusqu’à présent sur le développement de GASPAR est la conduite des tests utilisateurs visant à évaluer différents aspects de l’outil proposé. Ces tests utilisateurs sont prévus pour cibler plusieurs éléments : la pertinence des méthodes de rendus graphiques (2D et 3D) proposés, l’utilisabilité du composant de saisie des indices (bloc-notes — qui est optionnel dans le workflow — et boite de saisie des indices) et l’accompagnement offert par l’application dans son ensemble.

55Financement
Ce travail est financé par l’Agence nationale de la recherche au sein du projet « Intégration de données hétérogènes et raisonnement spatial pour l’aide à la localisation des victimes en montagne – CHOUCAS » [ANR-16-CE23-0018].

Haut de page

Bibliographie

Brewer C. A., Hatchard G. W., Harrower M. A. (2003). “ColorBrewer in Print: A Catalog of Color Schemes for Maps”. Cartography and Geographic Information Science, vol. 30, no 1, p. 5-32. En ligne : https://doi.org/10.1559/152304003100010929

Bunel M. (2021). Modélisation et Raisonnement Spatial Flou Pour l’aide à La Localisation de Victimes En Montagne. Thèse, Université Gustave Eiffel. En ligne : https://tel.archives-ouvertes.fr/tel-03298717

Moncla L., Gaio M. (2015). “A Multi-Layer Markup Language for Geospatial Semantic Annotations”. Proceedings of the 9th Workshop on Geographic Information Retrieval, p. 1-10. En ligne : https://doi.org/10.1145/2837689.2837700

Olteanu-Raimond A-M., Mustière S., Bunel M., Dominguès C., Duchêne C., Jolivet L., Van-Damme M.-D. (2020). Spatial Reference Objects Ontology (version 1.0.1). En ligne : http://purl.org/choucas.ign.fr/oor

Rice J., Farquhar A., Piernot P., Gruber T. (1996). “Using the Web Instead of a Window System”. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Common Ground - CHI ’96, p. 103-110. Vancouver, British Columbia, Canada : ACM Press. En ligne : https://doi.org/10.1145/238386.238442

Shneiderman B. (1996). “The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations”. Proceedings of the 1996 IEEE Symposium on Visual Languages, IEEE Computer Society, p. 336-343.

Viry M., Villanova-Oliver M. (2020). « Ontologie d’Alerte Choucas : de la modélisation des connaissances à un outil support d’un raisonnement géovisuel ». Geomatica, vol. 73, no 3, p. 87-103. En ligne : https://doi.org/10.1139/geomat-2020-0005

Viry M., Villanova-Oliver M. (2021). “How to Derive a Geovisualization from an Application Data Model: An Approach Based on Semantic Web Technologies”. International Journal of Digital Earth, vol. 14, no 7, p. 874-898. En ligne : https://doi.org/10.1080/17538947.2021.1900937

Viry M., Villanova-Oliver M., Gautier J., Sreeves M., Davoine P.-A. (2019. “Improving the Search for Victims in Mountain Environments with Geovisualization and Competing Hypotheses Management”. Proceedings of the ICA, vol. 2, p. 1-8. En ligne : https://doi.org/10.5194/ica-proc-2-138-2019

Haut de page

Notes

1 https://fr.wikipedia.org/wiki/GendLoc

2 http://choucas.ign.fr/

3 ANR-16-CE23-0018 : Intégration de données hétérogènes et raisonnement spatial pour l’aide à la localisation des victimes en montagne - CHOUCAS

4 Les termes en italiques sont issus de l’OAC.

5 Geoviz Application for Searching And Rescuing People

6 https://openlayers.org/

7 http://www.itowns-project.org/

8 http://www.itowns-project.org/

Haut de page

Table des illustrations

Titre Figure 1. Vue d’ensemble de l’Ontologie d’Alerte Choucas
Crédits Image extraite de Viry et Villanova-Oliver (2020)
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-1.jpg
Fichier image/jpeg, 364k
Titre Figure 2. Exemple d’indices transformés en Zones de Localisation Compatible et fusionnés en une Zone de Localisation Probable
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-2.jpg
Fichier image/jpeg, 343k
Titre Figure 3. Architecture de GASPAR et des services utilisés
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-3.jpg
Fichier image/jpeg, 167k
Titre Figure 4. Capture d’écran de GASPAR lors du traitement d’une alerte
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-4.jpg
Fichier image/jpeg, 417k
Titre Figure 5. Zone Initiale de Recherche non définie
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-5.jpg
Fichier image/jpeg, 21k
Titre Figure 6. Zone Initiale de Recherche définie
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-6.jpg
Fichier image/jpeg, 22k
Titre Figure 7. Arbre des objets du territoire
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-7.jpg
Fichier image/jpeg, 124k
Titre Figure 8. Bloc-notes vers fenêtre d’indice
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-8.jpg
Fichier image/jpeg, 151k
Titre Figure 9. Fenêtre d’instanciation d’un indice
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-9.jpg
Fichier image/jpeg, 51k
Titre Figure 10. Aide à la saisie et au choix d’une relation de localisation
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-10.jpg
Fichier image/jpeg, 15k
Titre Figure 11. Table des indices et hypothèses
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-11.jpg
Fichier image/jpeg, 162k
Titre Figure 12. Représentation de la ZIR
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-12.jpg
Fichier image/jpeg, 1,5M
Titre Figure 13. Représentation d’une ZLC (indice « proche d’un sommet »)
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-13.jpg
Fichier image/jpeg, 1,5M
Titre Figure 14. Représentation de la ZLP
Légende Vue d’ensemble.
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-14.jpg
Fichier image/jpeg, 1,7M
Titre Figure 15. Représentation de la ZLP
Légende Vue détaillée avec affichage des contours des ZLC ayant participé à son calcul.
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-15.jpg
Fichier image/jpeg, 1,4M
Titre Figure 16. Représentation de la ZIR et de la ZLP dans la vue terrain 3D
URL http://journals.openedition.org/mappemonde/docannexe/image/8063/img-16.jpg
Fichier image/jpeg, 1,0M
Haut de page

Pour citer cet article

Référence électronique

Matthieu Viry, « GASPAR —Geoviz Application for Searching And Rescuing People »Mappemonde [En ligne], 134 | 2022, mis en ligne le 27 octobre 2022, consulté le 29 novembre 2022. URL : http://journals.openedition.org/mappemonde/8063 ; DOI : https://doi.org/10.4000/mappemonde.8063

Haut de page

Auteur

Matthieu Viry

Univ. Grenoble Alpes, CNRS, Grenoble INP (Institute of Engineering Univ. Grenoble Alpes), LIG, 38000 Grenoble, France

Articles du même auteur

Haut de page

Droits d’auteur

CC-BY-NC-SA-4.0

Creative Commons - Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International - CC BY-NC-SA 4.0

https://creativecommons.org/licenses/by-nc-sa/4.0/

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search