Traitement de requêtes relatives à des objets mobiles

Dans les deux sections précédentes, nous nous sommes intéressés aux travaux liés au traitement des requêtes (spatiales et RDL) invoquant des données relatives à des objets fixes (e.g. hôpitaux). Dans cette section, nous présentons les axes les plus représentatifs de la recherche sur l’évaluation des requêtes invoquant des données relatives à des objets mobiles (e.g. la localisation des ambulances ou des hélicoptères). Nous commençons d’abord par présenter le problème de la modélisation des données, particulièrement, celles qui changent de manière continue comme la position des objets mobiles. Ensuite, nous abordons le problème du suivi et de mise à jour de la position de ces objets, ainsi que celui de la gestion de l’incertitude liée à la localisation.

5.1. Modélisation des objets mobiles

La représentation de la nature continue du mouvement des objets mobiles dans les bases de données est l’un des problèmes centraux de ce domaine. Premièrement, les systèmes informatiques ne sont pas capables de manipuler des ensembles infinis. En effet, pour les SGBD traditionnels, les données sont factuelles et ne changent pas jusqu’à ce qu’elles soient modifiées de façon explicite ; ce qui n’est pas adapté à la représentation du mouvement. D’un autre côté, les systèmes de positionnement renvoient les informations de localisation de manière discrète et la continuité du service n’est pas toujours assurée (e.g. GPS). Cette problématique rejoint, en fait, celle de la représentation des données spatio-temporelles. En effet, un objet spatio-temporel peut être défini comme un objet dont la forme et/ou la position

varie au cours du temps [MR 00]. La forme des objets mobiles est souvent ignorée puisque ces derniers sont généralement assimilés à des points dont la position change en fonction du temps. Cette hypothèse simplifie relativement le problème par rapport à celui, plus général, de la représentation des données spatio-temporelles. Les travaux proposés pour représenter le comportement spatio-temporel des objets mobiles suivent deux courants principaux. Le premier s’intéresse à la problématique de la représentation de l’historique du mouvement et des trajectoires des objets mobiles. Le second se focalise plutôt sur le problème de la représentation de la position courante de l’objet mobile et éventuellement de sa position future. Ce courant s’appuie sur une approche de modélisation basée sur des attributs dynamiques. Les travaux du premier courant sont, en fait, des extensions de ceux proposés pour la modélisation des données spatiales. Ainsi, nous retrouvons les deux approches présentées dans la section 3 : celle qui se base sur les TAD et celle qui s’appuie sur les bases de données contraintes.

5.1.1. Les types abstraits de données spatio-temporelles

Nous avons précisé que les TAD ont initialement été introduits pour modéliser des données spatiales (cf. section 3). Dans le cadre du projet européen Chorochronos [KSF+ 03], Koubarakis et al. ont proposé d’exploiter le concept de TAD pour définir des TAD spatio- temporels [EGS+ 99]. Ainsi, plusieurs travaux ont été menés dans le but d’intégrer aux SGBD un système de types abstraits et d’opérations permettant de mieux représenter les données spatio-temporelles relatives aux objets mobiles et d’étendre les langages de requêtes les interrogeant [GBE+ 00].

Le modèle présenté repose sur des types atomiques (e.g. int, real, string, bool), des types géométriques (point, points, line …) et des types temporels (instant). Un constructeur de type très important, appelé moving, permet d’instancier des types dont les valeurs changent continuellement. Par exemple, une instance de moving(point) peut représenter le déplacement d’un objet mobile. A partir de là, une panoplie d’opérations sur ces types peut être définie comme at, mdistance, trajectory. La syntaxe de plusieurs opérateurs a été définie dans [GBE+ 00]. Ces opérateurs peuvent être incorporés à des langages destinés aux utilisateurs (e.g. sous la forme d’un SQL étendu).

Pour illustrer nos propos, prenons l’exemple suivant :

Soit la relation ambulances(id: string, typeAmb: string, pos: mpoint)

mpoint est un synonyme de moving(point). L’attribut pos est un attribut spatio-temporel qui

