Infrastructure de stockage et de manipulation des données de trajectoires

FACULTÉ DES SCIENCES DÉPARTEMENT D INFORMATIQUE Infrastructure de stockage et de manipulation des données de trajectoires Michel FOÉ Directeur : Prof. Esteban ZIMÁNYI Mémoire présenté en vue de l obtention du grade de Master en Sciences Informatiques Année académique 2011 2012

A mon fils Mathis, que ce mémoire suscite en lui la soif de connaissances.

Remerciements Je tiens à remercier sincèrement Monsieur Esteban Zimanyí, mon Directeur de mémoire, qui m a honoré de sa confiance en acceptant de me confier ce sujet, pour sa grande disponibilité et son encadrement patient, ces deux dernières années à l ULB. Je voudrais également remercier Messieurs Thierry Massart et Stijn Vansummeren, membres de mon jury de mémoire, pour avoir accepté de prendre connaissance et d évaluer ce travail. Je souhaite ensuite exprimer ma gratitude au Professeur Ralf Hartmut Güting de l Université de Hagen en Allemagne, pour ses éclairages au sujet du jeu de données du BerlinMOD. En dehors de l univers académique, je voudrais exprimer ma reconnaissance à ma famille, particulièrement à mes parents qui, malgré l adversité, n ont jamais menagé des efforts pour mon éducation. Je remercie particulièrement ma compagne Nadine, pour ses encouragements et son soutien constants. Mes sentiments vont à l endroit de mes amis Louis-Marie, Gilles, Alain, Joseph, Franck, Salomon, Arielle et Géraud, pour avoir accepté de parcourir cet ouvrage, pour leurs judicieuses remarques et critiques. Enfin, que tous ceux qui, de près ou de loin ont contribué de quelque façon que ce soit à l aboutissement de ce travail et surtout à mon projet de reprendre les études après cinq années d inactivité académique, trouvent en ce mémoire, une récompense pour leurs efforts et encouragements.

Table des matières 1 Introduction 1 1.1 Contexte.................................... 1 1.2 Problématique................................ 2 1.3 Objectifs du mémoire............................ 2 1.4 Structure du mémoire............................ 2 2 Concepts de base des trajectoires 4 2.1 Introduction.................................. 4 2.2 Trajectoires.................................. 5 2.3 Caractéristiques des trajectoires....................... 6 2.3.1 Caractéristiques à un instant.................... 6 2.3.2 Caractéristiques à une période................... 6 2.4 Aspect spatial des trajectoires........................ 7 2.4.1 Système de coordonnées....................... 7 2.4.2 Structuration de l espace...................... 8 2.5 Aspect temporel des trajectoires...................... 8 2.5.1 Domaine temporel.......................... 9 2.5.2 Cycles de temps........................... 9 2.5.3 Dimension temporelle........................ 10 2.5.4 La norme ISO/IEC 9075 (SQL-2011)................ 11 2.6 Des données brutes aux trajectoires..................... 13 2.6.1 Méthodes d interpolation...................... 13 2.6.2 Notions d incertitude......................... 16 2.7 Conclusion.................................. 17 3 Modélisation et systèmes de gestion de données de trajectoires 19 3.1 Modélisation des données de trajectoires.................. 19 3.1.1 Modèle de données spatio-temporelles............... 19 3.1.2 Le modèle de données avec contraintes............... 26 3.1.3 Le modèle de données d objets mobiles.............. 29 3.2 Systèmes de gestion de données de trajectoires.............. 34 3.2.1 SECONDO.............................. 34 3.2.2 Hermes................................ 36 4 Hermes dans PostgreSQL 9 39 4.1 Introduction.................................. 39 4.2 PostgreSQL 9................................. 40 4.2.1 Méthodologie de développement d une extension......... 40 i

ii 4.2.2 Environnement de développement de l extension......... 40 4.2.3 Règles à respecter lors de l utilisation du compilateur C++... 41 4.3 Hermes dans PostgreSQL 9......................... 42 4.3.1 Module spatial : PostGIS...................... 42 4.3.2 Module temporel : TAU-TLL.................... 45 4.3.3 Module spatio-temporel....................... 51 4.4 Light Hermes (Lhermes)........................... 55 4.4.1 Insuffisances de Hermes....................... 55 4.4.2 Temporal PostgreSQL........................ 56 4.4.3 Type de données dans Lhermes................... 57 4.4.4 Fonctions de Lhermes........................ 58 5 Cas d utilisation de Lhermes 59 5.1 Introduction.................................. 59 5.2 Présentation du BerlinMOD......................... 59 5.2.1 Description du jeu de données.................... 59 5.2.2 Relations et requêtes......................... 60 5.3 Méthodologie de test............................. 61 5.4 Requêtes et résultats............................. 61 5.5 Synthèse et analyse des résultats...................... 71 5.6 Analyse.................................... 71 5.6.1 Au niveau de la représentation physique des types de données.. 73 5.6.2 Au niveau de l indexation...................... 73 6 Conclusion 74 6.1 Contributions................................. 74 6.2 Perspectives.................................. 75 A Types de données de Lhermes 76 B Configuration de l environnement de développement 78 B.1 Configuration au niveau de visual C++.................. 78 B.2 Configuration au niveau de PostgreSQL.................. 79

Table des figures 2.1 Une trajectoire en gégographie temporelle [40]............... 4 2.2 Relation instantanée [16]........................... 10 2.3 Relation à temps valide [16]......................... 10 2.4 Relation à temps transactionnel [16].................... 11 2.5 Relation bitemporelle [16].......................... 11 2.6 Interpolation linéaire [4]........................... 14 2.7 Interpolation utilisant des courbes de Bezier [4].............. 15 2.8 Incertitude d interpolation dans l espace [10]................ 17 2.9 Incertitude d interpolation dans l espace-temps [10]............ 17 2.10 Zone de définition de trajectoire [42].................... 18 3.1 Données vectorielles : abstractions de base [18].............. 21 3.2 Une partition [18]............................... 21 3.3 Un réseau [18]................................. 22 3.4 Exemple de modélisation avec STER [43]................. 24 3.5 Ecran de modélisation spatio-temporelle dans PERCEPTORY [5].... 25 3.6 MADS : Types de données abstraits spatiaux [31]............. 26 3.7 MADS : Types de données abstraits temporels [31]............ 26 3.8 Objet spatio-temporel trajectoire [10]................... 27 3.9 Attribut spatio-temporel trajectoire [10].................. 27 3.10 Trajectoire dans ISO/TC211 [10]...................... 28 3.11 Représentation d un moving real [12].................... 32 3.12 Moving point (a) et moving region (b) dans l espace-temps [16]..... 32 3.13 Représentation en tranches d un moving real [12]............. 34 3.14 Représentation en tranches d un moving point [12]............ 34 3.15 Architecture de SECONDO [41]...................... 36 3.16 Architecture de types dans Hermes [28].................. 38 3.17 Diagramme de classe de Hermes-MDC [28]................. 38 4.1 Diagramme de classes des types dans PostGIS [29]............ 43 4.2 Représentation en tranches d un Moving-Point dans Hermes-MDC [28] 52 4.3 Projection d un moving point dans le domaine temporel......... 55 5.17 Comparaison des coûts d exécution sur Lhermes et SECONDO..... 72 iii

Chapitre 1 Introduction 1.1 Contexte La question de la gestion des données issues de l observation des entités mobiles a suscité un intérêt particulier au sein de la communauté scientifique du domaine des bases de données ces dernières années. Cet intérêt se justifie par les énormes avancées observées avec l avènement d une multitude de technologies et d outils qui permettent d assurer techniquement et à moindre coût, la traçabilité d un objet en mouvement. Parmi ces technologies, on retrouve les systèmes de géolocalisation Global Positioning System (GPS) et Galileo, les technologies RFID (Radio Frequency IDentification), qui permettent de suivre l évolution à l aide d un marqueur embarqué ou implanté sur l entité en mouvement et enfin des technologies de communication sans fils (GSM, WIFI, WIMAX, BLUETOOTH, etc.). Cette facilité à pouvoir tracer des objets mobiles a ouvert la voie à une large gamme d applications dans des domaines aussi variés que la mobilité urbaine ou inter-urbaine, la logistique, l anthropologie ou l écologie. On peut citer : les applications de type Location Based Services, qui permettent aux utilisateurs d équipements mobiles (Smart Phone, tablettes, PDA, GPS, etc.) d accéder à un certain nombre de services (publicité ciblée, localisation de l hôtel ou du restaurant le plus proche, informations de trafic en temps réel, etc.) en fonction de l endroit où ils se trouvent ; l observation de travailleurs urbains se rendant à leur lieu de travail en utilisant divers moyens de transport ; le contrôle des déplacements d une flotte de camions d une entreprise dans une région donnée ; le suivi des animaux dans des aires protégées ; l étude du mouvement migratoire de certains oiseaux à la recherche de meilleures sources d alimentation ; ou l évolution comparée de la population de deux communes dans le temps. Ces applications génèrent un volume important de données représentant l historique des positions successivement occupées par le phénomène en observation. Ces données sont appelées données de trajectoire. Dès lors, il devient impératif de disposer d une infrastructure permettant le stockage et l interrogation de ce type de données en vue de leur interprétation, étant donné que les systèmes de gestion de base de données classiques n offrent pas ou offrent partiellement de telles fonctionnalités. 1

2 1.2 Problématique L augmentation du nombre d applications générant des données sur le mouvement des objets contraste avec le nombre de systèmes de gestion de base de données (SGBD) existants, offrant des fonctionnalités pour le stockage et la manipulation des données de ce type. Si dans le cadre de la recherche, des prototypes ont été développés, notamment [41, 33], il existe un besoin réel pour ce qui est de l extension des systèmes de gestion de base de données commerciaux ou open source, afin de les doter de la capacité de prendre en compte la gestion des données de trajectoire. En outre, en amont de la gestion au niveau des bases de données, il se pose un problème de modélisation de ce type de données. En effet, l un des centres d intérêt dans la manipulation des données issues de la mobilité des objets est la sémantique au niveau conceptuel qu il faut assigner à ce type de données : doivent-elles être représentées comme des types à part entière au sens langage de programmation (first class object), pour un SGBD donné? C est-à-dire qu on puisse déclarer des variables de type trajectoire, avoir des fonctions qui prennent en paramètre des variables de ce type ou qui renvoient des valeurs de ce type. Ou alors doit-on construire les types de données trajectoire par composition ou transformation, au moyen de requêtes ou d opérations sur des données brutes, collectées à l aide de capteurs et organisées en un flot de positions historisées? 1.3 Objectifs du mémoire Ce mémoire s inscrit dans la dynamique d extension des systèmes de gestion de base de données courants, afin de les doter de la capacité de stocker et d interroger des données issues d entités en mouvement(données de trajectoire). Ce mémoire a un double objectif : dans un premier temps, il sera question de faire une revue critique et structurée de la littérature scientifique en matière de gestion des données de trajectoire. Ensuite, proposer sous la forme d une extension, une insfrastructure pour la gestion des données de trajectoire pour le SGBD open source PostgreSQL qui offre des facilités en ce qui concerne le développement de nouvelles extensions et une stabilité proche de celle des leaders commerciaux dans le domaine notamment Oracle. 1.4 Structure du mémoire Le mémoire est composé de six chapitres dont cette introduction. Le chapitre 2 est consacré à la définition et à la formalisation des concepts de base nécessaires à la compréhension du sujet traité et utilisés dans la suite du travail. Ce chapitre introduit le chapitre 3, qui fait une revue de la littérature actuelle en matière de modélisation et de conception des systèmes de gestion des données de trajectoire. Au chapitre 4, nous présentons notre infrastructure de gestion de données de trajectoire pour le SGBD PostgreSQL 9. Cette infrastructure est basée sur Hermes-MDC, une cartouche spatio-temporelle développée à l origine pour le SGBD Oracle. De précédents travaux de migration de Hermes-MDC vers PostgreSQL 8, ont été effectués au sein du service WIT 1 de l école polytechnique de l ULB. Ces travaux constituent les fondements de notre extension ; nous présentons également dans ce chapitre, une version légère d Hermes dite Light Hermes, présentant des performances intéressantes (indexation, occupation de l espace disque, etc.) par rapport au prototype initial issu de la migration depuis Oracle. Ces performances seront 1. Web and Information Technology

évaluées au chapitre 5 grace au benchmark BerlinMOD, un test de performance basé sur un jeu de données issu de la simulation d une étude de la mobilité dans la ville de Berlin en Allemagne. Le chapitre 6 conclura notre travail et présentera des axes d amélioration de l extension actuelle. Deux annexes sont également fournies, la première contient des extraits essentiels de code source de notre travail et la deuxième annexe est un tutoriel de configuration d un environnement de développement des extensions de PostgreSQL sous Microsoft Visual C++. L objectif de ce guide de configuration est de donner à tout lecteur intéressé par le développement d extensions pour PostgreSQL dans un environnement Windows, le moyen d avoir rapidement un environnement de développement opérationnel. Ceci lui permettrait de gagner en temps et de se focaliser sur le problème de fond qu est le développement des différentes fonctionnalités de son extension. Quand il est vrai qu à notre connaissance une telle documentation n avait jusqu alors pas été publiée. 3

Chapitre 2 Concepts de base des trajectoires 2.1 Introduction Torsten Hägerstrand pionnier de la géographie temporelle, ancêtre de l étude actuelle des objets en mouvement, émet l hypothèse de l indissociabilité de l espace et du temps dans l observation d un objet mobile[19]. En effet, Hägerstrand représente la trajectoire d un objet en mouvement dans un espace à trois dimensions de la manière suivante : les deux axes horizontaux représentent l espace et l axe vertical représente le temps. Cette idée est reprise par Spaccapietra et al. dans [40] comme l illustre la figure 2.1. Figure 2.1 Une trajectoire en gégographie temporelle [40] La trajectoire est représentée par une polyligne(ou courbe) dont les segments (fragments de courbe) correspondent aux différentes phases du mouvement. Un segment perpendiculaire au plan (espace) correspond à un arrêt ou stop. Definition 1 Un stop est la partie de la trajectoire telle que l intervalle de temps entre le début et la fin du stop est non vide et l objet occupe la même position dans l espace au cours de cet intervalle [40]. Dans la figure 2.1, les positions P 1 et P 3 représentent des stop. Ainsi, dans le cadre de l observation d un travailleur urbain, le travailleur, initialement à son domicile se rend à son lieu de travail et y reste jusqu à la fin du 4

5 service. Ensuite, il se met sur le chemin du retour et s arrête au supermarché où il passe un certain temps avant de reprendre la route vers son domicile. Le lieu de travail et le supermarché correspondent à des stop. Les segments obliques à l axe du temps correspondent à des déplacements ou move, plus la pente est raide moins rapide est le mouvement. Definition 2 Un move est la partie de la trajectoire telle que l intervalle de temps entre le début et la fin du move est non vide et l objet mobile occupe des positions distinctes dans l espace au cours de cette période de temps [40]. Un move est délimité de part et d autre par des stop ou alors une de ses extrémités est le début ou la fin de la trajectoire et l autre est un stop. Le fait que certaines parties de la trajectoire soient représentées par des segments de droite suppose que l entité se déplace à vitesse constante sur ces parties, ce qui n est pas toujours le cas en pratique. Ceci n est rien d autre qu une approximation de la situation réelle par soucis de simplicité. Bien que les outils et les technologies pour observer, collecter, représenter et analyser les données de trajectoire aient évolué, les concepts de base qui sous-tendent l étude des objets en mouvement, restent les mêmes que ceux utilisés dans les études anciennes. Dans ce chapitre, nous essayerons de formaliser ces concepts. Plus précisément, nous parcourerons la littérature existante à ce sujet pour donner au lecteur non averti une définition des concepts essentiels que sont : les trajectoires, l espace, le temps, le spatiotemporel et d autres notions qui ont un intérêt dans l étude de la mobilité des objets. 2.2 Trajectoires Un mouvement se définit comme un changement de position (physique) dans un référentiel donné où la notion de position est clairement définie [4]. Dans le cadre de l étude des entités en mouvement, ce référentiel est généralement un référentiel géographique. Une trajectoire est l ensemble des positions successives occupées (ou chemin décrit) dans l espace, par une entité en mouvement. Une trajectoire est généralement décrite dans un intervalle de temps donné, ceci consacre le caractère indissociable entre la notion de trajectoire et celle de temps. En effet, si t begin est l instant de début du mouvement et t end l instant de fin, alors pour tout instant t i compris entre t begin et t end, il existe une position occupée par le mobile à cet instant dans le référentiel considéré. De cette façon, une trajectoire peut être vue comme une fonction qui associe chaque instant du mouvement à une position dans l espace. trajectoire : [t begin, t end ] espace On peut alors définir des paires (instant, position) pour collecter des données de trajectoire. Etant donné que la notion de temps est continue, il existe une infinité de telles paires pour représenter une trajectoire. En pratique, une trajectoire sera représentée par un nombre fini de paires (instant, position). Cette représentation sera fonction de la décision prise au moment de la collecte des données de position. Une telle décision est choisie parmi celles proposées ci-dessous : le prélèvement des données de position s effectue à intervalle de temps régulier, par exemple toutes les deux secondes ; le prélèvement est effectué lorsque l entité change de positions dans le référentiel ;

6 le prélèvement est basé sur la position de l entité par rapport à un point fixe, par exemple un capteur installé à un endroit ; le prélèvement est effectué lorsque survient un évenement donné ; ou toute combinaison des méthodes précédentes. Definition : Formellement, une trajectoire T est le graphe de la fonction de I R R 2 (l espace de dimension 2 ou plan) défini comme suit : I R R 2 : t α(t) = (α x (t), α y (t)) Ainsi, T = {(α x (t), α y (t), t) t I} R 2 R 2.3 Caractéristiques des trajectoires L observation de la trajectoire d un objet mobile permet de définir des caractéristiques qui aident à analyser le mouvement. Ces caractéristiques peuvent être regroupées en deux catégories. Les caractéristiques à chaque instant du mouvement et les caractéristiques pendant une période de temps ou l ensemble du mouvement. 2.3.1 Caractéristiques à un instant Une trajectoire est le chemin composé de l historique des positions successives par lesquelles passe une entité en mouvement. Les caractéristiques de trajectoire à un instant t i [t begin, t end ] correspondent aux informations qui décrivent une position du chemin de façon individuelle. De telles informations comprennent : la position de l instant à l échelle du temps ; la position de l objet dans l espace ; le sens du mouvement de l objet ; la vitesse du mouvement à l instant ; l accélération du mouvement à l instant ; la distance parcourue et le temps de parcours depuis le début du mouvement. 2.3.2 Caractéristiques à une période Les caractéristiques de trajectoire à une période donnée correspondent aux informations qui décrivent la trajectoire dans un intervalle de temps [t 1, t 2 ] [t begin, t end ] ou dans l entièreté de la période [t begin, t end ] couvrant toute la durée du mouvement. De telles caractéristiques comprennent : la forme géométrique décrite par tout ou partie de la trajectoire dans l espace pour la période donnée ; la distance parcourue c est à dire la longueur correspondante du fragment de trajectoire ou de la trajectoire entière dans l espace ; la durée du parcours ; le sens global du mouvement entre les deux extrémités de l intervalle de temps ; les valeurs moyenne, médiane et maximale de la vitesse ; le type de mouvement en fonction de la valeur de l accélération dans la période donnée : vitesse constante (accélération nulle) ;

7 mouvement accéléré (accélération positive) ; mouvement décéléré (accélération négative) ; la nature du mouvement en terme de direction : mouvement rectiligne ; mouvement curviligne ; mouvement circulaire. Il ressort des sections précédentes que la notion de trajectoire est intimement liée à celles d espace et de temps. Dès lors il nous parait judicieux de définir ces deux concepts, certes familiers, mais qui peuvent avoir une connotation particulière dans l étude des mouvements. c est ce que nous nous attélerons à faire dans les sections suivantes, dans un premier temps nous définirons la notion d espace dans le contexte des trajectoires, ensuite nous nous focaliserons sur la notion de temps. 2.4 Aspect spatial des trajectoires L espace est l ensemble des lieux (ou emplacements) et leurs relations [6]. Une propriété fondamentale de l espace est l existence de distances entre ses éléments. Cependant, l espace n a pas d origine c est-à-dire qu il n existe pas un lieu central à partir duquel sont organisés ses éléments, de même qu il n existe pas une relation d ordre entre ces derniers. Pour pouvoir distinguer les différents lieux, il est nécessaire d introduire un système de référence, par exemple le système de coordonnées dont l un des plus utilisés est le système de coordonnées géographiques. Lorsque l on utilise un système de coordonnées pour distinguer les éléments de l espace, il peut être nécessaire d introduire la notion de dimension qui renvoie au nombre de composantes nécessaires pour représenter un lieu. 2.4.1 Système de coordonnées En fonction des exigences, un lieu de l espace peut être représenté en deux dimensions c est-à-dire par une paire de coordoonnées comme c est le cas dans un plan cartésien (coordonnées cartésiennes) ; en trois dimensions (le lieu est représenté par trois coordonnées). Dans ce cas la troisième dimension peut être utilisée pour fournir une information supplémentaire sur la position, on va par exemple ajouter la composante altitude à des coordonnées géographiques (longitude, altitude). Dans certaines situations aussi, une seule coordonnée suffira pour représenter un lieu ; c est le cas par exemple, lors de l observation du mouvement d un objet sur un axe marqué (bornes kilométriques sur une route par exemple), la position courante du mobile peut être déterminée en fonction de la distance parcourue depuis l origine de l axe. Si les trois notions de dimension définies précédemment se réfèrent à l espace physique, théoriquement il est possible de parler d une représentation de l espace avec plus de trois dimensions. Une telle représentation décrit l espace au sens purement abstrait d où le terme : espace abstrait et peut être utile dans certains cas. Par exemple, dans le cadre de l étude de l évolution de la démographie dans une commune, un analyste peut être intéressé par plusieurs axes (dimensions) de l évolution temporelle de la population. Par exemple, le nombre d habitants, le nombre d enfants scolarisés dans la commune, l âge moyen, la densité, etc. Tous ces critères constituent des dimensions dans l évolution temporelle de la population (espace).

8 2.4.2 Structuration de l espace L espace physique est continu voir infini. Celà signifie que quelque soit le système de coordonnées ou de référence utilisé, en prenant deux lieux distincts de l espace, aussi petite soit la distance entre ces deux lieux, il est toujours possible de situer un point entre eux. Cependant, dans certaines situations il est tout à fait possible voir indispensable de discrétiser ou de réduire l espace à un ensemble fini de lieux. La discrétisation de l espace est nécessaire par exemple lorsque la localisation des lieux ne peut pas se faire (ou est sans intérêt) de façon précise. On peut par exemple imaginer la situation où les coordonnées sont des valeurs réelles et qu on ait besoin d un niveau de précision que les instruments de mesure utilisés ne permettent pas d obtenir ou bien le suivi de l évolution du parcours d un touriste dans une ville ou une région, dans ce cas l espace représentant la ville ou la région peut être réduit aux seuls lieux d intérêt visités par le touriste ou aux réseaux routiers et de téléphonie mobile. Il est dès lors possible de représenter l espace de façon structurée en particulier par division en zones. Une telle division pourra se faire de manière hiérarchisée ; par exemple un pays est divisé en départements, un département en communes, une commune en districts ainsi de suite. En définitive, tout comme le système de coordonnées, la structuration de l espace permet de distinguer ses différents éléments (lieux). On peut donc résumer comme suit, les différentes approches pour localiser un objet dans l espace : en utilisant un système de coordonnées, c est-à-dire que chaque lieu est décrit par un tuple de nombres, correspondant à la distance linéaire ou angulaire, par rapport à certains axes choisis comme référence. Le système de coordoonnées géographique en est une illustration ; la deuxième possibilité est basée sur la division de l espace en zones éventuellement hiérarchiques ou sur la base d un réseau (réseau routier, réseau de téléphonie mobile, etc.) ; enfin, il est possible d utiliser un système de référence linéaire qui n est rien d autre qu une réduction de la notion de coordonnées, à une dimension. En effet, il est tout à fait possible de localiser un lieu en utilisant sa position relative sur un objet perçu comme une droite (rivière, rue, route, etc.). Dans ce cas, pour déterminer la position de l objet mobile, on associe l identifiant de la route ou de la rivière à la distance parcourue dépuis l une des extrémités. La deuxième notion fondamentale attachée aux trajectoires est la notion de temps. Dans la section qui suivra, nous essayerons tout comme avec l espace de comprendre les différents concepts liés au temps et à sa représentation. 2.5 Aspect temporel des trajectoires Le temps est un ensemble infini (continu), constitué d éléments ordonnés linéairement et dont l une des propriétés fondamentales est l existence de distances entre les éléments. Un élément correspond à un instant ou moment de l axe du temps. De façon similaire à l espace, il est nécessaire de disposer d un système de référence pour pouvoir représenter la notion de temps dans des données. Le système de référence généralement utilisé est le calendrier Grégorien associé à une notion de granularité qui permet la division du temps en plusieurs niveaux : les années en mois, des mois en jours, des jours en heures, des heures en minutes et des minutes en secondes. On peut indiquer une heure précise de la journée en se référant à l heure locale (basée sur le fuseau horaire de la région) où

9 les données sont collectées ou en se référant au temps universel (Greenwich Mean Time - GMT). Dans certains cas cependant, il peut être intéressant de spécifier les instants d échantillonnage des données de façon relative, par exemple par rapport au temps écoulé dépuis le début de l échantillonnage ou de façon abstraite en utilisant une numérotation chronologique à partir d un instant initial. De cette façon, le temps peut être vu comme un ensemble fini discret et cette conception du temps contraste avec la conception du temps physique, reconnu comme continu. 2.5.1 Domaine temporel Comme évoqué précédemment, le domaine temporel peut être perçu comme borné ou infini. Cependant, quelque soit la perception adoptée, le domaine temporel est un espace à une dimension qui s étend du passé au futur. Dès lors, le domaine temporel peut être modélisé comme suit [16] : de façon isomorphe à l ensemble des entiers naturels, auquel cas on parle de temps discret ; de façon isomorphe à l ensemble des nombres rationnels, auquel cas on parle de temps dense ; ou de façon isomorphe à l ensemble des réels, auquel cas on parle de temps continu. Une autre perception du domaine temporel considère le temps de façon absolu (par exemple : 14-03-2012 12 :43 :25 ) ou de façon relative (par exemple : il y a deux semaines). Toutes ces approches partagent cependant les mêmes concepts temporels représentés par l ontologie suivante : instant, représentant un chronon (moment précis du temps) ou point sur la ligne du temps (exemple :14-03-2012 12 :43 :25 ) ; periode, représentant un intervalle d instants ancré (que l on peut situer précisément) sur la ligne du temps (exemple : [14-03-2012 12 :43 :25, 14-03-2012 12 :43 :26)) ; intervalle, représentant une durée non ancrée mais orientée, de la ligne du temps (exemple : [12-43-25, 12 :43 :26)) ; périodes, représentant un ensemble d objets de type periode. A cette ontologie, il faut ajouter les types standards Date, Time et Timestamp de la norme SQL-92. 2.5.2 Cycles de temps Lorsqu on s intéresse au temps comme domaine continu (comme c est le cas dans l étude des objets mobiles), on constate que quelque soit le niveau de précision imposé, il est impossible de pouvoir recueillir des échantillons de données à tous les instants de l axe du temps. En effet, pour deux instants d échantillonnage sucessifs t 1 et t 2, il existe toujours entre ces deux instants, un instant t où les données n ont pas été prélevées. Dès lors, le seul moyen de savoir ce qui s est passé à l instant t est de faire une estimation grace à la technique de l interpolation présentée à la section 2.6.1. Lors de l observation de la trajectoire d une entité, il est particulièrement important de bien définir à quelle fréquence les données sont prélevées. Cette fréquence définit les cycles temporels qui permettent de préléver des données de localisation qui sont pertinentes pour l analyse du phénomène observé. Ainsi, le prélèvement de la position d un véhicule en mouvement dans les rues d une ville toutes les 2 secondes a du sens dans l analyse des données

10 puisqu on observe une différence de localisation raisonnable dans son mouvement ; alors que le prélèvement des mêmes données par exemple toutes les deux minutes peut être source d erreurs, en ce sens qu en 2 minutes et en fonction de sa vitesse, le véhicule peut parcourir une distance considérable : en résultera une trajectoire très approximative. 2.5.3 Dimension temporelle Lorsqu on stocke des données issues de l observation d un phénomène dans une base de données, il existe toujours un décalage entre le moment où les données sont prélevées et le moment où les données sont prises en compte dans la base de données. Ce décalage introduit la notion de dimension temporelle qui définit le temps de transaction et le temps de validité. le temps de validité d un phénomène correspond au moment où un fait est vrai dans le monde réel ; le temps de transaction représente le moment où un fait est vrai dans la base de données. Les deux notions (dimensions) présentées précédemment son orthogonales : celà signifie qu une donnée sera dite temporelle au sens du temps de validité, si seule son temps de validité est pris en compte. Elle sera dite temporelle au sens du temps de transaction si elle ne prend en compte que le moment du stockage de la donnée dans la base. On parlera de donnée bitemporelle lorsque les deux aspects seront pris en compte. A ces concepts correspondent des systèmes de gestion de base de données particuliers [16] : les bases de données instantanées : celles qui prennent en compte uniquement l état courant du monde réel. Ce type de SGBD ne gère pas l historique des données. La grande majorité des SGBD appartiennent à cette catégorie. La figure 2.2 présente un exemple de relation dans une base de données instantanée.dans cette figure, la représentation de la relation par un tableau à une dimension symbolise la non prise en compte de l historique du phénomène représenté. Figure 2.2 Relation instantanée [16] les bases de données temps valide : ce sont des SGBD qui stockent les données dont seul le temps de validité est pertinent. La figure 2.3 présente une relation à temps valide avec quatre tuples ; On y constate par exemple que le quatrième tuple n est plus valide à l instant courant, alors qu il l a été à de précédents instants. Figure 2.3 Relation à temps valide [16]

11 les bases de données à temps transactionnel : stockent les données dont le temps de transaction est pertinent. La figure 2.4 illustre l évolution d une relation en fonction du temps de transaction. Au départ, une première transaction insère trois tuples dans la relation, ensuite une deuxième transaction insère un quatrième tuple ; à la fin, la troisième transaction supprime le deuxième tuple et insère un autre tuple. On constate ici qu on peut aisément accéder à l historique de la donnée. Figure 2.4 Relation à temps transactionnel [16] les bases de données bitemporelles : elles ont la particularité de gérer les données dont les deux dimensions (temps de validité et temps transactionnel) sont importantes. La figure 2.5 illustre une relation dans une base de données bitemporelles : Figure 2.5 Relation bitemporelle [16] 2.5.4 La norme ISO/IEC 9075 (SQL-2011) Le standard ISO/IEC 9075 est la nouvelle spécification du langage SQL dépuis Décembre 2011 [3]. Entre autres innovations, cette norme étend la norme SQL-92 (qui a introduit les concepts de base de la gestion du temps dans le langage SQL : Date, Time et Timestamp), avec de nouvelles fonctionnalités pour le support temporel dans SQL. Ces fonctionnalités sont principalement [25] : la prise en charge des colonnes de type Period dans des tables dites (Applicationtime period tables). Dans ce type de tables, on introduit deux champs supplémentaires start-time et end-time qu on encapsule dans une clause PERIOD pour créer une variable permettant à l utilisateur (l application ou le développeur) de gérer le cycle de vie (historicité) d un tuple. Les valeurs start-time et end-time sont mises à jour par l utilisateur. La norme définit également une syntaxe riche, permettant notamment à l utilisateur d ajouter des contraintes de clé primaire sur la variable de type Period, pour éviter par exemple que des périodes se chevauchent lorsqu on met à jour start-time et end-time pour une ligne ou lorsqu on insère une nouvelle ligne. Ce type de tables permettent d implémenter les bases de données temps valide introduites à la section précédente. Le listing SQL suivant

12 présente un extrait de code qui définit une table Application-Time Period employees, possédant une variable de type Period nommée (emp period), construite à partir d une clause PERIOD sur les colonnes start date et end date. On peut voir dans ce listing, la syntaxe de la définition de la clé primaire sans chevauchement (PRIMARY KEY WITHOUT OVERLAPS) sur la paire (emp name, emp period), qui empêche tout chevauchement de période lors de la mise à jour des champs start date et end date. Une contrainte de clé étrangère sur la période de validité du département en référence à la période pendant laquelle l employé est supposé y avoir travaillé est aussi définie. CREATE TABLE employees( emp_name VARCHAR(50) NOT NULL PRIMARY KEY, dept_id VARCHAR(10), start_date DATE NOT NULL, end_date DATE NOT NULL, PERIOD FOR emp_period (start_date, end_date), PRIMARY KEY (emp_name, emp_period WITHOUT OVERLAPS), FOREIGN KEY (dept_id, PERIOD emp_period) REFERENCES departments (dept_id, PERIOD dept_period)); l introduction des tables à temporalité système (System-versioned tables), qui sont des tables dont l historique est automatiquement gérée par le système (SGBD). En effet, contrairement aux Application-Time Period Table où c est l utilisateur qui nomme explicitement la variable Period et gère ses mises à jour, dans les System-versioned tables la clause PERIOD utilise une variable implicite nommée SYSTEM TIME. La variable SYSTEM TIME utilise également deux colonnes system start et system end qui sont mises à jour automatiquement par le système lui même. Cette nouvelle fonctionnalité permet d implémenter les bases de données à temps transactionnel. Le listing suivant présente la création d une table System-versioned employees. La colonne system start est automatiquement créée lors de l insertion, de la suppression ou de la mise à jour d une ligne donnée et sa valeur est automatiquement fixée au temps de transaction (clause GENERA- TED ALWAYS AS ROW START) ; au même moment la valeur de system end est fixée au plus grand Timestamp supporté par le système. Plus tard, sa valeur est positionnée au temps de transaction lorsque survient un évènement qui crée une nouvelle ligne. CREATE TABLE employees (emp_name VARCHAR(50) NOT NULL, dept_id VARCHAR(10), system_start TIMESTAMP(6) GENERATED ALWAYS AS ROW START, system_end TIMESTAMP(6) GENERATED ALWAYS AS ROW END, PERIOD FOR SYSTEM_TIME (system_start, system_end), PRIMARY KEY (emp_name), FOREIGN KEY (dept_id) REFERENCES departments (dept_id); )WITH SYSTEM VERSIONING; l association des deux concepts (application-time period tables et system-versionned tables), dans une nouvelle fonctionnalité appelée System-versioned application-

13 time period tables, permettant d implémenter les bases de données bitemporelles (prise en compte des temps de validité et de transaction). 2.6 Des données brutes aux trajectoires Bien que de façon intuitive, une trajectoire se définit comme une fonction qui associe chaque instant du mouvement à une position dans l espace géographique, ses description, représentation et manipulation ne sont pas aussi évidentes au niveau des applications informatiques notamment dans les systèmes de gestion de bases de données. En effet, d un point de vue applicatif, une trajectoire correspond à l ensemble des positions successivement occupées par un objet en mouvement à des instants spécifiques. Par conséquent, bien que l on puisse naturellement penser à une représentation de la trajectoire d un objet sous la forme d une simple courbe de fonction, la réalité est tout autre en ce sens que la simple courbe doit être construite à partir de l ensemble des positions collectées (données brutes) en appliquant des techniques d interpolation. Et quelque soit la méthode d interpolation utilisée, la courbe obtenue n est qu une approximation de la trajectoire réelle de l objet prise parmi une infinité de trajectoires candidates. Par ailleurs, cette trajectoire candidate choisie peut être mauvaise si on tient compte des éventuelles erreurs qui sont inévitablement apparues lors du prélèvement des différentes positions. Il y a par conséquent, une notion d incertitude qu il faut associer aux trajectoires. Cette incertidtude étant liée soit au prélèvement des positions du mobile, soit à la méthode d interpolation utilisée pour construire la trajectoire. Dans cette partie, nous nous intéressons à la façon dont les données brutes, issues de l historique des positions de l objet mobile, sont transformées en trajectoire et représentées dans une base de donnée. Nous allons principalement nous intéresser aux différentes méthodes d interpolation utilisées à cette fin. 2.6.1 Méthodes d interpolation En section 2.2, nous avons défini formellement une trajectoire T, comme l ensemble des positions représentées par des triplets formés des coordonnées dans l espace géographique (abscisse et ordonnée) et de l instant t correspondant au moment où ces coordonnées sont prélevées : où T = {(α x (t), α y (t), t) t I} R 2 R α(t) = (α x (t), α y (t)) La première conséquence de cette définition est que toute trajectoire construite à partir d un ensemble de positions ne contient que des positions de cet ensemble. C est-à-dire, pour toute position (x i, y i, t i ) collectée, nous avons : (x i, y i, t i ) = (α x (t i ), α y (t i ), t i ) ; en d autres termes, lors de la construction de la trajectoire, toute position prélevée (données brutes) correspond à une position dans la trajectoire construite. De même, il apparait clairement que l ordre de prélèvement des différentes positions des données brutes dans le temps, est préservé dans la trajectoire finale ; c est-à-dire si i < j alors t i < t j. Par ailleurs, il apparait que pour un ensemble de données brutes, il existe une infinité de trajectoires que l on peut construire à partir de ces données. La trajectoire n est en aucun cas unique, l application d une méthode d interpolation permettra de trouver la représentation géométrique qui s apparente le mieux à la trajectoire réelle de l objet.

14 En utilisant l interpolation pour construire la trajectoire de l entité en mouvement, on arrive à estimer les coordonnées du mobile à des instants qui ne sont pas échantillonés. 2.6.1.1 Interpolation linéaire Elle constitue la méthode la plus simple et la plus rapide de toutes les méthodes d interpolation[4]. L idée est de joindre par des segments de droite deux positions successives de l ensemble des données brutes (voir fig. 2.6). Cette méthode suppose que l objet se déplace dans le temps à vitesse constante. Ainsi, pour un même intervalle de temps correspond la même distance parcourue. On peut alors calculer la position du mobile entre deux positions sucessives à chaque instant t pris dans la période couvrant le déplacement entre ces deux positions. A titre d illustration, le segment de droite entre les positions (x i, y i, t i ) et (x i+1, y i+1, t i+1 ) est donné par l équation suivante : (x, y, t) = (x i, y i, t i ) + dans R 2 R à l instant t [t i, t i+1 ]. t t i t i+1 t i (x i+1 x i, y i+1 y i, t i+1 t i ) Figure 2.6 Interpolation linéaire [4] Inconvénients : Cette façon de construire la trajectoire n est pas la plus adaptée. En effet, en appliquant la méthode de l interpolation linéaire, plusieurs hypothèses ont été prises qui ne reflètent pas toujours la réalité : en premier, en appliquant l interpolation linéaire, nous avons supposé que le mobile se déplace à vitesse constante et ne change pas de direction entre les positions considérées. De plus, cette vitesse est la vitesse moyenne minimale qu il faut pour parcourir la distance entre les points (x i, y i ) et (x i+1, y i+1 ) en un temps t i+1 t i ; deuxièmement, cette méthode ne permet pas de représenter certaines situations ou des contraintes particulières liées à l itinéraire du mobile ; c est le cas par exemple, d un rond point ou d un changement brutal de vitesse dû à un coup de freins

15 de l automobiliste devant un obstacle imprévu. On constate simplement que la trajectoire issue de l interpolation linéaire est continue et que les différents points de changement de direction (virages par exemple) sont des angles aigus ; enfin, la trajectoire construite avec cette méthode s apparentera plus à la trajectoire réelle du mobile si l échantillongage des différentes positions de l objet au cours de son mouvement est faite à intervalle de temps très réduit (toutes les secondes par exemple), en d autres termes les positions doivent être assez proches les unes des autres pour obtenir une trajectoire de meilleure précision. Ce qui suppose un volume de données plus important et donc des temps de traitement plus longs. 2.6.1.2 Interpolation avec des courbes de Bezier L interpolation utilisant les courbes de Bezier [4] parait plus adéquate pour créer des courbes ou trajectoires reflétant au mieux la réalité. En effet, étant données deux positions de l ensemble des données brutes et le vecteur vitesse (qui renseigne sur la valeur de la vitesse et la direction à chacune de ces positions), une courbe de Bezier est construite en représentant chaque coordonnée spatiale par un polynome de dégré 3 de paramètre t (Figure. 2.7). Le début et la fin de la courbe correspondent exactement aux deux positions échantillonées des données brutes. La trajectoire construite est dérivable en tout point, ce qui permet de déterminer l accélération du mobile à chaque instant de son déplacement. Inconvénients : Le principal inconvénient de cette méthode est qu elle n est pas facile à mettre en oeuvre, ni à manipuler en pratique. Par exemple, le calcul de distance ou la recherche des intersections avec d autres trajectoires se compliquent avec cette méthode. En effet, du point de vue de la mise en oeuvre, il apparait clairement qu il faut plus d informations (par exemple, la vitesse de l objet en tout point, la direction en tout point, etc.), pour pouvoir construire ce type de trajectoire. Néanmoins, si ces données sont inconnues, on peut toujours faire des conjectures en prenant par exemple la direction moyenne obtenue sur la base de la direction du mobile dans les positions qui précèdent et suivent la position considérée ; on procède de la même façon pour déterminer la vitesse du mobile en ce point. Le point commun entre l interpolation avec des courbes de Bezier et l interpolation linéaire c est le fait que pour l une ou l autre méthode, plus on a de points d échantillonnage (temps de prélèvement des informations assez court), meilleure est la trajectoire obtenue. Figure 2.7 Interpolation utilisant des courbes de Bezier [4]

16 2.6.2 Notions d incertitude Quelque soit la méthode d interpolation utilisée, la trajectoire obtenue n est qu un choix parmi une multitude de trajectoires candidates. Dès lors, nait la notion d incertitude en rapport avec la méthode d interpolation utilisée pour construire la trajectoire. Cette première incertitude est appelée incertitude d interpolation. Dans le domaine des bases de données, notamment géographiques, l incertitude se définit comme la mesure de l écart entre ce qui est stocké dans la base de données et ce qu un opérateur ou une application obtiendrait de façon directe et précise de l observation d un phénomène [27] [24].Ainsi, les sources d incertitude suivantes sont recensées : une observation imparfaite de la réalité, qualifiée d incertitude dans la localisation (spatiale et temporelle) ; l incomplétude du langage utilisé pour décrire tous les détails inhérents à une observation, l incertitude descriptive ; enfin les insuffisances ou faiblesses de la méthode d interpolation utilisée. 2.6.2.1 Incertitude d interpolation L incertitude d interpolation résulte principalement des deux dernières sources et peut être gérée en appliquant la technique dite du bead model présentée dans [10]. Le bead model se base sur l hypothèse que : la vitesse maximale d un objet mobile entre deux positions échantillonnées, est connue sur la base que l information sur les différents positions prélevée est exacte. Ceci n est pas toujours vérifié comme le suggère la deuxième notion d incertitude. Donc, dans l espace (à 2 dimensions), si v est la vitesse maximale de l objet pour partir du point (x i, y i ) à l instant t i et arrivé au point (x i+1, y i+1 ) à l instant t i+1, alors pour tout instant t [t i, t i+1 ], la distance de l objet entre (x i, y i ) et (x i+1, y i+1 ) est au plus égale à v(t t i ). Celà signifie qu à tout instant t [t i, t i+1 ], l objet se trouve quelque part dans le disque de centre (x i, y i ) et de rayon v(t t i ). Dans l espace-temps (3 dimensions), ce disque équivaut à un cône de sommet (x i, y i, t i ) ayant un axe de symétrie parallèle à l axe du temps et orienté dans le sens contraire de ce dernier. A ce même instant t [t i, t i+1 ], l objet en position (x, y) doit atteindre la position (x i+1, y i+1 ) en un temps (t i+1 t). Celà signifie que la distance qu il parcourt jusqu à (x i+1, y i+1 ) est au plus égale à v(t i+1 t) et ainsi l objet se trouve sur un disque de centre (x i+1, y i+1 ) et de rayon v(t i+1 t). De façon similaire dans l espace-temps, ce disque correspond à un cône de sommet (x i+1, y i+1 ), d axe parallèle au temps mais cette fois dirigé vers le sens de l axe du temps. Donc à tout instant t [t i, t i+1 ], l objet se trouve quelque part dans l intersection des deux disques comme le montre la figure 2.8 [10]. De façon générale, un point (x, y, t) appartiendrait à la trajectoire allant de (x i, y i, t i ) à (x i+1, y i+1, t i+1 ) si et seulement s il se trouve dans l intersection des cônes comme illustré à la figure 2.9 [10]. 2.6.2.2 Incertitude de mesure Elle est dûe aux erreurs générées par les instruments de mesure par exemple des capteurs GPS. Cette dernière forme d incertitude, tout comme la précédente, concerne surtout la dimension spatiale des trajectoires. La notion d incertitude permet de mesurer l écart qui