représente la localisation de l’ambulance en fonction du temps. L’attribut typeAmb permet de savoir si l’ambulance est une ambulance SAMU ou une ambulance appartenant à une société privée AP.

Supposons que nous disposions de l’opérateur trajectory et de la fonction length définis de la manière suivante :

trajectory: mpoint → line renvoie une ligne qui est la projection des points mobiles dans le

plan.

Length : line → real détermine la longueur d’une ligne;

Maintenant, nous pouvons exprimer des requêtes telles que « sélectionner les ambulances privées dont la trajectoire a dépassé les 30 km »

Select id

From ambulances

Where typeAmb =’’AP’’ AND length(trajectory(pos))>30 ;

Nous avons choisi un exemple simple pour donner un aperçu des possibilités de l’utilisation des TAD. Des requêtes plus complexes peuvent être exprimées en utilisant d’autres opérations, mais cela nécessite davantage d’explications (e.g. sélectionner les ambulances dont la trajectoire traverse le centre ville entre 17h et 18h). Pour plus de détail, se référer à [GBE+ 00].

Retenons que l’utilisation des TAD permet de représenter la nature dynamique du mouvement des objets mobiles. Elle répond essentiellement au besoin de déterminer des structures de données permettant de gérer de manière efficace l’historique des mouvements des objets et des régions mobiles et de représenter leurs trajectoires complètes. L’inconvénient de cette approche est lié au fait que l’utilisateur soit obligé d’apprendre plusieurs nouvelles opérations, de nouvelles fonctions et de nouveaux types ; ce qui ne correspond pas, tout à fait, à l’esprit des langages déclaratifs tels que SQL [Rig 02].

5.1.2. Application du modèle de données contraintes aux données spatio- temporelles

Nous avons déjà précisé que plusieurs travaux ont étudié l’apport des modèles de données contraintes pour la représentation des objets géométriques placés dans un espace à plusieurs dimensions [RCK+ 00], [GAS 03], [RSS+ 03]. L’application aux données spatio-temporelles et aux objets mobiles devient naturelle en considérant le temps comme une des dimensions. Ainsi, les données spatio-temporelles sont vues comme des objets mathématiques pouvant être analysés avec des outils connus [MSI 02]. Une trajectoire est généralement approximée par une suite de segments connectés deux à deux dans un espace à 3 dimensions. Chaque segment peut ainsi être représenté comme une conjonction de contraintes linéaires utilisant la variable temps (t) et les variables coordonnées. La trajectoire complète est la disjonction de ces contraintes linéaires.

L’interrogation des données spatio-temporelles se fait de la même manière que les données spatiales en utilisant simplement un langage comme SQL et en manipulant des ensembles infinis sans se soucier de la représentation finie (gérée par le modèle).

Prenons à titre d’illustration l’exemple d’un gestionnaire de moyens mobiles qui souhaite connaître l’instant où une ambulance atteint le lieu d’intervention. Soit (x1,y1) les coordonnées du lieu d’intervention.

Soit la relation Trajectoire représentant la position d’une ambulance à chaque instant :

Tajectoire(t,x,y).

La requête s’exprime de la manière suivante :

Select t

From Trajectoire Where x=x1 and y=y1 ;

Aux avantages et inconvénients de ce modèle pour la représentation des données spatiales présentés dans la section 3, nous ajoutons que ce dernier n’est pas adapté aux requêtes spatio- temporelles qui portent sur la position future de l’objet mobile. Malgré quelques efforts fournis [MSI 02], il n’existe pas suffisamment de travaux consacrés à cet aspect.

5.1.3. Modèle basé sur les attributs dynamiques