17 Figure 2.8 Incertitude d interpolation dans l espace [10] Figure 2.9 Incertitude d interpolation dans l espace-temps [10] existe entre ce qui est stocké dans la base de données et ce qui est réellement observé. Un modèle pour représenter graphiquement une combinaison des deux formes d incertitudes est présenté dans [42]. Dans ce modèle, un seuil d incertitude est introduit. Ce seuil correspond à l écart maximal entre la trajectoire actuellement stockée et la trajectoire réelle en tout point du mouvement. Après avoir construit la trajectoire de l objet par interpolation linéaire, le modèle associe à chaque segment de la polyligne obtenue, un disque de rayon égal au seuil fixé. Tous ces disques mis ensemble dans l espace à trois dimensions (espace - temps), génèrent un cylindre autour de la polyligne de trajectoire. Ce cylindre couvre la zone de définition de toutes les trajectoires possibles de l objet mobile, comme l illustre la figure 2.10 [42]. 2.7 Conclusion Au terme de ce chapitre introductif consacré à la définition des concepts qui nous semblent pertinents dans l étude des trajectoires, il en ressort que les notions de temps et d espace sont fondamentales en matière de gestion d objets mobiles. Dès lors, vu le caractère continu et infini de ces deux ensembles, il est particulièrement important de pouvoir définir pour l un et l autre, un système de référence afin de pouvoir distinguer leurs éléments ; quand il est vrai que l on ne peut parler de mouvement que s il y a changement de position au cours du temps. L autre aspect important abordé est la façon

18 Figure 2.10 Zone de définition de trajectoire [42] dont les données brutes, c est-à-dire les données collectées à partir des différents capteurs lors de l observation d un mouvement, sont traitées, afin de pouvoir reconstruire la trajectoire de l objet mobile. A cette fin, nous avons présenté diverses techniques d interpolation utilisées ainsi que les limites de l une ou l autre technique. La dernière notion abordée dans ce chapitre est la notion d incertitude Intrinsèquement liée aux trajectoires et introduite soit par la méthode d interpolation utilisée, soit lors des prélèvements ou échantillonnage des données. Dans le chapitre qui suivra, nous allons nous intéresser à la modélisation et aux systèmes existants en matière de gestion des données de trajectoires. En effet, nous essayerons de faire un état de l art des différentes approches de modélisation élaborée dans la communauté scientifique en vue du stockage et de l interrogation des concepts introduits précédemment (espace, temps, trajectoire, etc.). Par la suite, nous étudierons quelques exemples de systèmes de gestion de base de données qui proposent un support même partiel à la gestion des trajectoires.

Chapitre 3 Modélisation et systèmes de gestion de données de trajectoires Dans ce chapitre, nous nous intéressons à l état de l art de la modélisation des données de trajectoires et des systèmes de gestion associés. Dans la première partie consacrée à la modélisation des données, nous étudierons les principales approches qui existent dans la littérature. Ces approches sont principalement dérivées des modèles de données classiques (relationnel et objet), auxquels on ajoute des constructions, afin de prendre en compte au mieux, les concepts inhérents aux trajectoires. Dans la deuxième partie, nous passerons en revue quelques systèmes de gestion de données implémentés sur la base de ces approches. 3.1 Modélisation des données de trajectoires Un modèle de données est une vue logique de la façon dont les données sont organisées dans le système de gestion de base de données. On regroupe en trois catégories les approches de modélisation des données de trajectoires [10] : le modèle de données spatio-temporelles, le modèle de données avec contraintes (constraint data model), le modèle de données d objets mobiles (moving object model). Si les deux premières catégories ne prennent pas en compte les trajectoires comme des types à part entière (first class object), elles permettent néanmoins d en représenter les principaux concepts et par conséquent de manipuler implicitement les trajectoires. La troisième catégorie par contre, regroupe les différentes approches développées spécifiquement pour la modélisation et l interrogation des objets mobiles et donc la modélisation et l interrogation des trajectoires. 3.1.1 Modèle de données spatio-temporelles La caractéristique commune des modèles de données spatio-temporelles réside comme leur nom l indique, dans le fait qu ils sont construits par association de types de données spatiales et des types de données temporelles. Si la modélisation et la manipulation des types de données géographiques (spatiales) font l objet d un consensus au sein de la communauté des systèmes d information géographique (SIG) ; où, notamment des standards SQL 1 existent, un tel consensus n existe pas encore en ce qui concerne les 1. Structured Query Language 19

20 types de données temporels. En effet, bien que des standards en matière de types de données temporelles soient définis [22], au niveau du SQL ce n est pas encore le cas. Les différentes propositions [38, 37, 21] n ont pas convaincu le comité SQL[39, 8]. De récents développements[3] introduisent de nouvelles fonctionnalités dans le langage SQL pour la gestion du temps. Ces nouvelles fonctionnalités, présentées à la section 2.5.4 de ce mémoire, sont progressivement implémentées par les grands éditeurs de SGBD à l instar d Oracle, Teradata ou IBM avec son système DB2[36]. Pour ce qui est de la modélisation des données spatio-temporelles, des solutions ont été proposées dans la littérature. Certaines s inspirant du modèle entité-association (STER [43], ST USM), d autres de l approche orientée objet (PERCEPTORY [5], Extended Spatiotemporal UML [43]) et d autres enfin, d une approche orientée logique basée sur des contraintes. Finalement, des bases pour une approche générale applicable à toute modélisation d objets mobiles ont été proposées par [16, 1]. 3.1.1.1 Le standard ISO/TC 211 ISO/TC 211 est le comité technique de l Organisation Internationale de Normalisation(ISO) en charge de la définition des normes internationales en matière d information géographique et géomatique. Ces normes spécifient les techniques, outils et services pour la collecte, le traitement, l analyse, la présentation et la diffusion des données géographiques entre divers partenaires (utilisateurs, applications, etc.) et sont consignées dans le guide [2]. En ce qui concerne la modélisation des données spatio-temporelles, deux standards de l ISO/TC 211 nous intéressent particulièrement, il s agit de : i) la norme ISO 19107, Information géographique - schéma spatial, qui définit les types spatiaux et les opérations qui s y appliquent dans l espace géométrique et topologique [23]. Elle concerne essentiellement les données vectorielles qui sont des données spatiales représentées dans un système de coordonnées en utilisant les trois abstractions de base : point, ligne/courbe et region comme l illustre la figure 3.1 [18]. Fondamentalement, un point représente le plus petit élément dans un système de référence et permet de modéliser un objet en terme de localisation (coordonnées) indépendamment de sa forme géométrique. De cette façon, un point permet de représenter une ville sur une carte à grande échelle ou un piéton sur un écran d observation (Google Maps, GPS, etc.) ; une ligne (ou courbe dans l espace), permet de représenter un mouvement (changement de position) d une entité ou une connexion dans l espace. Une ligne permettra ainsi de représenter par exemple la trajectoire d un piéton dans une région, une route ou une rivière sur une carte. Une région quant à elle permet de représenter une surface c est à dire un objet en deux dimensions, idéal lorsqu on s intéresse à la forme de l objet. Comme exemple d objet représentable par une région, on peut citer une forêt ou un lac sur une carte. Collection d objets spatiaux A côté des types de base( point, ligne et région), la norme permet également de définir des collections d objets spatiaux. Une collection d objets spatiaux peut être représentée par deux abstractions : une partition ou un réseau. Une partition est un ensemble d objets de type région nécessairement disjoints. Une partition est adaptée pour représenter des phénomènes spatiaux dont la relation d adjacence est particulièrement intéressante à l analyse, pour chaque paire d éléments de la collection [18]. Les cartes thématiques sont un exemple de tels phénomènes. Un

21 Figure 3.1 Données vectorielles : abstractions de base [18] réseau est une collection d objets représentée sous la forme d un graphe dont les noeuds sont de type point reliés entre eux par des objets de type ligne. Un réseau est idéal pour représenter des phénomènes où la notion de graphe est prépondérante ; par exemple, le réseau de transport urbain avec ses différentes stations, le réseau gazier ou l ensemble des cours d eau d un pays. Les figures 3.2 et 3.3 illustrent respectivement les notions de partition et de réseau. Figure 3.2 Une partition [18] Opérations sur les types spatiaux : Comme évoqué plus haut, ISO 19107 définit également les opérations de base qui s appliquent aux types spatiaux. On peut formaliser quelques unes de ces opérations dans le tableau 3.1. où points représente une collection d objets de type point. ii) la norme ISO 19108, Information géographique - schéma temporel, définit un ensemble de types de données et les opérations associées, pour décrire l aspect temporel de l information géographique[22]. Les types de données supportés par la norme ISO 19108 sont ceux décrits à la section 2.5.1. La norme définit également un ensemble d opérateurs de synchronisation et de comparaison pour les types temporels, inspirés des opérateurs d Allen[46]. Le tableau 3.2, présente les opérateurs temporels de base pour les types de données Période.

22 Figure 3.3 Un réseau [18] Opération Signature Signification inside point region bool retourne vrai si le point est contenu dans region, faux sinon. adjacent region region bool retourne vrai si les deux regions sont adjacentes, faux sinon. intersection line line points retourne l ensemble des points communs aux deux lignes. minus region region region retourne l ensemble des points de la region A qui ne font pas partie de la region B. contour region line retourne une ligne correspondant au périmètre de la region. length line real retourne la longueur d un objet de type ligne. Table 3.1 Opérations de base sur les objets spatiaux [23] 3.1.1.2 Un modèle de données spatio-temporelles basé sur le modèle entitéassociation : STER Spatio Temporal Entity Relationship (STER) a pour objectif d étendre le modèle entité-association classique afin de prendre en compte la modélisation des données spatiotemporelles [43]. STER utilise les concepts de base du modèle entité-association que sont : la notion d entité, qui représente une abstraction du monde réelle avec une existence propre et identifiable de façon unique, elle est représentée dans le modèle graphique par un rectangle ; la notion d association, représentant la façon dont les différentes entités intéragissent les unes les autres ; elle est représentée par un losange ; la notion d attribut qui sert à décrire une entité ; elle est représentée par un losange ; la notion de cardinalité qui définit le type de relation entre deux entités en indiquant le nombre d occurences de chaque entité intervenant dans la relation (association). La cardinalité est représentée par une paire de nombres : 1 :1 pour une association où une et une seule occurence de chaque entité intervient dans

Opérateur Signature Signification before bef ore(p erioda, P eriodb) bool Retourne Vrai si l entièreté de la période A se trouve avant la période B. meets meets(p erioda, P eriodb) bool Retourne Vrai si la fin de la période A coïncide avec le début de la période B. overlaps overlaps(p erioda, P eriodb) bool Retourne Vrai si les deux périodes se chevauchent. during during(p erioda, P eriodb) bool Retourne Vrai si l entièreté de la période A est contenue dans la période B. starts starts(p erioda, P eriodb) bool Retourne Vrai si les deux périodes commencent au même instant. finishes f inishes(p erioda, P eriodb) bool Retourne Vrai si les deux périodes se terminent au même instant. equal equals(p erioda, P eriodb) bool Retourne Vrai si les deux périodes coïncident c est-à-dire que le début de A est égale au début de B et la fin de A est égale à la fin de B. Table 3.2 Opérateurs temporels de base 23 la relation ; 1 :M, pour une occurence de l entité de gauche, on peut associer une multitude d occurences de l entité de droite ; N :M, plusieurs occurences de l entité de gauche peuvent être associées à plusieurs occurences de l entité de droite. STER crée des extensions de ces éléments de base en leur ajoutant une dimension spatiale, temporelle ou spatio-temporelle (par simple conjonction des deux précédentes notions). Les éléments ainsi construits constituent les concepts de base du modèle spatiotemporel entité-association (STER). Graphiquement, un élément du modèle STER est représenté en ajoutant à l élément du modèle entité-association simple correspondant : une indication sur le coin supérieur droit si l élément prend en compte l aspect temporel. Pour ce faire, plusieurs dimensions temporelles sont prises en compte : le temps d existence (symbole et), correspondant au temps où un objet existe ; le temps de validité (vt), le temps de transaction (tt) et le temps bitemporel(bt) tels que définis à la section 2.5.3. une indication sur le coin inférieur droit s il prend en compte l aspect spatial (symbole R et P respectivement pour région et point) ; La figure 3.4 présente un exemple de modélisation d une application cadastrale utilisant STER [43]. On y voit notamment la représentation des différents aspects spatiaux (entités agricultural et industrial par exemple), temporels(attribut type de l entité industrial) et spatio-temporels (entités landparcel et building par exemple). 3.1.1.3 Un modèle de données spatio-temporelles orienté objet : PERCEP- TORY PERCEPTORY est un outil de modélisation des bases de données spatiales et des bases de données spatio-temporelles, développé à partir du formalisme orienté-objet de UML et enrichi pour supporter la référence spatiale et les normes ISO/TC 211[45, 5, 26].

24 Figure 3.4 Exemple de modélisation avec STER [43] L approche de PERCEPTORY est de développer des plug-ins de langages visuels (PVL : Plug-in for Visual Languages) pour la modélisation des informations spatiales et temporelles. Ces plug-ins peuvent être installés dans un outil de modélisation existant (par exemple Microsoft Visio). Les plug-ins de PERCEPTORY disposent d un ensemble de concepts élémentaires (existence, évolution d une entité ou de l attribut d une entité, etc.), représentés par des symboles visuels ; la sémantique attachée à chaque concept permet de combiner ces concepts élémentaires afin de représenter des concepts complexes. PERCEPTORY dispose d une composante de modélisation spatiale (PVL spatial), permettant de modéliser des objets spatiaux en deux ou trois dimensions et d une composante de modélisation spatio-temporelle(pvl spatio-temporelle) qui intègre les types de données de la norme ISO/TC211-19107 et 19108. La figure 3.5 présente un écran de modélisation dans PERCEPTORY [5]. 3.1.1.4 Un modèle de données spatio-temporelles hybride : MADS Le modèle MADS (Modélisation d Applications à Données Spatiales) [31], est un modèle de type objet-relation, à mi-chemin du modèle entité-association (notions d attribut, d association et de cardinalité supportées) et de la modélisation objet (notions d objet et lien de généralisation/aggrégation supportées). MADS permet de modéliser à la fois des données classiques, les phénomènes spatiaux (route, rivière, bâtiment, pente, altitude...), temporels (dates des crues, débits journaliers des rivières...) et spatio-temporels (zones inondées ou polluées jour par jour, extension d un incendie, couverture du sol selon les années, etc.). Pour ce faire, MADS définit un formalisme visuel composé de pictogrammes permettant d ajouter une spatialité ou une temporalité à divers niveau

25 Figure 3.5 Ecran de modélisation spatio-temporelle dans PERCEPTORY [5] du schéma objet-relation(au niveau de l objet, de l attribut, ou de la relation). La spatialité renvoie à la localisation, à la forme et aux relations de l objet avec les autres objets dans l espace et se réfère à un ensemble extensible de types de données abstraits (TAD) illustré à la figure 3.6. La temporalité a trait au cycle de vie de l objet et à la validité de l information.elle se réfère également sur un ensemble de TAD illustré à la figure 3.7 [31]. Les figures 3.8 et 3.9 illustrent une modélisation de la spatio-temporalité respectivement au niveau de l objet et sur un attribut de l objet dans MADS. 3.1.1.5 Insuffisances des modèles spatio-temporels La plupart des modèles spatio-temporels présentés précédemment, à l exception de la norme ISO/TC 211 permettent de modéliser les données d objets dont la géométrie ou la position change en fonction du temps et donc, de manipuler des trajectoires. Pour la norme ISO/TC 211 qui ne propose aucun formalisme pour modéliser de tels objets, il reste néanmoins possible de définir une trajectoire comme un objet composite (constitué d un attribut spatial de type point et d un attribut temporel de type Instant représentant respectivement la position de l objet et l instant de prélèvement de cette position), qu on associe à l objet en mouvement. La figure 3.10 illustre une telle modélisation. Les trajectoires décrites avec des modèles spatio-temporels prennent en compte les

26 Figure 3.6 MADS : Types de données abstraits spatiaux [31] Figure 3.7 MADS : Types de données abstraits temporels [31] concepts des trajectoires, dans le sens de géométries évoluant dans le temps (considération de la spatialité et de la temporalité), mais ignorent toutes les contraintes et opérations spécifiques liées aux trajectoires. On peut par exemple citer la contrainte qui veut que toute trajectoire comporte au moins deux instants distincts. Des exemples d opérations relatives aux trajectoires concernent par exemple la durée et la direction de la trajectoire. De même, aucun de ces modèles ne propose de langage d interrogation spécifique ni de méthodes, pour l analyse des trajectoires. Toutes ces insuffisances incitent à explorer d autres approches de modélisation. 3.1.2 Le modèle de données avec contraintes L approche du modèle de données avec contraintes est de représenter des ensembles infinis en utilisant des contraintes logiques [35]. Etant donné que l espace et le temps sont des ensembles infinis, on peut naturellement imaginer exploiter cette propriété du modèle avec contraintes pour modéliser des données de trajectoires. En effet, dans un modèle de données avec contraintes, tout objet, spatial ou temporel, peut être décrit en utilisant une combinaison d égalités et d inégalités logiques de polynomes. Un tel polynôme est par exemple décrit en utilisant comme variable, les coordonnées (x, y) du

27 Figure 3.8 Objet spatio-temporel trajectoire [10] Figure 3.9 Attribut spatio-temporel trajectoire [10] point dans le plan. Ainsi, l ensemble des points appartenant à la moitié supérieure d un cercle trigonométrique est donné par l ensemble de contraintes suivant : (x, y) R 2 x 2 + y 2 = 1 y 0 Cette façon de modéliser des objets fixes peut être étendue pour modéliser des objets mobiles. En effet, il suffit d ajouter le temps comme troisième dimension au plan décrit à l étape précédente pour obtenir un espace - temps. Ainsi, un demi cercle qui se déplace sur l axe des abscisses en fonction du temps sera décrit par l ensemble de contraintes suivant : (t, x, y) R 3 (x t) 2 + y 2 = 1 y 0 0 t 1 Une trajectoire relie une infinité de positions (courbe construite), à partir d un ensemble fini de positions prélevées à des instants précis. On peut donc aisément adapter le modèle avec contraintes aux objets mobiles et donc aux trajectoires. Cette section est consacrée à l approche de modélisation des données de trajectoires en utilisant les différentes approches de modélisation avec contraintes : le modèle à contrainte linéaire le modèle à géométrie différentielle le modèle à équations de mouvement Dans cette section, nous nous intéresserons aux modèles à contrainte linéaire et au modèle avec équation de mouvement qui nous semblent plus appropriés au traitement informatique. 3.1.2.1 Le modèle à contrainte linéaire Dans le modèle à contrainte linéaire, le polynome utilisé pour décrire les données doit être linéaire. Ce modèle suppose que l objet se déplace à vitesse constante sur un segment de droite reliant deux positions successives de l ensemble des positions prises comme échantillon. En prenant m instants t ] 1, m[ t i < t j, i < j et une fonction p qui associe un instant t à une position p(t) = (p 1 (t), p 2 (t),, p n (t)) R n représentant la trajectoire de l objet. Dans le modèle à contrainte linéaire correspondant, chaque p i est représenté par la contrainte : pour t [t j, t j+1 ] et j = 1,, m 1. p i (t) = b ij t + cij

28 Figure 3.10 Trajectoire dans ISO/TC211 [10] Le fait que dans la réalité, la vitesse d un mobile ne soit pas toujours constante et que les changements de direction ne se font pas toujours de façon brutale (on imagine mal des routes en segments, avec des virages en angles), rend ce modèle peu naturel malgré sa grande simplicité et sa facilité d implémentation. 3.1.2.2 Le modèle à équations de mouvement L approche ici consiste à modéliser la trajectoire d un objet à l aide de l équation de son mouvement. En effet, en se basant sur la deuxième loi de Newtown relative au mouvement, Geerts dans [13], représente un objet mobile à l aide de l équation de son mouvement. La deuxième loi de Newtown ou relation fondamentale de la dynamique stipule que la force qui agit sur un objet mobile est proportionelle à l accélération que subit son mouvement. Formellement, soit x : R R n : t x(t) = (x 1 (t), x 2 (t),, x n (t)) représentant la position de l objet à l instant t et soit m sa masse. Considérons F : R R n : t F (t) = (F 1 (t), F 2 (t),, F 3 (t)) la somme des forces qui agissent sur le mobile à l instant t, la seconde loi de Newton stipule que : F (t) = m d2 x(t) dt 2 Etant, x 0 = x(t 0 ) et v 0 = dx(t 0) dt respectivement position initiale et vitesse initiale de l objet mobile, on peut retrouver une solution unique à cette équation différentielle d ordre 2 [13]. On peut ramener l ordre de cette équation au premier ordre en rajoutant des variables de la façon suivante : d dt X(t) = d ( ) ( ) x(t) v(t) = F (t). dt v(t) m La forme générale d une contrainte différentielle donnéee par : x i = f i (x 1,..., x n, t) x i sur les variables x 1, x 2,, x n est où i = 1,, n et f i est un polynôme à variables multiples et coefficients entiers. A partir de là, l auteur de [13] décrit une équation de mouvement comme un ensemble fini de triplets où chaque triplet est composé de l ensemble des contraintes initiales, d un ensemble de contraintes différentielles et de l instant de validité du triplet. En utilisant la méthode d Euler, l auteur de [13] démontre que la trajectoire de l objet peut être obtenue en joignant des morceaux de courbes construites à partir des triplets ainsi définis. Une base de données de trajectoires avec ce modèle est décrite par un triplet composé d un ensemble fini d identifiants d objets, d un mappage entre cet ensemble et l ensemble contenant toutes les équations de mouvement et de l instant de validité du mouvement(borne supérieure de la période du mouvement).

29 3.1.3 Le modèle de données d objets mobiles A la base, les modèles de données spatio-temporels permettent de représenter les objets dont on s intéresse uniquement à la forme ou à la position dans le temps considéré comme discret (à des instants précis). Ces objets spatio-temporels sont décrits en intégrant au sein de la représentation de l objet, un attribut spatial et un attribut temporel. Avec le temps, notamment avec l avènement des équipements mobiles personnels (GSM, GPS, Smartphone, etc.), de nouveaux besoins sont apparus. Notamment avec les applications ubiquitaires (applications qui nécessitent de connaitre la position d un objet en temps réel) et les location-based services, une nouvelle approche de représentation des trajectoires sous la forme d objets mobiles (moving object) a émergé. Cette approche s intéresse à la fois, à la gestion de l historique des positions, à la position courante de l objet à tout instant (temps continu) et éventuellement permet de faire des prévisions sur les positions dans un futur très proche. Suivant les besoins, les objets mobiles peuvent être représentés sous deux abstractions : lorsque l on s intéresse uniquement à la localisation de l objet dans le temps (par exemple tracking d un utilisateur de téléphone mobile, tracking d un véhicule, d un avion ou d un bateau, équipés d un GPS), l objet mobile peut être représenté comme un point mobile (moving point) ; lorsque l on s intéresse en plus de la localisation, à la forme de l objet ou à son extension dans le temps (par exemple, l évolution d un désert, le mouvement d une armée sur un champ de bataille), on utilisera un moving region comme abstraction. Diverses approches ont été élaborées pour modéliser la trajectoire des objets mobiles dans les bases de données. Ces approches peuvent être regroupées en deux catégories dans la littérature. La première s intéresse à l interrogation des positions courantes et futures de l objet dans le temps et la deuxième se focalise sur l historique des positions de l objet. 3.1.3.1 Approche basée sur l historique des positions (point-location management) Cette approche très utilisée dans l industrie, notamment dans le tracking des véhicules, consiste à prélever périodiquement des couples (p, t) où p est la position (par exemple les coordonnées géographiques) de l objet à l instant t. Ces couples sont stockés dans la base de données au fur et à mesure que l objet évolue et l on peut à l aide du langage d interrogation, faire des requêtes sur la localisation de l objet à un instant passé. Cette approche souffre de quelques insuffisances : premièrement, elle ne fournit pas assez d informations permettant d effectuer des interpolations et donc de déterminer la localisation de l objet à des instants qui ne sont pas échantillonés, c est-à-dire qui ne figurent pas dans la base de données ; la deuxième insuffisance est liée au fait que cette méthode impose un compromis ressource/précision. En effet, la précision des résultats des requêtes sera fonction de la fréquence des mises à jour de la localisation de l objet. Des mises à jour fréquentes de la position de l objet ont pour avantage de donner une situation quasi instantanée mais suppose de très bonnes connexions réseau (un très bon réseau de transmission) et surtout une grande puissance de calcul pour analyser les données générées. Des mises à jour moins fréquentes par contre produisent des résultats moins précis, qui reflètent moins bien la réalité pour une faible sollicitaion des ressources réseau et de calcul.

30 enfin, cette façon de modéliser les données générées par des objets mobiles est source de lourdeur et d inefficacité au niveau du développement des applications qui utilisent ces données. 3.1.3.2 Approche MOST (Moving Objects Spatio-Temporal L approche MOST développée dans [34] permet de stocker des vecteurs de mouvement plutôt que les positions successives de l objet. Le premier avantage de cette méthode est qu elle évite des mises à jour fréquentes de la position de l objet. Dans cette approche, la localisation d un objet peut être obtenue à l aide d une fonction linéaire qui associe la position (cordonnées (x, y) de l objet) à un instant t. Un deuxième paramètre, appelé vecteur de mouvement qui renseigne sur la vitesse et la direction du mouvement est également associé à cette fonction. De cette façon, le serveur de localisation peut calculer ou plutôt, estimer la position de l objet mobile à tout instant t, en utilisant la technique de l interpolation linéaire présentée au point 2.6.1.1, à l aide de la fonction suivante : y(t) = y 0 + v(t t 0 ), t > t 0 Formellement, l approche MOST définit des attributs dynamiques c est-à-dire des paramètres dont la valeur change de façon continue par opposition à des attributs statiques qui changent par modification discrète - mise à jour explicite de la position de l objet par exemple). Un attribut dynamique X est défini par trois champs : X.value : représentant la valeur de l attribut au moment de la mise à jour ; X.updatetime : représentant l instant de la dernière mise à jour ; X.function : la fonction décrite plus haut. Dans cette approche, une mise à jour est effectuée uniquement lorsque l un des paramètres (généralement l une des composantes du vecteur de mouvement : vitesse ou direction) de la fonction linéaire, change. Cette approche de mise à jour est dite navigation par estimation ou dead-reckoning [30]. Si elle offre des performances intéressantes pour les localisations courante et future de l objet, cette approche dépend néanmoins fortement des incertitudes (changement brusque de vitesse ou de direction par exemple) liées au déplacement de l objet mobile. Le langage FTL Afin de tirer profit des attributs dynamiques introduits précédemment, les auteurs de MOST ont développé le langage de requêtes FTL (Future Temporal Logic), inspiré de la syntaxe SQL et utilisant des prédicats de logique temporelle pour préciser les relations temporelles entre objets dans les requêtes. FTL définit deux opérateurs de base Until et Nexttime définis comme suit : le prédicat f Until g est vrai lorsqu on a g à l état présent ou futur et, f vérifié en attendant ; le précidcat Nexttime f est vrai si f est vérifié au prochain état du mouvement. A partir de ces opérateurs de base, on peut construire d autres opérateurs complexes, par exemple : Eventually f = true Until f Always f = Eventually f La syntaxe générale d une requête FTL est la suivante : RETRIEVE} target-list WHERE condition-list

31 Où, condition-list est exprimée sous la forme d un prédicat FTL. Ces derniers effectuent des requêtes sur les positions futures de l objet, comme soulignés plus haut. Le modèle MOST manipule uniquement des points mobiles (moving point) et gère exclusivement la position courante et future de l objet en mouvement. Le principal intérêt du modèle MOST est de permettre l interrogation de la localisation courante et future de l objet sans tenir compte de l historique des positions du mobile, ce qui constitue un allègement du volume de données à traiter et donc une meilleure réactivité pour les requêtes de localisation. Ceci sous-entend aussi que MOST permet de gérer la localisation en continu (puisqu une fonction qui estime la position de l objet en tout instant t existe). D un autre côté il peut être interessant de stocker l historique des positions de façon explicite (à la manière de l approche présentée en 3.1.3.1). On pourrait donc imaginer une approche qui permette d interroger les positions courantes et futures tout en stockant l historique des positions du mobile. Celà permettrait par exemple de revenir à l état de la base de données à des instants passés, afin de mieux analyser l évolution du mobile et comprendre son mouvement. C est l approche que Güting et al. développe dans [16, 1, 18] 3.1.3.3 Modélisation avec des types abstraits de données (TAD) Cette approche développée par Güting et al dans [16, 1, 18], ambitionne de répondre à un double besoin. le support de la localisation, c est-à-dire la possibilité de connaitre la position du mobile en temps réel et dans un futur proche ; le support de l historique des positions (gestion des données spatio-temporelles passées), afin de pouvoir analyser l évolution du mobile. L approche consiste à développer des types abstraits de données spatio-temporels (moving point ou mpoint, moving region ou mregion, etc.) avec l ensemble d opérations associées. Ces nouveaux types peuvent ensuite être intégrés comme types de base dans un système de base de données (relationnel ou objet), qui peut être étendu avec des types utilisateurs. De façon générale, cette approche introduit un constructeur de type τ qui transforme tout type élémentaire a en un type τ(a) tel que : τ(a) = time a De cette façon, les types mpoint et mregion introduits plus haut, peuvent également être représentés par τ(point) et τ(region). De même, pour des types scalaires, par exemple les entiers, (int), les réels(real) ou les booléens(bool), en leur appliquant le constructeur τ, on obtient respectivement un entier mobile ou moving int (mint), un réel mobile ou moving real (mreal) et un booléen mobile ou moving bool (mbool) correspondant à un entier, un réel ou un booléen dont la valeur change en fonction du temps. On peut aisément imaginer les multiples usages qu on pourrait faire de telles constructions. Un entier mobile mint pourra par exemple être utilisé pour représenter l évolution de la population d une commune dans le temps. Un réel mobile, sera utilisé pour représenter la distance entre deux points mobiles au cours du temps et un booléen mobile pour s assurer qu une condition est vérifiée dans le temps (par exemple la vitesse du mobile v < v max ). La figure 3.11 illustre la représentation d un mreal alors que la figure 3.12 illustre respectivement un mpoint et un mregion. On remarquera que les deux derniers objets

32 mobiles sont représentés en trois dimensions (espace (2D) + temps) alors qu un moving real est représenté par sa valeur dans le temps (2D). En général, tous les types construits par application du constructeur τ sont des fonctions sur un domaine infini (le temps) et par conséquent constituent eux même des ensembles infinis. Figure 3.11 Représentation d un moving real [12] Figure 3.12 Moving point (a) et moving region (b) dans l espace-temps [16] Opérations sur les objets mobiles : Le tableau 3.3 présente quelques opérations qui s appliquent aux objets mobiles décrits précédemment. Les objets ligne, périodes, etc. ont la même sémantique que celle qu on leur a assigné à la section 3.1.1.1. Modèle abstrait et modèle discret Il ressort des développements précédents que la trajectoire d un point mobile peut être décrite soit par une courbe, soit par une polyligne (un ensemble de segments de droites liés entre eux) dans l espace-temps (2D + 1D). Lorsqu elle est décrite par une courbe, le temps est considéré comme infini ; alors la trajectoire qui est une fonction du temps est continue et correspond à un ensemble infini de positions. Lorsqu elle est décrite par une polyligne, le temps est réduit à un ensemble fini et la trajectoire qui est une fonction du temps, correspond à un ensemble fini de valeurs(positions sucessivement occupées par l objet mobile). Ces deux abstractions sont appelées respectivement modèle abstrait et modèle discret. i) le modèle abstrait est une approche formelle de la modélisation des trajectoires, c est-à-dire qu elle permet de raisonner sur des ensembles infinis sans se soucier de l implémentation ou de toute représentation finie de ces ensembles. L approche de définition des types est similaire à ce qui est présenté au point 3.1.3.3. Bien qu elle

Opération Signature Signification distance mpoint mpoint mreal Renvoie un moving real représentant la distance temporelle entre les deux moving point. trajectory mpoint line Renvoie une ligne (objet line ou linestring) par projection du moving point sur le plan. intersection mpoint mregion mpoint renvoie un moving point correspondant à la partie du moving point en entrée chaque fois que ce dernier croise le moving region tout au long de son évolution. deftime mpoint periods Renvoie l ensemble des périodes pendant lesquelles le moving point est défini. min mreal real Renvoie la plus petite valeur prise par l objet mreal au cours du temps. length line real Renvoie la longueur de l objet line. Table 3.3 Opérations de base sur les objets mobiles [16] 33 reflète mieux la réalité (par exemple, une trajectoire d un objet mobile en 3D (espace+temps) s apparente plus à une courbe qu à une polyligne dans la réalité), cette approche est malheureusement utopique du fait de la difficulté à représenter un ensemble infini dans un SGBD. Dès lors, il devient nécessaire de réduire ces ensembles infinis en des ensembles finis qu on peut représenter, d où le modèle discret. ii) le modèle discret propose une représentation finie, assez proche de l implémentation, d un ensemble infini. Ce qui revient à réduire l ensemble infini (abstrait) à un sous ensemble d éléments constituant un ensemble fini (discret). Cette réduction n est cependant pas sans côut, notamment pour les entités mobiles où des approximations sont nécessaires pour décrire les trajectoires. A cet effet, la notion de représentation en tranches (sliced representation en anglais) est introduite dans [12]. Elle consiste à découper le développement d une entité dans le temps (trajectoire), en plusieurs morceaux ou tranches (slices en anglais), de telle sorte que la partie de la trajectoire décrite dans un morceau puisse être représentée par une simple fonction. Les figures 3.13 et 3.14 illustrent respectivement la représentation en tranches d un réel (moving real) et d un point mobile (moving point). Dans [12], un constructeur appelé mapping est utilisé pour créer la représentation en tranches d une entité. En effet, la première étape consiste à définir un type pour décrire une tranche individuelle ; ce type qu on nommera unité mobile ( moving unit en anglais), est composée généralement un couple de deux champs (p, v) où p correspond à un intervalle de temps (sous la forme d une période : [t debut, t fin ]) et v la représentation dans cet intervalle, d une fonction simple. L unité mobile est ensuite passée en paramètre au constructeur mapping pour créer la représentation en tranches correspondante. Par exemple pour les types real, point, line et region, on a respectivement les types unités mobiles suivants : ureal, upoint, uline, uregion.

34 Figure 3.13 Représentation en tranches d un moving real [12] Figure 3.14 Représentation en tranches d un moving point [12] A la fin de cette section consacrée à une revue des principales approches de modélisation des données de trajectoires qui existent dans la littérature, nous allons nous intéresser à la section suivante aux systèmes de gestion de base de données existants qui implémentent d une façon ou d une autre certaines de ces approches. Plus particulièrement, nous allons nous intéressé aux systèmes qui implémentent l approche de modélisation par types abstraits de données étant donné que c est sur cette même approche que s appuie notre contribution. 3.2 Systèmes de gestion de données de trajectoires L étape préalable pour le développement de tout système de gestion de base de données est la définition des différentes structures de types, des opérations qui s y appliquent et la définition d un langage d interrogation pour la manipulation et l analyse des objets créés. Les systèmes de gestion de données pour les objets mobiles ne dérogent pas à cette règle. Dans la section précédente, nous avons présenté les principales approches. Dans cette partie, nous nous intéressons principalement à quelques implémentations de l approche de Güting et al [16, 1, 18, 12], basée sur les types abstraits de données (TAD), notamment SECONDO et Hermes. 3.2.1 SECONDO SECONDO est un système de gestion de base de données (SGBD) spécialement développé pour les applications non standards (applications manipulant des données que les bases de données classiques ne manipulent pas encore) [41]. SECONDO est développé par des chercheurs de l université de Hagen en Allemagne. C est un SGBD extensible qui constitue une plateforme idéale pour le développement et l expérimentation de nouveaux

35 types de données et prototypes de systèmes de gestion de données. C est dans ce cadre qu a été développée une extension pour la manipulation des objets mobiles. 3.2.1.1 Architecture de SECONDO SECONDO est composé d un noyau, d un optimiseur de requêtes et d une interface graphique extensible. a) Le noyau de SECONDO s occupe du traitement des requêtes sur la base d un catalogue d algèbres implémentées pour différents modules. l algèbre de base qui fournit le support des types simples : entiers, réels, booléens et chaines de caractères, de même que les opérations associées ; l algèbre relationnelle contient les types de données et les opérations nécessaires pour manipuler une base de données relationnelle classique ; l algèbre spatiale qui représente les objets spatiaux (point, ligne et région) avec leurs opérations ; l algèbre temporelle contient les types et opérations nécessaires pour la manipulation des objets mobiles. b) L optimiseur de requêtes implémente la partie qui fournit les fonctionnalités similaires au langage SQL ; c) L interface graphique à laquelle on peut ajouter des extensions visuelles pour la modélisation de nouveaux types de données et pour visualiser les objets créés. La figure 3.15 présente une architecture en couches du système SECONDO de base [41]. Les parties colorées en gris représentent les composants extensibles du système alors que les parties blanches composent le système de base. La couche 1 regroupe un ensemble d outils nécessaires pour la communication avec le système d exploitation et la gestion du stockage. A la couche 2, on retrouve le catalogue d algèbres. La couche 3 contient le moteur de requêtes, le catalogue système de types et d objets et implémente les mécanismes d ajout de nouveaux modules. A la couche 4 on retrouve l optimiseur de requêtes qui prépare les requêtes pour le moteur en proposant notamment un plan d exécution efficient sur la base de règles de transformation. L optimiseur de requête travaille sur une algèbre descriptive alors que le moteur de requête travaille sur une algèbre opérationnelle. Le gestionnaire de commandes à la couche 5 fournit une interface procédurale aux fonctionnalités de couches inférieures. Au niveau 6, on retrouve l interface graphique. Pour plus de détails sur l implémentation de SECONDO, le lecteur intéressé pourra se référer à [17]. 3.2.1.2 Gestion des objets mobiles dans SECONDO L idée de base dans la gestion des objets mobiles dans SECONDO est d utiliser les types spatio-temporels moving point et moving region tels que présentés au point 3.1.3.3. De cette façon, on peut représenter par exemple l itinéraire complet d un véhicule par un objet de type moving point (mpoint) et l évolution d un feu de brousse pourra être représentée par un objet de type moving region (mregion). A ces types de données, on associe un ensemble d opérations dont quelques unes sont présentées dans le tableau 3.4 [17].

36 Figure 3.15 Architecture de SECONDO [41] 3.2.2 Hermes Hermes est un système de gestion de base de données manipulant des objets dont la forme, la taille ou la position changent de façon discrète ou continue au cours du temps. Hermes implémente l approche de modélisation par de types abstraits de données que nous avons introduite au point 3.1.3.3. Hermes a été proposé et développé par Pelekis et al. dans [33, 28]. Hermes fournit des fonctionnalités spatio-temporelles à des systèmes de gestion de base de données relationnelles ou objet. Un prototype a été développé comme extension de STAU [32, 28], une extension spatio-temporelle pour le SGBD Oracle. Hermes peut être utilisé comme extension spatiale pure ou comme extension temporelle pure (grâce notamment à sa cartouche temporelle TAU-TLL) ; cependant, sa principale fonctionnalité est le support de la manipulation des objets qui changent (en forme, taille ou position), de façon continue. 3.2.2.1 Architecture de types dans Hermes Hermes est developpé sous la forme d une cartouche Oracle appelée Hermes Moving Data Cartridge (Hermes-MDC) qui définit les différents types de données et les opérations qui s y appliquent pour la modélisation, l interrogation et l analyse des objets mobiles. Comme extension du SGBD Oracle, Hermes hérite : des types de base ou Base Type (BT) en anglais, composés des entiers, réels, chaines de caractères et booléens avec les opérations associées ; des types spatiaux ou Spatial Type (ST) en anglais fournis par Oracle Spatial,

Opération Signature Signification trajectory mpoint line retourne la projection d un moving point dans le plan distance mpoint point mreal calcule la distance temporelle entre un objet mobile moving point et un point fixe passes mpoint region bool vérifie si un point mobile passe par une région inside mpoint mregion mbool retourne un moving boolean (mbool) indiquant lorsque le point mobile est à l intérieur de la région mobile à tout instant de leur mouvement. Table 3.4 Opérations de base sur les objets mobiles [17] 37 composant Oracle (sous la forme d une cartouche également), qui s occupe de la gestion des données spatiales et des opérations associées ; enfin Hermes définit dans sa cartouche temporelle TAU-TLL, les fonctionnalités temporelles nécessaires à la modélisation spatio-temporelle, temporal Type (TT). La figure 3.16 présente l architecture d Hermes. 3.2.2.2 Ojets mobiles dans Hermes (Hermes-MDC) Comme nous l avons souligné à l introduction de cette section, à travers sa cartouche Hermes-MDC, Hermes implémente la gestion des objets mobiles et donc des trajectoires en se basant sur l approche de modèle discret introduite par Güting et al. dans [16, 1, 18, 12]. Hermes exploite notamment l idée de la représentation en tranches présentée au point?? et étend le constructeur mapping à toutes les formes géométriques fournies par Oracle Spatial. L autre particularité d Hermes est le support des collections d objets spatio-temporelles grâce aux types mobiles multiples (multi moving type). La figure 3.17 présente le diagramme de classe d Hermes.

38 Figure 3.16 Architecture de types dans Hermes [28] Figure 3.17 Diagramme de classe de Hermes-MDC [28]