Sistla et al., ont proposé un modèle appelé MOST (Moving Objects Spatio-Temporal) [SWC+ 97]. Ce modèle a été conçu pour être implémenté au-dessus des SGBD traditionnels. Un prototype a été développé dans le cadre du projet DOMINO (Database fOr MovINg Objects)[WSX+ 99]. L’objectif de ce travail est d’étendre les fonctionnalités des SGBD traditionnels, afin de représenter de manière efficace la position courante des objets mobiles et de pouvoir prédire leurs positions futures. L’originalité de ce travail réside dans l’introduction de la notion d’attributs dynamiques dont les valeurs changent continuellement, sans avoir à les mettre à jour explicitement. Ces attributs sont donc bien adaptés à la représentation de la position des objets mobiles. Ainsi, selon le modèle MOST, les attributs des objets sont soit statiques soit dynamiques. L’objet Ambulances, par exemple, peut avoir des attributs statiques comme l’identifiant ou le volume du véhicule et des attributs dynamiques comme la position représentée par les coordonnées (X,Y). Un attribut dynamique, disons X, est représenté par 3 sous-attributs : X.value : valeur de X au moment de la dernière mise à jour ; X.updatetime : instant de la dernière mise à jour ; X.function : fonction de t qui vaut 0 à t=0. Pour représenter la position d’un objet mobile, cette fonction dépend du vecteur mouvement (e.g. direction, vitesse). A chaque instant (t+X.updatetime), la valeur de l’attribut X est déterminée en calculant

X.value+X.function(t). Avec ce modèle, nous pouvons déduire implicitement les positions

futures de l’objet mobile et répondre ainsi aux requêtes qui portent sur l’état futur de la base de données. Dans [SWC+ 97], un langage FTL (Futur Temporal Logic) permettant d’exprimer ce type de requêtes a été proposé. Aussi, un algorithme d’évaluation prenant en compte en plus les requêtes spatio-temporelles continues a été développé.

Nous donnons ici l’exemple d’une requête exprimée à l’aide de FTL. Supposons qu’un gestionnaire de moyens demande les identifiants de toutes les ambulances qui rentrent dans une région P autour du lieu d’intervention dans les 10 prochaines minutes.

Soit la relation ambulances (id, typeAmb, X_pos).

Pour exprimer cette requête, nous utilisons un opérateur spatial INSIDE(X_pos,P) qui renvoie vrai si un point se trouve dans un polygone et l’opérateur temporel Eventually_Within_C

g qui renvoie vrai si le prédicat g est vrai pendant C unité de temps. Les deux opérateurs sont

définis dans FTL.

Select id

From ambulances

Where Eventually_within_30 INSIDE(X_pos,P);

La possibilité de supporter les requêtes qui impliquent la position future des objets mobiles constitue un des apports majeurs de ce modèle par rapport aux autres. Toutefois, il présente certaines limites. En effet, ce modèle ne gère que la position courante de l’objet mobile et celle du futur proche contrairement aux deux modèles présentés précédemment, qui donnent la possibilité de gérer des trajectoires. En plus, ce modèle nécessite d’être complété par des techniques adaptées, permettant des mises à jour implicites des informations de localisation,

sans trop compromettre leur précision. Nous développons plus ces aspects dans la sous- section suivante.

5.2. Mise à jour de la localisation et incertitude

La notion d’incertitude est très importante dans les bases de données représentant des objets mobiles. En effet, la localisation courante de ces derniers n’est connue qu’avec une précision limitée. De plus, il est difficile d’avoir une connaissance sur leurs positions futures avec des incertitudes limitées. Ceci est dû à la nature continue et parfois imprévisible du mouvement des objets, à l’imprécision des systèmes de positionnement et aux délais de traversée des réseaux. La notion d’incertitude intervient à plusieurs niveaux. Premièrement, concernant la mise à jour de la position courante des objets mobiles, une question très importante se pose : Quelles sont les fréquences de mise à jour permettant d’avoir une incertitude acceptable par l’application sans affecter les performances du système ? Deuxièmement, il est indispensable de prendre en compte la notion d’incertitude au niveau de l’interrogation des données représentant la localisation ou les trajectoires des objets mobiles. Dans ce qui suit, nous allons présenter les travaux qui traitent de ces deux aspects.

5.2.1. Mise à jour de la localisation des objets mobiles