Chapitre 4 Hermes dans PostgreSQL 9 4.1 Introduction L une des principales contributions de ce mémoire est de proposer une infrastructure pour la gestion des objets mobiles dans le SGBD PostgreSQL 9. Cette infrastructure est basée sur Hermes-MDC (Hermes Moving Data Cartridge), la cartouche spatiotemporelle développée pour le SGBD Oracle, que nous avons introduite à la section 3.2.2. Cette contribution s inscrit dans le cadre des travaux futurs proposés dans [7] ; où des tâches préparatoires avaient été réalisées pour assurer la migration de Hermes de Oracle à la version 8 de PostgreSQL. D une façon générale, il est question d étendre le prototype de base obtenu à la suite de cette migration, par : le développement de nouvelles fonctionnalités, notamment la prise en charge des opérateurs et classes d opérateurs, la prise en charge des index, le développement des fonctions d entrée/sortie et la gestion des exceptions ; la mise en oeuvre d une nouvelle approche de modélisation des types de données temporelles et spatio-temporelles qui constituent en fait, l essentiel des développements de l extension, puisque les types spatiaux et les opérations associées, comme nous le verrons, proviennent de PostGIS, l extension spatiale de PostgreSQL. Dans cette approche, il est question de construire les types temporels comme des objets à part entière (first class citizen), c est-à-dire des entités, pouvant être construites pendant la phase d exécution, passées comme paramètres à des fonctions ou renvoyées comme valeur de retour de fonction. Ce qui était fait jusque là, c est que les types temporels étaient traités comme des structures (au sens des structures en langage C) où chacun des champs était traité individuellement. Par exemple, pour manipuler un type Timepoint granularité jour (D_Timepoint_D), l utilisateur devait manipuler les champs année, mois et jour individuellement. De cette façon, une fonction qui n aurait pris qu un seul paramètre de type D_Timepoint_D, en recevait plutôt trois de type entier ; l application de la nouvelle méthodologie de développement des extensions en vigueur dans la communauté des développeurs de PostgreSQL, afin de permettre à notre extension, de prétendre à une certaine portabilité et de susciter l intérêt d autres développeurs au sein de la communauté. Dans ce chapitre, nous allons dans un premier temps, présenter le SGBD PostgreSQL 9 et son environnement de développement d extension. Ensuite nous reviendrons de façon détaillée, sur l implémentation de la cartouche Hermes dans PostgreSQL 9, en 39

40 étudiant notamment les différents modules (spatial, temporel et spatio-temporel) qui la composent ainsi que les principales modifications et ajouts apportés au premier travail de migration effectué sur la version 8. Enfin, nous proposons une version allégée de Hermes dite Light Hermes, qui prend en considération certaines insuffisances observées avec Hermes. 4.2 PostgreSQL 9 PostgreSQL est un puissant système de gestion de bases de données relationnelles et objet open source, dont l ancêtre est PostGRES, un SGBD développé à l université de Californie au département des sciences informatiques de Berkeley en 1985. PostgreSQL a connu une grande évolution de sa création à la distribution actuelle (9.2), ce qui lui permet aujourd hui de fonctionner sur une grande partie des systèmes d exploitation du marché, entre autres : Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) et Windows. De même, PostgreSQL supporte la quasi-totalité du standard SQL tout en offrant de nombreuses fonctionnalités modernes telles qu un module spatial (PostGIS), permettant de représenter des données géographiques [15]. Enfin, son organisation en catalogues permet à l utilisateur averti, de développer facilement des extensions. 4.2.1 Méthodologie de développement d une extension PostgreSQL est extensible parce qu il opère grâce à un système de catalogues ; c està-dire que les informations concernant les schémas, les tables, les colonnes, etc. sont stockées dans ce qu on nomme communément des catalogues systèmes ou dictionnaires de données dans certains SGBD. Du point de vue de l utilisateur, ces catalogues sont semblables à des tables ordinaires, mais le SGBD y stocke ses registres internes. Contrairement à d autres systèmes, PostgreSQL enregistre beaucoup d informations dans ses catalogues. En plus de celles citées plus haut, on y retrouve l information concernant les types de données, les fonctions, les méthodes d accès, etc. Ces tables peuvent être modifiées par l utilisateur. Par conséquent, puisque PostgreSQL fonde ses opérations sur ces tables, il peut être étendu par les utilisateurs. A contrario, les systèmes de bases de données conventionnels ne peuvent être étendus qu en modifiant des procédures dans le code source ou en installant des modules spécifiquement écrits par l éditeur même du SGBD. Par ailleurs, le serveur PostgreSQL peut incorporer du code utilisateur par chargement dynamique ; cela signifie que l utilisateur peut indiquer un fichier de code objet (par exemple une bibliothèque ou librairie dynamique - DLL) qui implémente de nouveaux types ou de nouvelles fonctions et PostgreSQL le charge à la demande grace à des fonctions ou des procédures stockées - en langage PL/pgSQL 1 qui attaquent la librairie. C est cette méthode que nous utiliserons dans le développement de notre extension. 4.2.2 Environnement de développement de l extension 4.2.2.1 Difficultés rencontrées L une des principales difficultés de la réalisation de cette étape a été la mise sur pied de l environnement de développement de l extension de PostgreSQL. En effet, nous étions contraints de travailler dans un environnement Windows parce que l extension 1. Procedural Language for PostgreSQL

41 de base avait été développée avec Microsoft Visual C++ (langage par ailleurs recommandé par la communauté des développeurs, pour le développement d extensions ou la compilation des sources PostgreSQL sous Windows[15]). Malheureusement, nous nous sommes confrontés à un manque de documentation sur une méthodologie de mise en oeuvre d une infrastructure de développement d extension sous Windows. Dans [15], il est juste mentionné la possibilité de compilation des sources pour une installation de PostgreSQL à partir des sources avec MS Visual C++. L accent y est surtout mis sur l infrastructure intégrée de développement d extensions sous UNIX. Une autre contribution de ce mémoire est la production d un tutoriel de configuration pour la mise en place d une infrastructure de développement d extensions pour PostgreSQL avec MS Visual C++, afin de mettre à la disposition des développeurs de la communauté, travaillant en environnement Windows, un point de départ efficace pour leurs travaux. 4.2.2.2 Environnement de développement L environnement de développement est constitué d une part du compilateur Microsoft Visual C++ pour l écriture des fonctions de la librairie dynamique et du moteur d exécution des requêtes du serveur PostgreSQL d autre part. Il a fallu effectuer un certain nombre de configurations pour faire communiquer PostgreSQL et Microsoft Visual C++. Dans l annexe B, nous proposons les grandes lignes des étapes de configuration nécessaires pour créer un tel environnement. Comme décrit plus haut, l extension de PostgreSQL passe par le développement d une librairie de fonctions sous forme de code objet que le serveur charge ensuite à la demande. PostgreSQL étant un projet open source, la majorité des développements de ce genre de code objet est faite en C standard sous UNIX sous la forme de librairie partagée, une large documentation existe à cet effet dans [15] et les différents forums associés. Une autre méthode consiste à créer la bibliothèque en utilisant le langage C++ pour générer une DLL (Dynamic Link Library) afin de faire fonctionner l extension dans un environnement Windows. L utilisation du langage C++ pour développer l extension permet d exploiter les propriétés orientées objet de ce langage (héritage, polymorphisme, etc.), mais nécessite toutefois le respect de certaines règles lors de l écriture du code afin d assurer la portabilité de l extension (c est cette méthode qui nous intéresse). 4.2.3 Règles à respecter lors de l utilisation du compilateur C++ Les règles suivantes doivent être respectées lors de la construction d une extension PostgreSQL avec un compilateur C++ [15] : Toutes les fonctions utilisées par le serveur doivent présenter une interface C au serveur ; ces fonctions C peuvent ensuite appeler des fonctions C++. Par exemple, le lien extern C est requis comme préfixe d entête pour toutes les fonctions présentes dans l extension. Il est aussi nécessaire que chaque fonction soit passée comme pointeur entre le serveur et le code C++. Allouer/libérer la mémoire en utilisant la méthode appropriée d allocation/libération. Par exemple, la majorité de la mémoire serveur est allouée en utilisant la fonction palloc(), donc utilisez pfree() pour la libérer. Utiliser la fonction delete() de C++ pour ces cas échouera. Empêcher la propagation des exceptions dans le code C (utiliser un bloc capable de récupérer toutes les exceptions au plus haut niveau des fonctions C ). Ceci est nécessaire même si le code C++ ne renvoie aucune exception car des événements

42 comme le manque de mémoire renvoient toujours des exceptions ; par exemple vérifier le renvoi de NULL suite à l appel de la méthode new().toute exception doit être récupérée et une erreur appropriée doit être envoyée à l interface C. Si possible, compilez C++ avec l option -fno-exceptions pour complètement éliminer les exceptions. S il doit y avoir des appels aux fonctions du serveur à partir du code C++, s assurer que la pile d appels C++ contienne seulement l ancienne structure de données (POD). Cela est nécessaire car des erreurs du serveur génèrent un appel distant à longjmp() qui ne dépile pas proprement la pile d appels C++ avec les objets autre que POD. En résumé, il est préférable de placer le code C++ derrière un mur de fonctions extern C qui font l interface avec le serveur et évitent la fuite des exceptions, de mémoire et de pile d appels. Toutes ces recommandations ont été prises en compte dans nos développements. 4.3 Hermes dans PostgreSQL 9 Dans la section 3.2.2, nous avons présenté l architecture de haut niveau d Hermes. Nous allons nous intéresser dans cette partie, à une étude détaillée de ses différents composants (spatial, temporel et spatio-temporel) sous PostgreSQL 9. Il s agit en fait de présenter la façon dont ces différents modules sont implantés physiquement. Nous ne reviendrons pas sur les détails de la migration d Hermes vers PostgreSQL 8 dépuis Oracle, cette question étant suffisament abordée dans les travaux de [7]. 4.3.1 Module spatial : PostGIS Les fonctionnalités spatiales d Hermes sont supportées par PostGIS. PostGIS est la cartouche qui dote le SGBD PostgreSQL des capacités d une base de données spatiale, c est-à-dire une base de données qui stocke et manipule des objets géographiques (Point, Ligne, Polygone, etc.), comme des objets classiques (entier, réel, chaine de caractères, etc.). Pour ce faire, PostGIS définit les types de données spatiales, les fonctions associées et le support des index [29]. 4.3.1.1 Types de données PostGIS implémente les types de données spatiales spécifiés par l Open Geospatial Consortium (OGC) dans [14]. La figure 4.1 présente le diagramme de classes des types de données spatiales [14] supportées par PostGIS. On constate notamment dans ce diagramme que tous les objets spatiaux héritent de la classe Geometry qui est donc la classe mère et celle qui sera utilisée dans la définition des types spatio-temporels dans Hermes, afin de prendre en compte toutes les formes géométriques possibles. Par ailleurs, PostGIS utilise deux formats également recommandés par l OGC pour exprimer la forme des objets spatiaux dans un système de référence (système de coordonnées par exemple). Ce système de référence est lui même spécifié par un identifiant (SRID). Les deux formats sont : le format Well-Known Text (WKT), qui représente un objet spatial sous forme texte et donc compréhensible pour l humain. Par exemple un point est représenté par Point(x 1, y 1 ), une ligne par Linestring(x 1, y 1, x 2, y 2, x 3, y 3 ) où les x i représentent des coordonnées dans un système de référence ;

43 Figure 4.1 Diagramme de classes des types dans PostGIS [29] et le format Well-Known Binary (WKB) qui représente les objets spatiaux sous forme binaire. 4.3.1.2 Fonctions Sur la base des spécifications de l OGC [14], PostGIS fournit un riche ensemble de fonctions pour créer, déterminer les relations spatiales (intersection, chevauchement, union, etc.) ou analyser des objets spatiaux. La liste des fonctions spatiales proposées par PostGIS est très longue, cependant elles peuvent être regroupées dans les cinq catégories suivantes [29] : les fonctions de conversion qui permettent de convertir des données géographiques dans divers formats ; les fonctions de gestion pour la gestion des informations sur les tables spatiales et les informations d administration ; les fonctions d interrogation qui permettent d interroger les tables avec des attributs spatiaux ; les fonctions de comparaison qui permettent de comparer deux objets spatiaux sur la base de leur relation spatiale ; les fonctions de construction pour créer de nouveaux objets spatiaux à partir d autres. Le tableau 4.1, illustre quelques opérations implémentées par PostGIS. Pour une description complète des fonctions spatiales utilisées dans PostGIS et donc dans Hermes, le lecteur intéressé pourra se référer à [20].

44 Signature ST AsBinary(geometry) ST AsText(geometry) ST Distance(geometry g 1, geometry g 2 ) ST IsEmpty(geometry) ST Relate(geometry g 1, geometry g 2 ) ST Union(geometry[ ]) ST Makeline(geometry[ ]) Description Retourne le format WKB de l objet spatial (geometry) en paramètre. Retourne le format WKT de l objet spatial (geometry) en paramètre. Retourne la distance eucludienne entre les deux objets spatiaux en paramètres. Renvoie vrai ou faux selon que suivant que l objet spatial en paramètre est un ensemble vide. Retourne vrai si les deux objets spatiaux en paramètres se touchent. retourne un objet de type Multi* geometry à partir de l ensemble des objets en paramètre. Crée un objet de type Linestring à partir de l ensemble des Points en paramètre. Table 4.1 Quelques fonctions de PostGIS [20] 4.3.1.3 Support des index spatiaux Les SGBD classiques utilisent les structures d arbres binaires (B-Tree) pour la gestion des index. Un index est une méthode d accès efficace et non séquentielle à un sous ensemble de données. Les index (B-Tree) sont généralement basés sur des ensembles de données qui possèdent une relation d ordre naturel, par exemple les entiers ou l ordre alphabétique. Pour les bases de données spatiales, les arbres binaires ne sont plus suffisants pour supporter les méthodes d indexation étant donné la nature des relations entre les objets spatiaux. Par exemple, les polygones peuvent se chevaucher, être contenus dans d autres et sont représentés par des tableaux à plusieurs dimensions : il est difficile d en déduire un ordre naturel. Dès lors il est nécessaire d introduire de nouvelles méthodes d accès. Index R-tree : PostGIS, comme d autres systèmes de gestion de bases de données spatiales, introduit la notion d index spatial ou R-Tree qui permet de répondre à des questions dans le style : quel objet se trouve à l intérieur d une étendue spécifique?. Une étendue est le plus petit rectangle capable de contenir un objet spatial. Pour répondre à la question : l objet A contient t-il l objet B, opération non coûteuse si on manipule des rectangles, un index R-Tree va diviser l objet A en des rectangles de plus en plus petit jusqu à trouver ou non un rectangle qui contienne l objet B. Cependant l implémentation R-Tree de PostgreSQL n est pas assez robuste pour les concepteurs de PostGIS[20], d où l introduction des index GiST. Index GiST : Les index GiST (Generalized Search Tree) ou arbre de recherche généralisé, constituent un socle pour le développement des index personalisés pour structures de données complexes. En effet, un index GiST, peut être étendu à tous les types de données sur lesquels on peut effectuer des recherches. Les index GiST offrent en réalité un modèle de base ou template permettant d implanter des schémas d indexage arbi-

45 traires, par exemple B-tree et R-tree [44]. Pour le SGBD PostgreSQL [15], l interface GiST propose un haut niveau d abstraction qui permet au développeur de la méthode d accès d implémenter uniquement la sémantique du type de données à accéder et non la façon dont les données sont accédées. La couche GiST s occupant elle-même des accès concurrents. L utilisation d une méthode d accès GiST fonctionnelle sous PostgreSQL nécessite le développement de sept fonctions utilisateur définissant le comportement des clés dans l arbre [15]. PostGIS implémente des index GiST pour ses types spatiaux ; dans le cadre de notre extension, nous avons implémenté les fonctions nécessaires pour les différents types temporels. 4.3.2 Module temporel : TAU-TLL Le module temporel est responsable des fonctionnalités purement temporelles d Hermes. Il implémente les types temporels, les fonctions et opérateurs associés. Il est composé de deux parties : la première partie réalise le support de bas niveau, sous la forme d une librairie dynamique. La seconde partie, sous la forme d un script, (TAU-TLL.sql), est une enveloppe qui fait le pont entre la librairie dynamique et le serveur PostgreSQL. 1. La librairie dynamique (DLL) contient les binaires des différentes fonctions C qui supportent la cartouche temporelle au bas niveau. En effet, c est au niveau de ces fonctions que sont implantés les types temporels et leurs comportements. Le développement des différentes fonctions de cette partie obéit aux règles énoncées au point 4.2.3 ; 2. Le script TAU-TLL.sql contient le code PLpgSQL qui déclare les différents types temporels et les fonctions au niveau SQL afin de les rendre accessibles aux utilisateurs de la base de données. La cartouche temporelle définit principalement trois nouveaux concepts : Timepoint, Period et Temporal Element ; représentant respectivement un Point Temporel de l axe du temps, une Période bornée par deux points temporels de l axe du temps et une collection de périodes. A chacun de ces trois concepts, nous associons six niveaux de granularité : Année, Mois, Jour, Heure, Minute et Seconde, suivant le niveau de précision que l on désire atteindre pour représenter un phénomène. Ceci a pour avantage de permettre une certaine souplesse dans la modélisation des phénomènes temporels. Par exemple, pour modéliser l évolution temporelle d un désert, il est plus pertinent de s intéresser à une granularité de type Année ; alors que pour la modélisation de l évolution d un véhicule, la granularité Seconde est plus adéquate. Le tableau 4.2, présente les trois concepts évoqués, avec les différents niveaux de granularité. Period Temporal Element Timepoint D Period Y D Te Y D Timepoint Y D Period M D Te M D Timepoint M D Period D D Te D D Timepoint D D Period H D Te H D Timepoint H D Period Min D Te Min D Timepoint Min D Period Sec D Te Sec D Timepoint Sec Table 4.2 Types temporels dans Hermes A ces trois concepts, nous proposons également notre propre implémentation des types standards de la norme SQL-92 (Date, Time, Timestamp et Interval). Ceci par souci

46 de consistence et pour permettre une certaine indépendance vis-à-vis de l implémentation PostgreSQL des mêmes types, de même qu une souplexe dans la mise en oeuvre des fonctions et opérateurs de notre extension. Le tableau 4.3 présente les types issus de l implémentation Hermes des types de données SQL-92. Date Time Timestamp Interval D Date D Time D Timestamp D Interval Table 4.3 Types SQL-92 dans Hermes En ce qui concerne les fonctions et opérateurs, nous avons implémenté pour tous les concepts temporels présentés précédemment, les opérations temporelles de la norme ISO-19108, présentées à la section 3.1.1.1. Auxquelles nous avons ajouté des fonctions particulières, notamment les fonctions d appui aux index B-tree et GiST pour l indexation temporelle, ainsi que les différents opérateurs de comparaison. C est la partie de l extension principalement affectée par les modifications par rapport au prototype hérité du portage de PostgreSQL 8. 4.3.2.1 Interfaçage des fonctions de la librairie Comme nous l avons mentionné au point 4.2.1, l une des recommandations lorsque l on développe une extension pour PostgreSQL en utilisant le langage C++, est de s assurer que toutes les fonctions dans la librairie communiquent avec le serveur en langage C. Ceci se fait en préfixant le prototype de chaque fonction par une directive extern C coté DLL et du côté des fonctions PostgreSQL, on précise pour chacune des fonctions SQL qui attaquent la librairie, que le langage utilisé est le C, par l inclusion de la clause Language C strict dans la définition de la fonction. Par ailleurs, pour exporter les fonctions de la DLL afin de les rendre accessibles au serveur, l ancienne extension utilisait un fichier de définition de modules tllwrapper.def ; dans lequel pour chaque fonction, on associait manuellement et de façon unique, une valeur ordinale comprise entre 1 et N où N représente le nombre de fonctions exportées par la DLL. Si cette approche est aisée pour des librairies de quelques fonctions, elle devient très vite fastidieuse et des risques de confusion peuvent apparaitre lorsque le nombre de fonctions à écrire devient élevé comme c est le cas pour notre librairie (un millier de fonctions environ). Pour résoudre ce problème, nous avons préconisé une approche qui consiste à laisser le soin au compilateur C++ de générer automatiquement le processus d exportation. Pour ce faire, nous introduisons dans l entête de chaque fonction une clause declspec(dllexport) qui indique à l éditeur des liens de gérer lui-même l identification des fonctions dans la librairie. L avantage évident ici est que le développeur n a plus à gérer manuellement une séquence, avec le risque d avoir des doublons (ce qui conduirait nécessairement à une exception puisque le serveur se retrouvera devant deux fonctions distinctes associées à un même numéro et ne saura pas laquelle des deux invoquée). De même, le développeur peut créer de nouvelles fonctions sans avoir à se soucier de la façon dont elles seront exportées. Pour illustrer les aspects évoqués ci-dessus, dans ce qui suit, nous présentons un extrait du fichier de définition de module (ancienne approche), suivi de la nouvelle approche en présentant le prototype de quelques fonctions de la librairie : Ancienne approche TLLWrapper.def : Declares the module parameters LIBRARY "TLLWrapper.DLL"

47 EXPORTS DllCanUnloadNow @1 PRIVATE DllGetClassObject @2 PRIVATE DllRegisterServer @3 PRIVATE DllUnregisterServer @4 PRIVATE D_Interval_C_day @5 D_Interval_C_hour @6 Nouvelle approche extern "C" declspec(dllexport) Datum D_Interval_C_day(PG_FUNCTION_ARGS); extern "C" declspec(dllexport) Datum D_Interval_C_hour(PG_FUNCTION_ARGS); Les paramètres d export de la librairie sont implicitement inclus dans la déclaration des prototypes de fonction. On peut voir, l introduction du préfixe extern C, de même que la recommandation qui veut que les paramètres soient passés au serveur sous forme de pointeurs PG_FUNCTION_ARGS ; le type de retour des fonctions (datum) est un type générique qui peut être mappé à n importe quel type de valeurs effectivement retournées. 4.3.2.2 La définition des types Pour définir un nouveau type sous PostgreSQL, le guide du développeur PostgreSQL[15] recommande les étapes suivantes : 1. définir des fonctions d entrée/sortie pour le type ; 2. définir des différentes fonctions de manipulation du type (pour les différents traitements) ; 3. créer des opérateurs et classe d opérateurs associés au type ; 4. déclarer le type proprement dit (clause CREATE TYPE). Il est à noter que chacune des étapes de 1. à 3. est réalisée à la fois côté PLpgSQL et côté C (code source de la DLL). Dans l ancienne extension, seules les étapes 2. et une partie de l étape 4. étaient prises en compte ; une déclaration de type se faisait directement par un ordre CREATE TYPE AS, pas de fonctions d entrée/sortie, pas d opérateurs définis sur le type. Ainsi, un type d_timepoint_h était défini par : CREATE TYPE timepoint_h AS(y integer,m integer,d integer,h integer) Ceci a quelques inconvénients majeurs à savoir : du côté de la manipulation du nouveau type dans les tables, du fait qu il n existe pas de fonctions d entrée/sortie dédiées pour ce type, le serveur aura tendance à manipuler les colonnes déclarées de ce type comme des types enregistrement (type RECORD sous PostgreSQL) ; les opérations sur le type ainsi déclaré sont par conséquent fastidieuses : on doit faire un cast avant de pouvoir appliquer à un type ses propres fonctions ; par ailleurs, impossible de définir des d index sur ces types de données, puisqu il n existe pas d opérateurs, ni des classes d opérateurs ; Nous avons essayé de répondre à ces insuffisances, les principales actions prises sont les suivantes : Création des fonctions d entrée/sortie Pour chaque type à créer, nous définissons des fonctions d entrée/sortie pour ce type.

48 Ceci revient à proposer un format de données en entrée et un format de données en sortie. Les fonctions d entrée/sortie sont appelées par le système lorsque l utilisateur exécute un ordre SQL insert ou select sur une table où des colonnes du type correspondant sont déclarées. Dans le cas où ces fonctions ne sont pas définies, le système charge les fonctions d entrée/sortie par défaut et le type des colonnes insérées ou renvoyées est le type générique RECORD. C est ce qui justifie la nécessité de faire un cast lorsque l on veut maintenant effectuer des traitements avec des fonctions propres au type. Pour les types temporels, le format de date utilisé est le format standard ISO 8601/SQL, recommandé pour PostgreSQL 9. Il propose le format suivant : 1997-12-17 07:37:16 pour un d_timepoint_sec. Illustrons la création des fonctions d entrée/sortie pour le type d_timepoint_sec. Pour rappel, la création d une fonction pour un type et donc celle des fonctions d entrée/sortie, se fait à deux niveaux : 1. on implémente son comportement au bas niveau en C, ensuite on l exporte dans une librairie dynamique ; 2. ensuite on écrit le code PLpgSQL qui fait le pont entre le serveur et la librairie dynamique. Dans notre cas, la fonction d entrée prendra en paramètre une chaine de caractères (cstring) et renverra un d_timepoint_sec ; et l inverse pour la fonction de sortie. Nous donnons dans ce qui suit le prototype des fonctions C correspondantes et le code PLpgSQL associé. // Timepoint_Sec_IN extern "C" { PG_FUNCTION_INFO_V1(timepoint_sec_in);} Datum timepoint_sec_in(pg_function_args) // Timepoint_Sec_OUT extern "C" { PG_FUNCTION_INFO_V1(timepoint_sec_out);} Datum timepoint_sec_out(pg_function_args) Code PLpgSQL CREATE OR REPLACE FUNCTION Timepoint_Sec_In(cstring) RETURNS D_Timepoint_Sec AS $libdir/hermes.dll, timepoint_sec_in LANGUAGE C IMMUTABLE STRICT ; CREATE OR REPLACE FUNCTION Timepoint_Sec_Out(D_Timepoint_Sec) RETURNS cstring AS $libdir/hermes.dll, timepoint_sec_out LANGUAGE C IMMUTABLE STRICT ; La redéfinition des fonctions de traitement Les différentes fonctions de traitement ont été adaptées côté PLpgSQL pour mettre à profit les nouvelles possibilités d entrée/sortie des types qu elles manipulent. Ceci génère un gain de lisibilité, de simplicité du code et de simplicité des requêtes également. Illustrons ceci par l exemple suivant de la fonction d_timepoint_sec.f_equal. Elle prend en paramètres deux d_timepoint_sec et renvoie un booléen selon que les deux paramètres sont égaux ou non. Ancienne approche CREATE OR REPLACE FUNCTION d_timepoint_sec.f_equal(y1 integer, m1 integer, d1 integer,

49 h1 integer, mn1 integer, sec1 integer, y2 integer, m2 integer, d2 integer, h2 integer, mn2 integer, sec2 integer) RETURNS bool AS $libdir/hermes.dll, D_TimeP_Sec_C_equal LANGUAGE C IMMUTABLE STRICT ; Nouvelle approche CREATE OR REPLACE FUNCTION d_timepoint_sec.f_equal(d_timepoint_sec, D_Timepoint_Sec) RETURNS bool AS $libdir/hermes.dll, D_TimeP_Sec_C_equal LANGUAGE C IMMUTABLE STRICT; On constate effectivement que, dans la nouvelle approche, le nombre et le type de paramètres ont changé et la sémantique de la fonction est plus perceptible. Le type D_Timepoint_Sec est clairement un type à part entière (first citizen object) ici, plutôt qu une composition de types entiers. Création des opérateurs et classes d opérateurs Nous définissons des opérateurs et les classes d opérateurs associés à tous les types temporels. Le support spatial étant fourni par PostGIS, nous ne définissons pas d opérateurs pour les types spatiaux. L absence d opérateurs rend fastidieuse la manipulation des types. Pour de simples opérations de comparaison par exemple, il faut appeler une fonction dont le nom n est pas toujours commun. Cette complexité est d autant plus accentuée que l utilisation de ces fonctions nécessite de faire un CAST explicite sur les paramètres. Illustration Considérons l exemple suivant, représentant ce qui se faisait avant le développement des opérateurs et des fonctions d entrée/sortie. -- on crée une table t1 contenant deux attributs temporels CREATE TABLE t1( id integer; tp1 d_timepoint_sec; tp2 d_timepoint_sec ) -- on y insère deux lignes INSERT INTO t1 VALUES(1, 2010,3,4,15,27,6, 2011,12,5,6,56,36 ); INSERT INTO t1 VALUES(2, 2011,12,5,6,56,36, 2011,12,5,6,56,36 ); -- renvoyer les lignes où tp1=tp2 SELECT * FROM t1 WHERE D_timepoint_sec.f_equal(tp1::timepoint_sec,tp2::timepoint_sec); On constate la complexité de la dernière requête, pour une sémantique pourtant simple ; de même le format des données dans l ordre insert est assez ambigu. Après une définition correcte des fonctions d entrée/sortie et des opérateurs, suivie d une définition de type ; cette requête se résume simplement en ce qui suit : INSERT INTO t1 VALUES(1, 2010-03-04 15:27:06, 2011-12-05 06:56:36 ); INSERT INTO t1 VALUES(2, 2011-12-05 06:56:36, 2011-12-05 06:56:36 ); -- renvoyer les lignes où tp1=tp2 SELECT *

50 FROM T1 WHERE tp1=tp2; Il est à noter que de façon générale, nous avons surtout créé des opérateurs de comparaison pour les différents types. Ceci pour leur intérêt fondamental dans la manipulation des types de données spatio-temporelles. L extrait de code PLpgSQL suivant crée les opérateurs = (equal) et && (overlaps) pour le type d_timepoint_sec et la classe d opérateurs associée pour l indexation. CREATE OPERATOR = ( leftarg = D_Timepoint_Sec, rightarg =D_Timepoint_Sec, procedure = D_Timepoint_Sec.f_eq, commutator = =, negator = <>, restrict = eqsel, join = eqjoinsel ); -- Opérateurs d overlapping CREATE OPERATOR && ( leftarg = D_Timepoint_Sec, rightarg = D_Timepoint_Sec, PROCEDURE = D_Timepoint_Sec.f_overlaps, COMMUTATOR = &&, RESTRICT = areasel, JOIN = areajoinsel); -- classe d opérateurs associée CREATE OPERATOR CLASS timepoint_sec_ops DEFAULT FOR TYPE cube USING btree AS OPERATOR 1 <, OPERATOR 2 <=, OPERATOR 3 =, OPERATOR 4 >=, OPERATOR 5 > ; La déclaration de type Une fois les fonctions d entrée/sortie, les opérateurs et classes d opérateurs définis, on peut passer à la déclaration du type. Nous illustrons dans le code qui suit la création du type timepoint_sec. CREATE TYPE d_type.d_timepoint_sec ( internallength = 24, input = d_type.timepoint_sec_in, output = d_type.timepoint_sec_out, alignment = double ); Les attributs input et ouptput contiennent respectivement, les fonctions d entrée et de sortie ; l attribut internallength correspond à la taille allouée au type sur le disque.

51 4.3.2.3 Validation des données et gestion des exceptions Dans l ancienne extension, il était possible de se retrouver avec des dates invalides par exemple 2008-12-31 19:60:05, dans ce cas les minutes. Ceci du fait qu aucun test de validation n était effectué sur les données en entrée et que globalement, ces dernières étaient traitées commes des types RECORD. Pour résoudre ce problème, nous avons introduit dans le code C++ des fonctions d entrée, un appel au contructeur du type correspondant dans un try{} catch(e){} ; ainsi, lorsque l utilisateur tente d insérer des données invalides dans une table avec des colonnes de types temporels, il reçoit le message d erreur approprié. Par exemple, pour le type d_timepoint_sec, nous avons l extrait suivant : try { d_timepoint_sec temp(y, m, d, h, min, sec); } catch(d_error e) { ereport(error,(errcode(errcode_data_exception),errmsg("%s",e.what()))); PG_RETURN_POINTER(NULL); } La gestion des exceptions est particulièrement importante dans un objectif d amélioration de l intéractivité entre le serveur de base de données et le programmeur, l administrateur de base de données ou les applications clientes. En effet, étant donné que le langage C (qui supporte les fonctions du moteur de base de données au bas bas niveau) est particulièrement exigeant pour ce qui est de la gestion de la mémoire, il arrive qu une instruction délicate cause un dépassement de capacité de la pile mémoire, occasionnant un arrêt brutal du serveur. Pour éviter cela, il est important d envelopper toutes les instructions sensibles dans un bloc try{} catch(e){} et de générer des messages d erreurs appropriés pour que le programmeur ou l application cliente ait une idée de la source du problème. 4.3.3 Module spatio-temporel Le module spatio-temporel est au centre de notre travail, en ce sens qu il constitue la partie qui supporte au premier plan, la représentation et l interrogation des objets mobiles. L objectif à ce niveau est de mettre en oeuvre des structures de données et des opérations, qui permettent de créer et de manipuler les données de trajectoires. A cet effet, nous avons exploité les fonctionnalités spatiales qu offre PostGIS et les fonctionnalités disponibles sur la cartouche temporelle TAU-TLL, pour implémenter les types abstraits de données mobiles présentés à la section 3.1.3.3. Le module spatio-temporel se compose de deux scripts SQL : le script Hermes.sql, comportant la définition des types mobiles et les fonctions de manipulation ; le script Utilities.sql, contenant quelques fonctions de calcul utiles indépendantes des aspects spatio-temporelles (calcul de direction, calcul de vitesse, calculs angulaires, etc.). 4.3.3.1 Les types de données spatio-temporelles Concrètement, nous manipulons principalement les objets mobiles dont la forme peut être assimilée à un point (un utilisateur de téléphonie mobile, un véhicule équipé

52 d un GPS, un animal portant un émetteur, etc.). De ce fait, ces objets mobiles sont représentés par des types moving point. Ces types moving point utilisent à leur tour, la représentation en tranches (sliced representation) présentée à la section 3.1.3.3. Pour rappel, l idée de base dans la représentation en tranches, est de décomposer l évolution temporelle d une entité mobile en plusieurs phases ou tranches ; de telle sorte que, chaque tranche peut être décrite à l aide d une fonction du temps. La figure 4.2 présente les différentes phases du mouvement d un point mobile (moving point) : mouvement linéaire accéléré pour la période [t 1, t2) ; mouvement linéaire dééléré pour la période [t 4, t5) ; mouvement circulaire dans la période [t 2, t3) mouvement constant dans [t 3, t4) ; Figure 4.2 Représentation en tranches d un Moving-Point dans Hermes-MDC [28] Dans notre cas, le moving point est décomposé en unit moving point et chaque unit moving point est composé d un champ unit function décrivant le comportement (accélération, vitesse et direction), du mobile entre deux instants t 1 et t 2 correspondant à une période p. La position géographique du point mobile est décrite par des coordonnées cartésiennes, représentées par deux couples de réels représentant respectivement, la position initiale et la position finale de l objet dans une tranche donnée, indépendamment du type Point : :Geometry, proposé par PostGIS. La période p correspond au type temporel D_Period_Sec implémenté dans TAU-TLL. Ces différentes structures de données sont définies comme suit : CREATE TYPE d_type.unit_function_point AS ( xyi numeric[2],-- (xi, yi) position initiale xye numeric[2],-- (xe, ye) position finale xym numeric[2],-- (xm, ym) centre du cercle (en cas de mouvement circulaire) v integer,-- vitesse initiale (en cas d accélération) a integer,-- accélération f integer,-- angle balayé en cas de mouvement circulaire descr text -- type de mouvement(accéléré, décéléré, constant) ); CREATE TYPE d_type.unit_moving_point AS ( p d_type.d_period_sec,

53 ); m d_type.unit_function_point A partir de ces déclarations, le type moving point, est déclaré simplement comme un tableau de unit moving point ; de la manière suivante : CREATE TYPE d_type.moving_point AS d_type.unit_moving_point []; Pour des besoins de souplesse dans la conception des différentes opérations spatiotemporelles, nous définissons également des variantes mobiles de certains types scalaires notamment : les réels mobiles (moving real) ; les entiers mobiles (moving int) ; et les booléens mobiles (moving bool). La liste complète de ces déclarations est fournie en annexe A, pour Lhermes. 4.3.3.2 Les fonctions spatio-temporelles de Hermes L implémentation des opérations sur les types de données spatio-temporelles de Hermes obéit à quelques principes de base [28] : 1. concevoir les opérations de la façon la plus générique possible ; afin d éviter une prolifération des functions, il est important de regrouper les comportements similaires au sein d une même fonction ; 2. assurer une cohérence entre les opérations purement temporelles, les opérations purement spatiales et les opérations spatio-temporelles ; pour atteindre cet objectif, nous procédons en trois étapes : dans un premier temps, on recherche les opérations purement spatiales susceptibles d avoir une sémantique temporelle ; par exemple la distance euclidienne entre deux points ; ensuite on utilise les fonctionalités purement temporelles qu offre TAU-TLL, pour construire des variantes des opérations choisies à la première étape, qui sont fonction du temps. Généralement, il suffit d ajouter un argument de type D_Timepoint_Sec (un instant), à la fonction purement spatiale, pour obtenir sa valeur à un instant ; par exemple on peut s intéresser à la distance entre deux points à un instant t de la ligne du temps ; la dernière étape consiste à récupérer les opérations de l étape précédente (celles qui dépendent du temps), et à leur retirer leur dimension temporelle fixe (au sens : à un instant précis de la ligne du temps ), pour construire des variantes dites mobiles (au sens : indépendamment de tout instant de la ligne du temps ), pour ces opérations ; Cette méthode est appelée lifting. Pour revenir à l exemple de l opération distance, le processus ainsi décrit, permet simplement de construire la distance entre deux points mobiles (time varying distance), ce qui correspond à la distance spatio-temporelle, le résultat de cette opération est de type moving real ; 3. s assurer de la stabilité et de la consistance de la base de données ; l ajout de nouvelles règles et des opérations au langage d interrogation de la base de données, ne doit pas menacer l intégrité de la base de données ;

54 4. développer des opérations uniquement pour des phénomènes intéressants pour le domaine étudié ; dans notre cas, nous prenons principalement en compte les relations d ordre, le relations topologiques, etc. Liste de fonctions. Nous présentons par catégorie, quelques opérations importantes de la cartouche spatio-temporelle de Hermes. 1. Consistance de la base de données Cette catégorie de fonctions permet à l utilisateur de vérifier certaines contraintes liées aux objets mobiles lors de leur construction. Nous présentons deux de ces fonctions ici : boolean check sorting(moving point) Cette opération permet de s assurer que les périodes (D Period Sec) pendant lesquelles, les différents (unit moving point) qui composent le (moving point), sont chronologiquement ascendantes. Cette vérification est importante, pour s assurer de l évolution de l objet mobile dans la ligne du temps. boolean check disjoint(moving point) Cette méthode s assure que les périodes (D Period Sec) pendant lesquelles, les différents (unit moving point) qui composent le (moving point), ne se chevauchent pas. 2. Projection et Interaction des domaines spatial et temporel. Cette catégorie regroupe les fonctions courantes dans la gestion des objets mobiles. Point at instant(d Timepoint Sec, moving point). Cette opération permet d avoir la position d un point mobile à un instant donné. Cette opération est certainement la plus importante pour notre extension. En effet, elle a un double intérêt : premièrement, au point de vue conceptuel, nous avons définit la trajectoire d un objet mobile comme une fonction du temps (cf. section 2.2). Cette opération, grace à la technique de l interpolation linéaire présentée en 2.6.1.1, matérialise la continuité de cette fonction dans l espace à trois dimensions (2D + temps). La deuxième raison de son importance réside dans le fait que la plupart des autres fonctions spatio-temporelles l utilise dans leur implémentation. moving point at period(d Period Sec, moving point) Cette fonction renvoie, la partie de la trajectoire d un objet mobile correspondant à une période donnée. Le résultat de cette opération est donc de type moving point. D Period Sec [] f temp element(moving point) Cette fonction renvoie un ensemble de périodes de la ligne du temps, correspondant à la concaténation des différentes périodes pendant lesquelles les (unit moving point) qui composent le point mobile sont définis. En d autres termes, cette fonction n est rien d autre que la projection d un moving point dans le domaine temporel. La figure 4.3 illustre cette projection. moving point at temp element(d Period Sec []). Cette opération renvoie des parties de la trajectoire du mobile dans les périodes spécifiées. Point f initial(moving point). Renvoie la valeur de la fonction at instant, au tout premier instant de la trajectoire ; Point f final(moving point).

55 Figure 4.3 Projection d un moving point dans le domaine temporel Similaire à la fonction précédente, mais l instant considéré est la borne supérieure de la période de définition du dernier unit moving point (dernier instant de la trajectoire). LineString f trajectory(moving point). Cette fonction retourne un LineString correspondant à la projection du point mobile dans le plan cartésien. Cette projection construit segment par segment, l objet LineString en joignant les différents morceaux construits en considérant la position aux extrémités de chaque unit moving point et une position intermédiaire. Si les trois positions (les deux extrémités et la position intermédiaire) sont alignés, le morceau est un segment de droite sinon le morceau correspond à un arc. 3. Opérations de distance Hermes supporte deux opérations pour le calcul de distance entre deux objets mobiles. La première opération qui renvoie un réel, correspond à la distance euclidienne (indépendamment du temps), qui calcule la distance minimale qui sépare les deux points les plus proches entre les trajectoires de deux objets mobiles dans le plan. La deuxième opération calcule la distance entre deux mobiles à tous les instants et la valeur de retour est de type moving real. 4.4 Light Hermes (Lhermes) 4.4.1 Insuffisances de Hermes L implémentation actuelle de Hermes, présentée à la section précedente a quelques limites : 1. La lourdeur de la cartouche temporelle TAU-TLL. Comme nous l avons souligné à la section 4.3.2, TAU-TLL implémente vingt-deux (22) types temporels ; si cela constitue une grande souplesse, en terme de modélisation ou de représentation des phénomènes temporels, ce n est pas le cas en ce qui concerne la gestion des données de trajectoires qui nous intéresse ici. En effet, on constate que dans la cartouche spatio-temporelle, seuls 2 types temporels sont effectivement utilisés : le type D_Timepoint_Sec et le type D_Period_Sec. Par ailleurs, l implantation de

56 ces deux types de données est particulièrement coûteuse en espace mémoire et certainement en temps d accès disque. Le premier (D_Timepoint_Sec) est représenté sur 28 octets alors que D_Period_Sec tient sur 56 octets. Etant donné que, pour la gestion des données de trajectoires, nous traitons d énormes volumes de données, avec une telle représentation, on arrive facilement à une occupation exponentielle de l espace de stockage, ajoutés à cela les coûts en temps d accès liés. Dès lors, il est nécessaire d envisager une autre façon de représenter les types Période utilisés dans la définition des différents types mobiles. Temporal PostgreSQL que nous présentons en section 4.4.2, propose une solution à ce problème. 2. Une faible utilisation des fonctionnalités PostGIS. La composante spatiale, dans la définition actuelle des points mobiles (unit moving point) de Hermes, utilise des tableaux de réels pour représenter les coordonnées géographiques d un point. Dans les fonctions spatio-temporelles, pour utiliser certaines fonctionnalités spatiales offertes par PostGIS, on est obligé de faire un cast explicit de ces coordonnées vers des objets de type Point (type Geometry de PostGIS). Dès lors, on pourrait simplement envisager de représenter la composante spatiale d un unit moving point, directement par un objet de type Point de PostGIS. 4.4.2 Temporal PostgreSQL Temporal PostgreSQL est une initiative de Jeff Davis, développeur actif de la communauté PostgreSQL. L objectif de Temporal PostgreSQL (TPg) est de mettre à la disposition de la communauté, un ensemble d outils pour la gestion du temps dans les bases de données PostgreSQL, afin de dépasser les limites constatées avec SQL-92, notamment la non prise en charge des types périodes [9]. TPg fournit les structures de données, les fonctions, les opérateurs et classes d opérateurs (pour l indexation), nécessaires à la manipulation des périodes dans PostgreSQL. Le projet ne fait pas actuellement partie de l arbre de projets de PostgreSQL, mais l arrivée de SQL-2011, va certainement suscité un souffle nouveau à ce projet. Les sources de TPg sont disponibles sur le site de la communauté des développeurs (PgFoundry) en libre télechargement. 4.4.2.1 Type de données dans Temporal PostgreSQL Temporal PostgreSQL utilise les types standards TimestampTZ (Timestamp with timezone), supporté par PostgreSQL. L idée est de construire un type Period (équivalent de D Period Sec), pour la gestion des périodes sur l axe du temps, en utilisant comme bornes des TimestampTZ. Ceci a un double intérêt pour nous, dans le développement de l extension : en utilisant le type standard TimestampTZ, dans la construction du type Period, on s appuie sur un standard et on peut donc bénéficier de toute la richesse des opérations standards SQL sur ce type ; le deuxième avantage vient combler l une des insuffisances relevées au point 4.4.1, à savoir la taille de l espace occupé par un D Period Sec de TAU-TLL. En effet, nous avons relevé qu un D Period Sec occupait actuellement 56 octets (28 octets pour chaque D Timepoint Sec représentant la borne), contre 16 octets pour un type Period de TPg.