Les premières approches proposées sont basées sur des mises à jour périodiques de la position des objets mobiles (e.g. tous les 2 kilomètres ou toutes les 2 minutes). Ces approches traditionnelles ont l’avantage de borner l’erreur sur les réponses des requêtes, puisque l’incertitude est connue et correspond à la distance entre deux mises à jour [WY 03]. Cette solution est simple à mettre en œuvre et elle répond aux besoins de nombreuses applications commerciales qui n’exigent pas un degré de précision très élevé sur la localisation [Nov 07]. Par exemple, dans le projet Géo Urgence, c’est cette solution qui a été adoptée [Geo 07]. Pour avoir une précision assez élevée sur la localisation, la fréquence de mise à jour doit augmenter considérablement. D’autres politiques de mise à jour visant à réduire le coût des mises à jour et augmenter la précision sur la localisation ont été introduites dans [WJS+ 99]. Ce travail étend le modèle MOST en proposant une technique basée sur la déviation et l’incertitude. L’idée est de mettre à jour la position de l’objet mobile, lorsque la distance entre sa position courante et celle représentée dans la base de données (position calculée par le système cf. sous-section 5.1.3) dépasse un certain seuil d’incertitude (noté th). Cette distance appelée déviation peut être calculée par l’objet mobile (e.g. équipé d’un système GPS). Le choix du seuil d’incertitude est très important. En effet, il s’agit de trouver un compromis entre le coût d’incertitude et celui des mises à jour. Trois méthodes de calcul de ce seuil ont été étudiées. La première considère un seuil fixe. La deuxième change l’incertitude à chaque mise à jour de façon à minimiser le coût de mise à jour, le coût de déviation et le coût d’incertitude. Enfin, la troisième technique prend en compte, en plus, la détection de la déconnexion. Dans [LUL+ 01], les auteurs étudient le rapport entre les politiques de mise à jour des localisations des objets mobiles et la validité des résultats des requêtes continues. La méthode proposée définit des seuils d’incertitude différents pour des objets mobiles différents selon l’impact de cette incertitude sur la validité des résultats. Par exemple, les objets mobiles qui ne sont pas susceptibles de satisfaire aux conditions des requêtes continues en cours de traitement ont un seuil d’incertitude plus large que les autres. Une autre approche s’appuyant sur le calcul de la déviation a été proposée dans [WY 03]. Celle-ci considère que l’itinéraire de l’objet mobile n’est pas connu d’avance (ce qui est une des hypothèses des travaux précédents). Par contre, l’objet mobile est supposé se déplacer sur la même rue ou avenue entre deux mises à jour successives.

5.2.2. Interrogation des données avec incertitude

Il est très important de prendre en compte la notion d’incertitude dans les modèles de données, les langages d’interrogation et les modèles d’exécution des requêtes. Dans [WJS+ 99], le résultat d’une requête invoquant la localisation courante ou future de l’objet mobile implique la notion de surface d’incertitude (e.g. la surface d’un cercle autour de la position calculée par le système de rayon l’incertitude th). Dans le cas des SGBD représentant les trajectoires des objets mobiles, le problème de gestion de l’incertitude est plus complexe. Dans [PJ 99], les auteurs s’intéressent à l’incertitude due à l’échantillonnage et à l’imprécision du système GPS. Ils proposent une méthode permettant de quantifier l’incertitude dans la modélisation des objets mobiles. Leur approche permet de limiter l’incertitude sur le mouvement passé de l’objet, mais l’erreur devient plus grande lorsqu’on s’approche du moment présent. Un autre travail considérant l’incertitude sur les trajectoires des objets mobiles a été proposé dans [TWH+ 04]. Les auteurs proposent de modéliser la trajectoire d’un objet mobile comme un volume cylindrique dans un espace 3D. Ce modèle incorporant l’incertitude facilite l’interrogation des données et l’extension des langages par de nouvelles modalités (e.g. sometimes, always, possibly). Ainsi, de nouveaux opérateurs ont été spécifiés et leurs algorithmes d’évaluation ont été fournis.