57 4.4.2.2 Fonctions et opérateurs de Temporal PostgreSQL TPg supporte la plupart des opérations et opérateurs temporels standards définis au point3.1.1.1. Il a cependant été nécessaire d adapter certaines implémentations TPg, de ces fonctions standards, pour respecter certaines règles de nommage que nous utilisions dans notre extension. Mais, Il a surtout été question d étendre TPg pour supporter des fonctions spécifiques à TAU-TLL, utiles dans Hermes ; dans le même sens, nous avons dévéloppé pour TPg, des fonctions de support pour la prise en charge des index GiST. Le tableau 4.4, présente quelques fonctions de TAU-TLL et leur équivalent dans Temporal PostgreSQL. Description TAU-TLL Temporal PostgreSQL Borne inférieure de la f begin first période Borne supérieure de la f end last période Opérateur strictement f l before inférieur Opérateur strictement f b after supérieur Fonction contain f contains contains Fonction overlaps f overlaps overlaps Table 4.4 Quelques opérations de base dans TAU-TLL et Temporal PostgreSQL 4.4.3 Type de données dans Lhermes Sur la base des insuffisances listées en section 4.4.1, nous avons défini une version légère de Hermes que nous avons appelé Light Hermes (Lhermes). Concrètement, il est question de remplacer la composante temporelle (représentée par un D Period Sec de TAU-TLL), de chaque unit moving point, par un type temporel Period de TPg. Plus loin, pour les moving point, afin d exploiter la riche bibliothèque de fonctions de PostGIS, nous représentons également la composante spatiale par un objet Geometry de PostGIS. La nouvelle définition du type moving point est : CREATE TYPE d_type.unit_function_point AS ( posi GEOMETRY,-- position initiale pose GEOMETRY,-- position finale posm GEOMETRY,-- centre du cercle (en cas de mouvement circulaire) v integer,-- vitesse initiale (en cas d accélération) a integer,-- accélération f integer,-- angle balayé en cas de mouvement circulaire descr text -- type de mouvement(accéléré, décéléré, constant) ); CREATE TYPE d_type.unit_moving_point AS ( p period, m d_type.unit_function_point

58 ); CREATE TYPE d_type.moving_point AS d_type.unit_moving_point[]; La définition complète des autres types moving real, moving int et moving bool, sera fournie en annexe. 4.4.4 Fonctions de Lhermes Les fonctions de Lhermes sont exactement les mêmes que celles définies pour Hermes ; moyennant cependant quelques adaptations dans leur implémentation pour exploiter au mieux, les fonctionnalités offertes d une part, par le type standard TimestampTZ, utilisé par Temporal PostgreSQL. Et les fonctionnalités offertes par le type Geometry d autre part. Finalement, nous disposons d une extension fonctionnelle et légère pour la manipulation des objets mobiles. C est cette extension que nous utilisons au chapitre suivant pour évaluer son utilisabilité et ses performances sur un cas pratique d utilisation : le benchmark BerlinMOD.

Chapitre 5 Cas d utilisation de Lhermes 5.1 Introduction Dans ce chapitre, nous nous intéressons à l application de notre extension à un cas pratique. Il sera en effet question d évaluer l effectivité et les performances des structures de données et des opérations développées, pour représenter et interroger un jeu de données, le benchmark BerlinMOD 1, généré à partir d une simulation de la mobilité dans la ville de Berlin. Le test est réalisé sur un ordinateur dont on peut retrouver les caractéristiques dans le tableau 5.1. Processeur RAM HDD Intel Core i7 CPU 920, 2.67 GHz. 4 Go. 120 Go. Table 5.1 Spécifications de la machine de test 5.2 Présentation du BerlinMOD Le BerlinMOD est un test de performance (benchmark) pour des systèmes de gestion de base de données spatio-temporels. C est un outil développé par des chercheurs de l université de Hagen en Allemagne dont l objectif est double [11] : 1. mettre à la disposition de la communauté scientifique, un moyen de comparer les différentes implémentations des fonctionnalités d un système de gestion de base de données spatio-temporelles. Parmi ces fonctionnalités : les types de données, les index et les opérateurs spatio-temporels ; 2. évaluer les performances des SGBD spatio-temporels. 5.2.1 Description du jeu de données Le BerlinMOD s intéresse principalement à l évaluation des performances des requêtes sur les objets mobiles de type moving point, présentés dans les chapitres 3, 4 et en section 4.4.3. Le jeu de données du BerlinMOD est issu d une simulation de la mobilité d un échantillon d automobiles, dans le réseau routier de la ville de Berlin. Le scénario est basé sur l observation de travailleurs allant et venant entre leur domicile 1. Berlin Moving Objects Database 59

60 et leur lieu de travail. Les données du benchmark sont générées à partir d un script paramétrable, exécuté sur le SGBD SECONDO. Le script reçoit comme entrées, des données spatiales réelles du réseau routier de Berlin. Différents facteurs de dimensionnement (scale factor), sont utilisés pour générer le jeu de données. Dans le cadre de notre application, nous nous limiterons au facteur 0.05. Le scale factor 0.05 correspond à 6 jours d observation de 447 véhicules, produisant un total de 15045 voyages (trip) et 2998674 unit moving point en moyenne. Les données sont disponibles sur le site du projet[11], sous format CSV 2. Le jeu de données est composé de 8 fichiers CSV, contenant des données brutes (principalement des relevés GPS des différents mouvements de véhicules). Chaque fichier CSV est décrit par une relation. Le benchmark utilise deux approches différentes pour représenter les mouvements des véhicules : la première approche dite Object Based (OBA), représente pour chaque véhicule, l historique des positions couvrant l entiereté de la période d observation dans un fichier unique, contenant également les informations générales du véhicule (Immatriculation, Type, Modèle, etc.) ; la deuxième approche dite Trip Based (TBA), découpe l historique entière de chaque véhicule en plusieurs morceaux ou trip. L ensemble des trips d un véhicule est stocké en plusieurs tuples, dans une relation, avec une référence sur le véhicule concerné. Les informations du véhicule sont quant à elles stockées dans une autre table. 5.2.2 Relations et requêtes Pour notre application, nous utilisons l approche OBA. Les principales relations utilisées sont décrites dans le tableau 5.2. Pour pouvoir être utilisées sur les types et les Fichier Relation Description datamcar.csv datamcar{moid, Licence, Type, Informations générales sur un Model} véhicule ; clé primaire : Moid journey.csv Journey{Moid, Licence, Type, Model, stocke l historique complet Tstart, Tend, Xstart, Ystart, Xend, Yend} (sur plusieurs lignes), d un véhicule et les informations sur le véhicule, Approche OBA. queryinstants.csv QueryInstants{Id, Instant} Echantillons d instants utilisés dans les requêtes querylicences.csv QueryLicences{Moid, Licence, Informations sur les véhicules Type, Model} queryperiods.csv QueryPeriods{Id, Begin, End} Echantillons de Période utilisées dans les requêtes. querypoints.csv QueryPoints{Id, Pos x, Pos y} Echantillons de Point utilisés dans les requêtes. queryregions.csv QueryRegions{Id, Vertex x, Vertex y} Table 5.2 BerlinMOD : description des relations opérations de notre extension, ces données ont subi des transformations. 2. Comma Separated Values Echantillons de Région utilisées dans les requêtes.

61 En ce qui concerne les requêtes, le BerlinMOD propose une batterie de 17 requêtes basées sur des prédicats de données standard, spatiale, temporelle et spatio-temporelles. 5.3 Méthodologie de test Pour chaque requête exécutée, PostgreSQL construit un plan de requête (Query Plan). Les performances du système sont liées à ce plan de requête, pour une structure de données particulière. Pour mettre en oeuvre le plan de requête, le système utilise un planificateur complexe pour essayer d établir le meilleur plan possible pour une requête donnée. Chaque plan de requête est constitué de noeuds appelés noeud de plan qui correspondent aux principales étapes de l exécution de la requête. Par exemple, renvoyer des lignes brutes d une table (noeud hash), sélectionner des lignes répondant à une condition donnée, renvoyer les lignes issues d une jointure (noeud hash Join), effectuer un tri(noeud sort), boucler sur une condition (noeud nested loop), fusionner des tuples (noeud merge join), charger des données en mémoire (noeud materialize), etc. Le benchmark consiste à exécuter les 17 requêtes proposées par le test de performance sur l extension qu on veut évaluer. Ensuite, on compare les temps d exécution avec ceux obtenus sur SECONDO. Pour notre extension, nous avons procédé comme suit : dans un premier temps, nous exécutons chaque requête à froid (les données ne sont pas disponibles en mémoire), s en suivent deux exécutions à chaud ; puis nous calculons la moyenne des trois exécutions ; la deuxième étape consiste à exécuter sur chaque requête, la commande EXPLAIN ANALYZE de PostgreSQL, qui permet d avoir des informations (statistiques) sur l exécution d une requête, notamment le plan d exécution et les détails de coûts en temps processeur et de taille des résultats ; à l étape 3, nous comparons ces résultats avec ceux obtenus à la première étape. Le temps d exécution retenu pour la requête est le plus grand entre ces deux valeurs. Parmi les informations fournies par EXPLAIN ANALYZE, nous allons nous intéresser : au coût d exécution moyen de la requête. Le coût est mesuré en unités arbitraires, déterminés par les paramètres de coût du planificateur, sur la base du coût en unité de récupération d une page sur disque ; à la façon dont les données sont accédées dans les tables (accès séquentiel, indexé ou Bitmap) ; au nombre de lignes retournées par la requête ainsi qu à la taille (en octets) de chaque ligne ; Par ailleurs, pour visualiser le plan de requête, nous utilisons l utilitaire de visualisation fourni par le client pgadmin Environnement graphique d administration pour PostgreSQL. A la fin, nous présentons une synthèse des résultats (tableau 5.3), accompagnée d une interprétation. 5.4 Requêtes et résultats 1. Requête 1 : Enoncé : Quels sont les modèles de véhicules dont la plaque d immatriculation se trouve dans QueryLicences? Formulation SQL :

62 SELECT DISTINCT ll.licence AS licence, c.model AS model FROM berlinmod.datascar c, berlinmod.querylicences ll WHERE c.licence = ll.licence; Query Plan :(fig.5.1) Figure 5.1 Query Plan de la requête 1 L objectif de cette première requête est de vérifier les performances du système sur les types standards et les index. En effet, certains SGBD ont tendance à aller chercher au-delà des colonnes intervenant dans une requête donnée. Par exemple dans notre requête, un mauvais SGBD pourrait accéder (même partiellement) à la colonne trip de la table Datascar alors que cela n est absolument pas nécessaire dans cette requête. 2. Requête 2 : Enoncé : Combien de véhicules sont de type passager? Formulation SQL : SELECT COUNT (licence) FROM berlinmod.datascar WHERE type = passenger ; Query Plan :(Fig.5.2) L objectif est le même que celui de la requête 1, c est-à-dire tester les fonction- Figure 5.2 Query Plan de la requête 2 nalités standards du SGBD. Une particularité cependant, c est l utilisation d un prédicat de sélection et d une fonction d agrégation. 3. Requête 3 : Enoncé : Par quels Points sont passés les véhicules dont la plaque d immatriculation est stockée dans QueryLicences1 (les 10 premiers tuples de QueryLicences),

63 à chaque instant de QueryInstants1 (les 10 premiers tuples de QueryInstants)? Formulation SQL : SELECT ll.licence AS licence, ii.instant AS instant, lhermes.at_instant(ii.instant, c.trip) AS pos FROM berlinmod.datascar c, berlinmod.querylicences1 ll, berlinmod.queryinstants1 ii WHERE c.licence = ll.licence AND lhermes.present(ii.instant, c.trip); Query Plan :(Fig.5.3) Figure 5.3 Query Plan de la requête 3 4. Requête 4 : Enoncé : Donner les plaques d immatriculation des véhicules qui sont passés par des points de QueryPoints? Formulation SQL : SELECT ST_astext(qp.pt) AS pos, c.licence AS licence FROM berlinmod.datascar c, berlinmod.querypoints qp WHERE lhermes.passes(qp.pt, c.trip); Query Plan :(Fig.5.4) Figure 5.4 Query Plan de la requête 4

64 5. Requête 5 : Enoncé : Quelle est la distance minimale entre les lieux par lesquels un véhicule de QueryLicences1 est passé et ceux par lesquels un véhicule de QueryLicences2 est passé? Formulation SQL : SELECT ll1.licence AS licence1, ll2.licence AS licence2, st_distance (lhermes.f_trajectory (v1.trip), lhermes.f_trajectory(v2.trip)) AS dist FROM berlinmod.datascar v1, berlinmod.datascar v2, berlinmod.querylicences1 ll1, berlinmod.querylicences1 ll2 WHERE v1.licence = ll1.licence AND v2.licence = ll2.licence AND v1.licence <> v2.licence; Query Plan :(Fig.5.5) Figure 5.5 Query Plan de la requête 5 6. Requête 6 : Enoncé : Donner les paires de plaques d immatriculation de véhicules de type truck qui ont été à moins de dix mètres l un de l autre? Formulation SQL : SELECT distinct v1.licence AS licence1, v2.licence AS licence2 FROM berlinmod.datascar v1, berlinmod.datascar v2 WHERE v1.licence <> v2.licence AND v1.type = truck AND v2.type = truck AND ST_dwithin(lhermes.f_trajectory(v1.trip), lhermes.f_trajectory(v2.trip),10.0); Query Plan :(Fig.5.6) 7. Requête 7 : Enoncé : Quelles sont les plaques d immatriculation des véhicules de type passager qui ont atteint les points de QueryPoints1 avant tous les autres véhicules de

65 Figure 5.6 Query Plan de la requête 6 type passager durant la totalité de la période d observation? Formulation SQL : SELECT ST_astext (pp.pt) AS pos, v1.licence AS licence FROM berlinmod.datascar v1, berlinmod.querypoints1 pp WHERE lhermes.passes (pp.pt, v1.trip) AND v1.type = passenger AND lhermes.get_time_point(pp.pt, v1.trip) <= ALL ( SELECT lhermes.get_time_point (pp2.pt, v2.trip) AS firsttime FROM berlinmod.datascar v2, berlinmod.querypoints1 pp2 WHERE lhermes.passes (pp.pt, v2.trip) AND v2.type = passenger ); Query Plan :(Fig.5.7) 8. Requête 8 : Enoncé : Quelles est la distance totale parcourue par les véhicules de QueryLicences1 durant les périodes de QueryPeriods1? Formulation SQL : SELECT v1.licence, pp.per_sec AS period, ST_Length(lhermes.f_trajectory(lhermes.at_period(pp.per_sec, v1.trip))) AS dist FROM berlinmod.datascar v1, berlinmod.queryperiods1 pp, berlinmod.querylicences1 ll WHERE v1.licence = ll.licence AND contains(lhermes.deftime(v1.trip),pp.per_sec); Query Plan :(Fig.5.8)

66 Figure 5.7 Query Plan de la requête 7 Figure 5.8 Query Plan de la requête 8 9. Requête 9 : Enoncé : Quelle est la plus longue distance parcourue par chaque véhicule durant chacune des périodes de QueryPeriods? Formulation SQL : SELECT pp.per_sec as period, MAX(ST_Length(lhermes.f_trajectory(lhermes.at_period(pp.per_sec, v1.trip)))) AS dist FROM berlinmod.datascar v1, berlinmod.queryperiods pp WHERE contains(lhermes.deftime(v1.trip),pp.per_sec) GROUP BY pp.per_sec; Query Plan :(Fig.5.9) 10. Requête 10 : Enoncé : Quand et où les véhicules de QueryLicences1 ont rencontré les autres véhicules (distance inférieure à 3m l un de l autre) et quelles sont les plaques

67 Figure 5.9 Query Plan de la requête 9 d immatriculation de ces derniers? Formulation SQL : SELECT v1.licence AS querylicence, v2.licence AS otherlicence, lhermes.at_temp_element(lhermes.f_temp_element(v1.trip), v2.trip) AS pos FROM berlinmod.datascar v1, berlinmod.datascar v2, berlinmod.querylicences1 ll WHERE v1.licence = ll.licence AND v2.licence <> v1.licence AND ST_dwithin(lhermes.f_trajectory(v1.trip), lhermes.f_trajectory(v2.trip), 3.0); Query Plan :(Fig.5.10) Figure 5.10 Query Plan de la requête 10 11. Requête 11 : Enoncé : Quels sont les véhicules qui sont passés par un point de QueryPoints1 à un instant de QueryInstants1? Formulation SQL : SELECT c.licence AS licence, qp.pt AS pos, ii.instant AS instant FROM berlinmod.datascar c, berlinmod.querypoints1 qp, berlinmod.queryinstants1 ii WHERE lhermes.at_instant(ii.instant, c.trip) = qp.pt AND lhermes.check_sorting(c.trip); Query Plan :(Fig.5.11)

68 Figure 5.11 Query Plan de la requête 11 12. Requête 12 : Enoncé : Quels sont les véhicules qui se sont rencontrés en un point de Query- Points1 à un instant de QueryInstants1? Formulation SQL : SELECT pp.pt AS pos, ii.instant AS instant, c1.licence AS licence1, c2.licence AS licence2 FROM berlinmod.datascar c1, berlinmod.datascar c2, berlinmod.querypoints1 pp, berlinmod.queryinstants1 ii WHERE lhermes.at_instant(ii.instant, c1.trip) = pp.pt AND lhermes.at_instant(ii.instant, c2.trip) = pp.pt AND lhermes.check_sorting(c1.trip) AND lhermes.check_sorting(c2.trip); Query Plan :(Fig.5.12) Figure 5.12 Query Plan de la requête 12 13. Requête 13 : Enoncé : Quels sont les véhicules qui sont entrés dans une région de QueryRegions1 durant une période de QueryPeriods1? Formulation SQL : SELECT st_astext(rr.region) AS region, pp.per_sec AS period, c.licence AS licence

69 FROM berlinmod.datascar c, berlinmod.queryregions1 rr, berlinmod.queryperiods1 pp WHERE ST_Relate(lhermes.f_trajectory(lhermes.at_period(pp.per_sec, c.trip)), rr.region, FF*FF**** ); Query Plan :(Fig.5.13) Figure 5.13 Query Plan de la requête 13 14. Requête 14 : Enoncé : Quels sont les véhicules qui sont entrés dans une région de QueryRegions1 à un instant de QueryInstants1? Formulation SQL : SELECT rr.region AS region, ii.instant AS instant, c.licence AS licence FROM berlinmod.datascar c, berlinmod.queryregions1 rr, berlinmod.queryinstants1 ii WHERE ST_Within(lhermes.at_instant(ii.instant, c.trip), rr.region) AND lhermes.check_sorting(c.trip); Query Plan :(Fig.5.14) Figure 5.14 Query Plan de la requête 14

70 15. Requête 15 : Enoncé : Quels sont les véhicules qui sont passés par un point de QueryPoints1 durant une des périodes de QueryPeriods1? Formulation SQL : SELECT st_astext(po.pt) AS pos, pr.per_sec AS period, c.licence AS licence FROM berlinmod.datascar c, berlinmod.querypoints2 po, berlinmod.queryperiods2 pr WHERE NOT (lhermes.isempty(lhermes.f_timepoint(po.pt, lhermes.at_period(pr.per_sec, c.trip)))); 16. Requête 16 : Enoncé : Lister les paires de plaques d immatriculation, la première issue de Query- Licences1 et la seconde issue de QueryLicences2, dont les véhicules correspondant sont dans une région de QueryRegions1 durant une période de QueryPeriods1 mais qui ne se rencontrent pas? Formulation SQL : SELECT pp.per_sec AS period, rr.region AS region, c1.licence AS licence1, c2 AS licence2 FROM berlinmod.datascar c1, berlinmod.datascar c2, berlinmod.queryregions1 rr, berlinmod.queryperiods1 pp, berlinmod.querylicences1 ll1, berlinmod.querylicences1 ll2 WHERE c1.licence = ll1.licence AND c2.licence = ll2.licence AND ll1.licence <> ll2.licence AND lhermes.passes(rr.region, lhermes.at_period (pp.per_sec, c1.trip)) AND lhermes.passes(rr.region, lhermes.at_period (pp.per_sec, c2.trip)); AND lhermes.isempty(lhermes.f_enter(lhermes.at_period(pp.per_sec, lhermes.f_intersection(c1.trip, c2.trip)), rr.region)); Query Plan :(Fig.5.15) 17. Requête 17 : Enoncé : Quels sont les points de QueryPoints qui ont été visités par le maximum de véhicules différents? Formulation SQL : CREATE or REPLACE VIEW lhermes.poscount AS SELECT pp.pt AS pos, COUNT (c.licence) AS hits FROM berlinmod.querypoints1 pp, berlinmod.datascar c WHERE lhermes.passes(pp.pt, c.trip) GROUP BY pp.pt; -- FROM lhermes.poscount AS n WHERE n.hits = (SELECT MAX (hits) FROM lhermes.poscount); Query Plan :(Fig.5.16)

71 Figure 5.15 Query Plan de la requête 16 Figure 5.16 Query Plan de la requête 17 5.5 Synthèse et analyse des résultats Le tableau 5.3 présente la synthèse des résultats de l exécution des requêtes du benchmark BerlinMOD sur Lhermes. Ces résultats sont comparés avec ceux obtenus sur le SGBD SECONDO utilisé dans la conception du benchmark, pour le même facteur d échelle. 5.6 Analyse La comparaison des courbes représentant respectivement l exécution des différentes requêtes du benchmark sur SECONDO et Lhermes à la figure 5.17), permet de dégager un net avantage de SECONDO au détriment de Lhermes pour la grande majorité des 17 requêtes. En effet, mises à part les requêtes Q01 et Q02, qui portent sur des types de données standards et pour lesquelles le SGBD PostgreSQL a une très bonne réputation,

72 Requête Coût Moyen en ms(lhermes) Coût Moyen en ms (SECONDO) Q01 0.8 1 Q02 0.233 1 Q03 220521 899 Q04 371866 239 Q05 571321 13488 Q06 325831 38149 Q07 123258 1818 Q08 304863 2263 Q09 402882 1014490 Q10 361601 35522 Q11 297209 888 Q12 311178 79 Q13 145823 42408 Q14 574785 900 Q15 n/a 1679 Q16 1518544 250423 Q17 337474 18330 Table 5.3 Comparaison des coûts d exécution sur Lhermes et SECONDO. Figure 5.17 Comparaison des coûts d exécution sur Lhermes et SECONDO les performances de Lhermes sont en dessous de celles de SECONDO pour le reste des requêtes. On observe cependant un sursaut d orgueil de Lhermes pour la requête Q09, ceci se justifie par le fait que c est une requête purement spatiale et de ce fait, les index GiST utilisés par PostGIS y joue un grand rôle. Les faibles performances de Lhermes par rapport à SECONDO pour le reste des requêtes (en grande partie spatio-temporelle), peut se justifier à plusieurs niveaux :

5.6.1 Au niveau de la représentation physique des types de données SECONDO a été conçu pour des types de données non standards et particulièrement pour le support des données spatio-temporelles. A ce titre, ses concepteurs opèrent au plus bas niveau du catalogue de données du SGBD, pour assurer une implémentation de bas niveau aux unit types (unit moving real, unit moving point, etc.), issus de la représentation en tranches. En d autres termes, les objets mobiles de SECONDO sont représentés au niveau interne (couche langage de développement, langage C par exemple), du SGBD et non pas au niveau utilisateur (couche langage d interrogation, SQL par exemple). Ceci a pour avantage de minimiser les temps d accès de telles structures puisqu elles sont stockées à des emplacements mémoires mitoyens. Pour Lhermes, les unit types, éléments de base pour la représentation des objets mobiles, sont construits à la couche utilisateur ; par association comme nous l avons vu au chapitre précédent, des types spatiaux et des types temporels. Ceci a certainement une influence sur le stockage des données sur disque et donc leur accès. En effet, une première conséquence de cette façon de représenter ces types de données est la façon dont on accède à leur emplacement mémoire. Pendant que pour SECONDO cet accès se fait en une étape, parce que le type est représenté de façon interne à un emplacement mémoire unique ; pour Lhermes, cette accès peut nécessiter des accès multiples puisqu il peut être nécessaire de chercher les composants d un seul unit type à deux endroits éloignés (un emplacement mémoire pour la composante spatiale et un emplacement mémoire pour la composante temporelle). Une deuxième conséquence de cette repésentation est la façon dont les moving type de Lhermes sont construits à partir des unit type. Dans l actuelle implémentation de Lhermes, un moving type est construit comme un tableau de unit type correspondant (cf. 4.4.3) - implémentation de la représentation en tranches. Cela signifie qu un moving point par exemple, n est rien d autre qu un tableau de unit moving point. Cette façon d implémenter la représentation en tranches, pour les types mobiles à l aide des tableaux, est héritée d Oracle (on se souvient que Hermes sur PostgreSQL et par extension Lhermes, sont basés sur Hermes-MDC d Oracle), qui utilisait des structures de données particulières appelées tables nichées, présentant de bonnes performances en terme d accès aux éléments. Or, il se trouve que PostgreSQL ne supporte pas de telles structures ; nous les avons remplacées par de simples tableaux. Dès lors, le niveau des performances de Lhermes peut également être lié à cet aspect. 5.6.2 Au niveau de l indexation A l état actuel de son implémentation, Lhermes ne propose pas d index spatiotemporel. Nous avons défini des méthodes d accès GiST pour le module temporel et PostGIS propose des méthodes similaires pour le module spatial. Les faibles performances actuelles de Lhermes peuvent se justifier par cette insuffisance. L implémentation de méthodes d accès GiST pour le module spatio-temporel pourrait améliorer de façon significative la qualité de nos résultats. Cette problématique est intimement liée à la précédente. En effet, pour pouvoir développer des méthodes d accès (GiST, B-Tree, R-Tree, etc.), pour un type donné, on doit pouvoir manipuler le type au niveau de sa représentation interne. Cela signifie qu on doit disposer d une représentation interne du type de données pour pouvoir créer les différentes fonctions de support des index. Or, comme souligné plus haut, les types de Lhermes sont définis à une couche supérieure. Cette problématique, de même que la précédente constituent des axes de recherche futurs, pour l amélioration de Lhermes. 73

Chapitre 6 Conclusion L objectif principal, lorsqu on parle de systèmes de gestion de données de trajectoires, est qu on voudrait être capable de représenter et d interroger dans une base de données, l évolution d un objet mobile. Un objet mobile est un objet dont la position change au cours du temps ; par exemple un piéton, un véhicule en mouvement, un animal équipé d un émetteur, etc. Un tel objet peut être assimilé à un Point mobile dans la mesure où seule la position dans le temps intéresse les analystes. Une autre catégorie d objet mobile comprend les objets dont la forme change au cours du temps ; par exemple un ouragan, l avancée d un désert, une armée dans un champ de bataille, un nuage de pollution, une épidémie, etc., de tels objets sont modélisés comme des régions mobiles. Etendre les SGBD classiques pour manipuler des objets mobiles, signifie développer des nouvelles fonctionnalités dans le modèle de données du SGBD qui lui permettent de décrire de telles entités et d enrichir son langage d interrogation, avec de nouvelles opérations. Pour atteindre cet objectif, il existe deux principales approches [18] : la première consiste à construire une couche au dessus du SGBD qui représente les objets mobiles à partir des fonctionnalités existantes du SGBD (modèle de données et opérations associées) ; la seconde approche consiste à étendre les fonctionnalités existantes du SGBD en leur fournissant de nouvelles structures de données, des opérations pour la manipulation, le support des index et des algorithmes de jointure pour ces objets. C est cette dernière approche que nous avons utilisée dans le cadre de ce travail. 6.1 Contributions Suivant les objectifs que nous nous sommes fixés en début de ce travail, nous sommes partis d une analyse de la littérature scientifique en matière de modélisation et de gestion de données de trajectoires. Cette analyse nous a permis de retenir une approche de modélisation, que nous avons mise en oeuvre sous la forme d une extension pour le SGBD PostgreSQL. Dans une démarche pragmatique, nous avons proposé Lhermes, une infrastructure de stockage et d interrogation des données de trajectoires pour le SGBD PostgreSQL 9. Cette infrastructure implémente l approche de modélisation des objets mobiles utilisant des types abstraits de données. Concrètement, il a été question de développer pour PostgreSQL 9, une cartouche contenant de nouveaux types de données et un ensemble d opérations, pour stocker et interroger l évolution des objets mobiles. Nous nous sommes intéressés principalement aux objets mobiles dont seule la position au cours du temps 74

75 est pertinente pour les analyses. Mais notre extension permet une grande souplesse au niveau conceptuel qui fait que l on puisse facilement l étendre pour supporter les objets dont la forme évolue au cours du temps. Notre infrastructure a fait l objet d un proof of concept à travers l application d un cas pratique : le benchmark BerlinMOD. Les résultats de cette application montrent l effectivité de notre approche et nous permettent de baliser de nouveaux chemins d investigation afin de la rendre plus compétitive. 6.2 Perspectives Comme nous l avons souligné à la section précédente, la version actuelle de Lhermes ne supporte que des objets dont on s intéresse principalement à la position au cours du temps. La première voie d investigation serait d étendre cette infrastructure, afin qu elle puisse prendre en charge également, des objets dont la forme évolue dans le temps. La souplesse conceptuelle de notre approche devrait permettre d implémenter de telles structures. Par ailleurs, les résultats du test de performance mettent en exergue la nécessité de développer des méthodes d accès particulières pour le support des index spatiotemporels. En effet, dans l infrastructure actuelle, PostGIS, qui fournit les fonctionnalités purement spatiales implémente des méthodes d accès GiST. Pour la cartouche temporelle, Temporal PostgreSQL, nous avons développé des méthodes d accès similaires. Si ceci permet des gains de performance pour des requêtes purement spatiales ou purement temporelles, il en est un peu moins pour ce qui est des requêtes spatio-temporelles. Dès lors, la deuxième voie d investigation consistera à doter l extension d un support d index spatio-temporel à part entière. Cependant, cette dernière voie d investigation en cache une autre. Il s agit du problème de la représentation physique des unit moving type qui constituent les types de base pour tout objet mobile. L actuelle implémentation d Hermes resprésente ces types au niveau de la couche utilisateur (couche SQL). Pour pouvoir en développer des méthodes d accès, il est impératif que ces types aient, tout comme les types spatiaux ou temporels, une ancrage au plus bas niveau (couche langage C). Enfin, avec l avènement de SQL-2011 et ses nouvelles fonctionnalités temporelles ; particulièrement la prise en charge des colonnes de type PERIOD. On peut naturellement imaginer le remplacement du module temporel (TAU-TLL ou Temporal PostgreSQL) de l infrasctructure, par une implémentation native des concepts temporels qu offrirait PostgreSQL pour SQL-2011 (ce qui n est pas le cas pour le moment, la norme SQL- 2011 adoptée en Décembre 2011 n est pas encore supportée par PostgreSQL). Dès lors, une troisième voie d investigation, avec cette nouvelle architecture s ouvre pour Lhermes. Par ailleurs, TAU-TLL ou Temporal PostgreSQL, peuvent constituer des bases de travail pour l implémentation de la prise en charge de SQL-2011 dans PostgreSQL.

Annexe A Types de données de Lhermes Nous reprenons dans cette partie la déclaration SQL des différents types de données manipulées dans Lhermes. /*unit_function for a sliced representation of time varying point*/ CREATE TYPE lhermes.unit_function_point AS ( posi GEOMETRY,-- initial position (PostgIS POINT) pose GEOMETRY,-- end position posm GEOMETRY,-- (xm, ym) centre of circle (in case of cyclic motions) v NUMERIC,-- initial velocity (in case of accelerating) a NUMERIC,-- acceleration f NUMERIC,-- angle covered by the moving point (in case of cyclic motions) descr text -- mask describing the type of motion ); /*unit function for a sliced representation of time varying real*/ CREATE TYPE lhermes.unit_function_real AS ( vali double precision,-- initial value vale double precision,-- end value descr text -- mask describing the type of motion ); CREATE TYPE lhermes.unit_function_int AS ( v int, -- the value of the int tp timestamptz -- at the timestamp tp ); /*unit function for a sliced representation of time varying bool*/ CREATE TYPE lhermes.unit_function_bool AS ( v bool,-- the value of the bool tp timestamptz -- at the timestamp tp ); CREATE TYPE lhermes.unit_moving_point AS ( p period, -- Time period with granularity second where Unit function is valid m lhermes.unit_function_point -- Motion during period p 76

77 ); -- CREATE TYPE lhermes.unit_moving_real AS ( p period, -- Time period with granularity second where Unit_function is valid m lhermes.unit_function_real -- Motion during period p ); -- CREATE TYPE lhermes.unit_moving_int AS ( vali lhermes.unit_function_int,-- initial vale lhermes.unit_function_int,-- final int descr text -- mask describing the type of motion ); -- CREATE TYPE lhermes.unit_moving_bool AS ( vali lhermes.unit_function_bool,-- initial vale lhermes.unit_function_bool,-- final bool descr text -- mask describing the type of motion );

Annexe B Configuration de l environnement de développement La présente configuration est basée sur la distribution 9 de PostgreSQL et la version Express 2008 Microsoft Visual C++. Ces deux logiciels sont libres de droit et peuvent aisément être téléchargés sur les sites web de leur éditeur respectif (PostgreSQL et Microsoft respectivement). Pour des besoins de simplicité, nous supposerons que l utilisateur intéressé, a une expérience minimale de ces deux environnements. B.1 Configuration au niveau de visual C++ 1. Créer un projet de type application win32 et choisir DLL dans le menu paramètres de l application proposé par l assistant. 2. Dans les options du projet : Menu --> outils --> options --> projets et solutions --> répertoires de VC++ --> fichiers Include Inclure les chemins de fichiers suivants pour permettre une compilation avec les librairies PostgreSQL : PG_HOME/include PG_HOME/include/server PG_HOME/include/server/ports/win32 PG_HOME/include/server/ports/win32/msvc 3. A partir de la même page, sélectionner fichiers librairie dans la liste déroulante et inclure le répertoire : PG_HOME/lib où PG_HOME représente le répertoire d installation de PostgreSQL. 4. Spécifier le répertoire de sortie : C est le répertoire où sera stockée la DLL générée. Idéalement cette dernière sera stockée dans le répertoire de librairie de PostgreSQL PG_HOME/lib, pour permettre au serveur d y accéder à la demande. Mais on peut tout aussi bien la stocker dans un emplacement temporaire, le temps du développement de la DLL et la mettre au bon endroit le moment venu. 78

79 5. Une fois ces différentes configurations effectuées, on peut lancer un premier test de développement d une extension, pour celà PostgreSQL propose un exemple fort détaillé de développement d un type utilisateur Complex, pour la manipulation des nombres complexes. L exemple est en C standard pour des environnements UNIX et nécessite donc une adaptation en suivant les règles de 4.2.3. B.2 Configuration au niveau de PostgreSQL Au niveau de PostgreSQL, il n y a pas de configuration nécessaire, le fichier de librairie généré à partir de visual C++ est placé dans le répertoire lib de PostgreSQL, ensuite il ne reste plus qu à écrire les scripts PL/pgSQL qui utilisent les différentes fonctions de la librarie 4.2.3.

Bibliographie [1] Spatio-temporal databases : The chorochronos approach. In Manolis Koubarakis, Timos K. Sellis, Andrew U. Frank, Stéphane Grumbach, Ralf Hartmut Güting, Christian S. Jensen, Nikos A. Lorentzos, Yannis Manolopoulos, Enrico Nardelli, Barbara Pernici, Hans-Jörg Schek, Michel Scholl, Babis Theodoulidis, and Nectaria Tryfona, editors, Spatio-Temporal Databases : The CHOROCHRONOS Approach, volume 2520 of Lecture Notes in Computer Science. Springer, 2003. [2] ISO/TC 211. Standards guide iso/tc 211 geographic information/geomatics. Technical report, international Standards Organization, 2009. [3] ISO/IEC 9075-2 :2011. Information technology database languages sql part 2 : Foundation (sql/foundation). www.iso.org, 2011. [4] Natalia V. Andrienko, Gennady L. Andrienko, Nikos Pelekis, and Stefano Spaccapietra. Basic concepts of movement data. In Mobility, Data Mining and Privacy, pages 15 38. 2008. [5] Yvan Bédard, Suzie Larrivée, Marie-Josée Proulx, and Martin Nadeau. Modeling geospatial databases with plug-ins for visual languages : A pragmatic approach and the impacts of 16 years of research and experimentations on perceptory. In ER (Workshops), pages 17 30, 2004. [6] Roger Brunet. Les mots de la géographie. Reclus, 1997. [7] Suleman Bulahya. Représentation et interrogation de données spatio-temporelles : Cas d étude sur postgresql/postgis. Master s thesis, Université Libre de Bruxelles, 2009. [8] Hugh Darwen. Valid time and transaction time proposals : Language design aspects. Temporal Databases : Research and Practice, pages 195 210, 1998. [9] Jeff Davis and Selena Deckelmann. Temporal postgresql. http ://pgfoundry.org/projects/temporal/, 2009. [10] José Antônio Fernandes de Macêdo, Christelle Vangenot, Walied Othman, Nikos Pelekis, Elias Frentzos, Bart Kuijpers, Irene Ntoutsi, Stefano Spaccapietra, and Yannis Theodoridis. Trajectory data models. In Mobility, Data Mining and Privacy, pages 123 150. 2008. [11] C. Düntgen, T. Behr, and R.H. Güting. Berlinmod : a benchmark for moving object databases. the VLDB Journal, 18(6) :1335 1368, 2009. [12] Luca Forlizzi, Ralf Hartmut Güting, Enrico Nardelli, and Markus Schneider. A data model and data structures for moving objects databases. In SIGMOD Conference, pages 319 330, 2000. [13] Floris Geerts. Moving objects and their equations of motion. In CDB, pages 41 52, 2004. 80

81 [14] Open GIS. Consortium : OpenGIS simple features specification for SQL, revision1. 1. OpenGIS Project Document, pages 99 049, 1999. [15] The PostgreSQL Global Development Group. Guide du développeur PostgreSQL 9.0.1. 2010. [16] Ralf Hartmut Güting, Michael H. Böhlen, Martin Erwig, Christian S. Jensen, Nikos A. Lorentzos, Markus Schneider, and Michalis Vazirgiannis. A foundation for representing and querying moving objects. ACM Trans. Database Syst., 25(1) :1 42, 2000. [17] Ralf Hartmut Güting, Victor Teixeira de Almeida, Dirk Ansorge, Thomas Behr, Zhiming Ding, Thomas Höse, Frank Hoffmann, Markus Spiekermann, and Ulrich Telle. Secondo : An extensible dbms platform for research prototyping and teaching. In ICDE, pages 1115 1116, 2005. [18] Ralf Hartmut Güting and Markus Schneider. Moving Objects Databases. Morgan Kaufmann, 2005. [19] Torsten Hägerstrand. What about people in regional science? Papers in Regional Science, 24(1) :6 21, 1970. [20] Refractions Research Inc. PostGIS 1.5.3 Manual. 2011. [21] ISO/IEC. Information Technology - Databases Languages - SQL - Part 7 : Temporal(SQL/Foundation). ISO/IEC 9075-2 ISO Working Draft, 2001. [22] ISO/TC211. Geographic Information and Temporal Schema. ISO :19108 :2002, 2002. [23] ISO/TC211. Geographic Information and Spatial Schema. ISO :19107 :2003, 2003. [24] Zhang Jingxiong and F. Goodchild Michael. Uncertainty in geographical information. CRC, 2002. [25] Krishna Kulkarni. Temporal features in sql standard. IBM Presentation, 2011. [26] Suzie Larrivée, Yvan Bédard, and Jacynthe Pouliot. How to enrich the semantics of geospatial databases by properly expressing 3d objects in a conceptual model. In OTM Workshops, pages 999 1008, 2005. [27] Gervais Marc, Bédard Yvan, Jeansoulin Robert, and Cervelle Bernard. Gestion de l incertitude dans les bases de données géographiques : développement du modèle du producteur raisonnable. Revue Internationale de Géomatique, pages 1 X, 2005. [28] Pelekis Nikos and Theodoridis Yannis. An oracle data cartridge for moving objects. 2005. [29] OpenGeo. Introduction to PostGIS. http ://workshops.opengeo.org/postgisintro/introduction.html, Consulté le 13/05/2012. [30] Wolfson Ouri, Bo Xu, Chamberlains Sam, and Jiang Liqin. Moving objects databases : Issues and solutions. In Scientific and Statistical Database Management, 1998. Proceedings. Tenth International Conference on, pages 111 122. IEEE, 1998. [31] Christine Parent, Stefano Spaccapietra, and Esteban Zimányi. Conceptual modeling for traditional and spatio-temporal applications - the MADS approach. Springer, 2006. [32] Nikos Pelekis. STAU : A Spatio-Temporal Extension for the Oracle DBMS. PhD thesis, 2002.

82 [33] Nikos Pelekis, Yannis Theodoridis, Spyros Vosinakis, and Themis Panayiotopoulos. Hermes - a framework for location-based data management. Advances in Database Technology-EDBT 2006, pages 1130 1134, 2006. [34] A. Prasad Sistla, Wolfson Ouri, Chamberlain Sam, and Dao Son. Modeling and querying moving objects. In Data Engineering, 1997. Proceedings. 13th International Conference on, pages 422 432. IEEE, 1997. [35] Peter Z. Revesz. Introduction to Constraint Databases. Springer, 2002. [36] Richard T. Snodgrass. Tsql2 and sql3 interactions. http ://www.cs.arizona.edu/ rts/sql3.html, 2012. [37] Richard T. Snodgrass, Michael H. Böhlen, Christian S. Jensen, and Andreas Steiner. Adding transaction time to sql/temporal. ISO-ANSI SQL/Temporal Change Proposal, ANSI X3H2-96-152r ISO/IEC JTC1/SC21/WG3 DBL, 1101 :143, 1996. [38] Richard T. Snodgrass, Michael H. Böhlen, Christian S. Jensen, and Andreas Steiner. Adding valid time to sql/temporal. ANSI X3H2-96-501r2, ISO/IEC JTC, 1, 1996. [39] Richard T. Snodgrass, Michael H. Böhlen, Christian S. Jensen, and Andreas Steiner. Transitioning temporal support in tsql2 to sql3. In Temporal Databases, Dagstuhl, pages 150 194, 1997. [40] Stefano Spaccapietra, Christine Parent, Maria Luisa Damiani, José Antônio Fernandes de Macêdo, Fabio Porto, and Christelle Vangenot. A conceptual view on trajectories. Data Knowl. Eng., 65(1) :126 146, 2008. [41] V. Teixeira de Almeida, R. Hartmut Guting, and T. Behr. Querying moving objects in secondo. In Mobile Data Management, 2006. MDM 2006. 7th International Conference on, pages 47 47. IEEE, 2006. [42] Goce Trajcevski, Ouri Wolfson, Klaus Hinrichs, and Sam Chamberlain. Managing uncertainty in moving objects databases. ACM Trans. Database Syst., 29(3) :463 507, 2004. [43] Nectaria Tryfona, Rosanne Price, and Christian S. Jensen. Conceptual models for spatio-temporal applications. In Spatio-Temporal Databases : The CHOROCHRO- NOS Approach, pages 79 116, 2003. [44] Berkeley University of California. The gist indexing project. http ://gist.cs.berkeley.edu/, 1999. [45] Bedard Yvan. Visual modeling of spatial databases : Towards spatial pvl and uml. In Geomatica, pages 169 185, 1999. [46] Esteban Zimányi. Notes de cours Advanced Databases : Temporal Databases. Slides, 2011.