DÉVELOPPEMENT DES TECHNOLOGIES GÉOSPATIALES.

Transcription

1 Copie N o : DÉVELOPPEMENT DES TECHNOLOGIES GÉOSPATIALES. Livrable 1- Définition d une chaîne de production de données multidimensionnelles géospatiales Marie-Josée Proulx, M.Sc., professionnelle de recherche, Suzie Larrivée, B.Sc.A., professionnelle de recherche, Éveline Bernier, M.Sc., professionnelle de recherche, Yvan Bédard, PhD., professeur-chercheur Titulaire de la chaire de recherche industrielle CRSNG en bases de données Centre de recherche en géomatique, Université Laval, géodécisionnelles de l Université Laval. Chaire de recherche industrielle CRSNG en bases de données géodécisionnelles, Centre de recherche en géomatique, Université Laval

2 Table des matières 1. Mise en contexte Rappel des concepts multidimensionnels Chaîne de production de données multidimensionnelles géospatiales Chaîne de production de données Démarrage: L élaboration du système: Construction du système: Transition du système: Spécificités de la chaîne de production pour les données décisionnelles Analyse des fonctionnalités de logiciels d accès aux données Syntell 4i (Syntell): JMAP Spatial OLAP (Kheops-Technologies) OLAP Add-On for ArcGIS (ESRI) SAS 9.9- SAS Web OLAP Viewer for Java (SAS) Cognos 8 BI (Cognos) Proclarity Analyse du potentiel des solutions déjà utilisées par RDDC pour produire des données géospatiales Solutions logicielles d un grand intérêt pour l extraction, le traitement et le chargement des données dans une application SOLAP Trois outils d un grand intérêt pour l ETL Produits FME FME Spatialdirect - FME Web Services FME Data Servers FME Developer Tools Produits de Vivid Solutions JUMP Unified Mapping Platform... 31

3 JTS Topology Suite RoadMatcher JCS Conflation Suite GEOXYGENE Opérations ETL Sélection et extraction Nettoyage des données Intégration de données Intégration informatique Intégration sémantique Fusion multisource Intégration horizontale Intégration verticale Intégration géospatiale Passage de primitives à objet explicite Passage d attributs graphiques textuels à des attributs descriptifs Intégration temporelle Généralisation cartographique des données Raffinement Agrégation des données Reclassification Réduction de dimension Simplification des données Resymbolisation Caractérisation Exagération symbolique Déplacement Déformation Lissage Traitement des images Traitements des données 3D Autres opérations intéressantes Conclusion... 51

4 7. Nouveaux outils produits dans le cadre de la chaire de recherche industrielle en bases de données géospatiales décisionnelles Méthode et outils d analyse des besoins des utilisateurs Outils supportant l élaboration de systèmes Outils supportant la construction de systèmes Outils supportant la transition du système Intégration des différents outils dans la chaîne de production de données multidimensionnelles proposée Bilan de la situation organisationnelle: Exploration des données: Inventorier les données : Évaluer les besoins et produire une maquette : Conception du système : Modéliser les systèmes opérationnel et multidimensionnel : Définir les contraintes d intégrité Réalisation du système : Choix des plateformes et implantation de l architecture du système Développer le système Extraire, transformer et charger les données : Données descriptives : Données géospatiales : Tester la validité du processus ETL Conclusion Références Annexe A- Lecture suggérée Annexe B : Lecture suggérée Annexe C : Formats matriciels supportés par ArcGIS Annexe D : Formats de données supportés par GDAL Annexe E - Formats supportés par FME

5 Annexe F Formats supportés par Spatialdirect Annexe G Synthèse des opérateurs de généralisation cartographique présenté par Martel [1999]

6 Liste des figures Figure 1. Chaîne de production de données introduites dans les phases de développement de la méthode UP Figure 2. Application CITS-Gestion d inventaire cartographique Figure 3. Application SOLAP-Sport Figure 4. OLAP Add-ON for ArcGIS (ESRI) Figure 5. SAS 9.9- SAS Web OLAP Viewer for Java Figure 6. Cognos 8 BI Figure 7. Proclarity Figure 8 : Architecture de la plate-forme GeOxygene avec des exemples de composantes logiciels. [Extrait de Badard, 2005] Figure 9. Exemple de l utilisation des opérateurs d extraction et sélection de FME Figure 10. Exemple en (a) de découverts et (b) de chevauchement. Extrait de JCS Conflation Suite User Guide Figure 11. Déplacement latéral entre deux jeux de données de type polygone. Extrait de JCS Conflation Suite User Guide Figure 12. Différence entre l opérateur Aggregator et Dissolver de FME Figure 13. Exemple de classification de la dimension «marges de recul» dans un SOLAP..45 Figure 14. Classification d un attribut discret avec FME. L opérateur ValueMapper classifie le nombre d étages en 3 catégories, soit 1 à 3, 4 à 6 et 7 à 9 étages Figure 15. Classification d un attribut continu avec FME. Les opérateurs ExpressionEvaluator, AttributeFilter et AttributeCreator sont utilisés pour créer les classes d étages 30 et moins, 30 à 70 et 70 et plus Figure 16. Distinction entre les opérateurs CenterOfGravityReplacer, CenterLineReplacer, CenterPointReplacer Figure 17. Exemple de resymbolisation. À gauche, représentation simplifiée (l ensemble des objets ont le même symbole) et à droite représentation plus détaillée (symboles différents selon le type de bâtiment)... 48

7 Figure 18. Outils pouvant être utilisés dans la chaîne de production des données aux étapes d exploration des données Figure 19. Outils pouvant être utilisés dans la chaîne de production des données aux étapes de conception de système Figure 20. Différentes architectures OLAP possibles pour la réalisation du système Figure 21. Outils pouvant être utilisés dans la chaîne de production des données à l étape d implantation de la structure multidimensionnelle Figure 22. Outils pouvant être utilisés dans la chaîne de production des données à l étape d extraction, de transformation et d intégration Figure 23. Outils pouvant être utilisés dans la chaîne de production des données à l étape des tests de validation... 72

8 Liste des tableaux Tableau 1. Syntell 4i (Syntell) Tableau 2. JMAP Spatial OLAP (Kheops-Technologies) Tableau 3. OLAP Add-ON for ArcGIS (ESRI) Tableau 4. SAS 9.9- SAS Web OLAP Viewer for Java Tableau 5. Cognos 8 BI (Cognos) Tableau 6. Proclarity Tableau 7. Tableau synthèse des outils clients Tableau 8. Domaines d application des types d opérateurs de généralisation. Extrait de Martel [1997] Tableau 9. Synthèse de la planification de développement des outils... 57

9 1. Mise en contexte «Partout dans le monde, de nombreuses organisations dépensent des sommes colossales en acquisition de données localisées sur le territoire. La production cartographique, l'établissement de relations avec les bases de données internes à l organisation et l'analyse spatiale de ces données relèvent du domaine de la géomatique qui représente un marché annuel de plusieurs dizaines de milliards de dollars. Cependant, les données ainsi produites sont surtout de nature opérationnelle et par conséquent difficiles à exploiter à des fins décisionnelles, fins qui demandent des informations multisources, agrégées, des comparaisons dans l'espace et le temps, des synthèses, des mesures de tendances, des réponses rapides à des requêtes imprévues, etc. D'importants efforts sont déployés depuis une quinzaine d'années pour mettre en place des systèmes d'aide à la décision géospatiale, mais ces systèmes reposent sur les systèmes d'information géographique (SIG) et les approches transactionnelles habituelles (OLTP) pour produire l'information géodécisionnelle, souvent avec des délais inacceptables, voire des coûts prohibitifs au point d'en laisser tomber la production. Cette situation nuit à la prise de décision tactique/stratégique (ex. déploiement des ressources, de nouvelles infrastructures) et devient particulièrement problématique en situation d'urgence où tout retard peut avoir des impacts majeurs. Cette difficulté de produire l'information géospatiale décisionnelle provient de cinq problèmes : (1) des méthodes inadéquates de conception de bases de données géospatiales à fins décisionnelles, (2) la difficulté d'agréger et synthétiser des données cartographiques hétérogènes, (3) la difficulté d'évaluer la qualité de l'information géospatiale agrégée, (4) une sous-exploitation des technologies de l'information et des communications, et (5) un manque de technologies décisionnelles géospatiales efficaces». (Bédard,Y., M.J. Proulx & S. Rivest, 2005) La présente étude vise à identifier les besoins spécifiques pour la mise en place d un système multidimensionnel qui s introduit dans une démarche d envergure d entrepôt de données ou de petits comptoirs de données. Indépendamment de l orientation prise, plusieurs technologies entrent en liste lorsque vient le temps de préparer les données multidimensionnelles à partir de plusieurs sources. De plus, le processus de production de ces données est directement influencé par la richesse des fonctions analytiques désirées. Par conséquent, cette étude vise à proposer une chaîne de production utilisant différents outils et méthodes afin de réaliser un système multidimensionnel. Les aspects suivants seront abordés. D abord un rappel des concepts multidimensionnels est nécessaire pour permettre au lecteur de comprendre la suite du document (cf. section 2). La définition en temps que telle d une chaîne de production des données multidimensionnelles sera introduite (cf. section 3). L analyse de différentes architecture de données multidimensionnelles sera présenter et des solutions commerciales présentées (cf. section 4). Ensuite, l analyse des solutions déjà utilisées par RDDC pour produire des données géospatiales seront évaluation pour la production de données multidimensionnelles (cf. section 5). De nouvelles solutions pouvant être d un grand intérêt pour RDDC seront aussi proposées (cf. section 6).

10 Ensuite, la présentation des outils logiciels planifiés dans le programme de R&D de la chaire de recherche pouvant être d intérêt pour RDDC seront présenter afin de les intégrer lorsque souhaitable dans la chaîne de production (cf. section 7). Finalement, l intégration de tous les outils discutés précédemment sera faite à l intérieur de la chaîne de production (cf. section 8). Nous couvrirons l ensemble du processus, depuis la conception jusqu à la l exploitation et l analyse des données multidimensionnelles, en passant par l extraction, la transformation, le chargement des données et la gestion des données multidimensionnelles spatiales. Cette chaîne de production s arrimera ainsi avec les technologies utilisées au RDDC.

11 2. Rappel des concepts multidimensionnels. Les concepts multidimensionnels s orientent autour de deux aspects fondamentaux: les cube de données ainsi que les technologies d analyse en ligne (ou OLAP) et leur architecture. L approche des bases de données multidimensionnelles introduit des concepts qui diffèrent des concepts reliés aux bases de données communément utilisées qui sont qualifiées de transactionnelles. La technologie d analyse en ligne permet la visualisation cartographique des données, la navigation cartographique dans la carte elle-même ou dans les symboles affichés sur cette carte et ceci selon différents types de forage. La lecture des références suivante qui se trouve en annexe au présent rapport est recommandée. Révision des concepts multidimensionnels et aperçu des applications possibles. Bédard Y., M.J. Proulx & S. Rivest, 2005, Enrichissement du OLAP pour l'analyse géographique : exemples de réalisation et différentes possibilités technologiques, Revue des Nouvelles Technologies de l'information - Entrepôts de données et l'analyse en ligne, sous la direction de F. Bentayeb, O. Boussaïd, J. Darmont et S. Loudcher, Cépaduès-Éditions, France, pp

12 3. Chaîne de production de données multidimensionnelles géospatiales 3.1. Chaîne de production de données. Afin de produire efficacement des données décisionnelles, il est primordial d avoir en tête une chaîne de production permettant d illustrer les étapes clés dans la production de données en général. La chaîne de production présentée dans cet ouvrage est basée sur la méthode de développement UP (Unified Process). Cette méthode est une vision itérative et incrémentale de développement de système où chaque phase est définie partiellement a priori puis raffinée durant sa réalisation. Il existe quatre phases de développement de système selon la méthode UP. Le démarrage : Cette phase consiste en une étude de faisabilité ou une enquête minimale afin de supporter la décision de continuer ou d arrêter le développement. L élaboration : Cette phase consiste l identification de la majorité des besoins et de la portée du système, on procède à l implantation du cœur de l architecture de façon itérative et où les risques élevés sont atténués. La construction : Cette phase consiste en l implantation itérative des éléments les plus simples et les moins risqués. Elle vise à compléter le développement (incluant la documentation et le manuel à l usager) et à préparer les tests et le déploiement. Transition : Tests, déploiement, formation, migration de l ancien vers le nouveau système et mise en opération. Il est alors possible de positionner les étapes de la chaîne de production de données en regard à ces différentes phases de développement. D abord un premier groupe d étapes a pour objectif de dresser le bilan organisationnel, autrement dit identifier les ressources pour le projet. Le second groupe a pour objectif d explorer les données existantes et d analyser les besoins. Troisièmement, la conception du système focus sur les étapes de conception et de modélisation du système et des processus. Finalement, la réalisation en soi du système inclut les étapes clés telles que l implantation, l extraction et la transformation des données. Cette chaîne de production de données est illustrée dans la figure suivante en regard aux phases de développement de système selon la méthode UP.

13 Figure 1. Chaîne de production de données introduites dans les phases de développement de la méthode UP. Dans la section et suivantes, chaque étapes de la chaîne de production est discutée Démarrage: Les premières observations à faire lors du développement d une application géospatiale décisionnelle est d analyser la situation organisationnelle en

14 termes de ressources disponibles et de contraintes matérielles. L application souhaitée doit s arrimer aux systèmes déjà en place, mais elle doit aussi cadrer avec les contraintes et recommandations organisationnelle en termes d architecture et de logiciel. Il est primordial de déterminer au départ les ressources humaines disponibles dans l organisation, soit l expertise technique et les types d usagers ciblés pour l application. Les ressources matérielles en place permettent de savoir sur quelle architecture (systèmes opérationnels, entrepôt de données, marchés de données, systèmes décisionnels, applications maison) et systèmes en place (SGBD, GIS, ETL, etc.) il faudra s arrimer. L étude du contrôle de sécurité et de la confidentialité des données doit aussi être faite. À cette étape, peu de choses sont directement liées au développement à proprement dit et à la production des données géospatiales décisionnelles, mis à part, si une architecture d entrepôt de données décisionnel existe déjà sur place, on pourrait tenir compte des plateformes utilisées pour identifier des formats de données à produire L élaboration du système: Au tout début de la chaîne de production de données, il est essentiel de procéder à l analyse des besoins des utilisateurs. De plus, il est souhaitable de refaire cette étape dans le cadre d une mise à jour du système afin d en assurer l évolutivité. Cette analyse peut être réalisée à l aide d'observations, interviews, questionnaires et revues de documentation ou encore par maquettage et prototypage. Diverses études ont démontré qu il est difficile pour la clientèle d exprimer ses besoins pour les applications géomatiques. Ce constat est d autant plus vrai lorsqu il s agit d applications multidimensionnelles. La nouveauté du potentiel géodécisionnel, sa dimension analytique et exploratoire ainsi que sa convivialité soulèvent souvent des attentes nouvelles, évolutives et hétérogènes à l intérieur même d un projet. Il devient alors avantageux d utiliser des exemples visuels et concrets à l aide de prototype et de maquette. Cette pratique est réputée la plus efficace pour découvrir les besoins des utilisateurs lors du développement de systèmes décisionnels. Parmi les étapes clés de l exploration des besoins, notons, l inventaire préliminaire des sources de données utilisées actuellement (formulaires, graphiques, cartes, atlas) qui permettent de comprendre la thématique d analyse des usagers. Un inventaire détaillé des sources existantes autant descriptives que géospatiales permettra d identifier les sources externes à l organisation nécessaire pour construire l application. Cette étude est essentielle afin d évaluer si les usagers utilisent déjà des données décisionnelles ou non. Dans l affirmative, les usagers seront en mesure d exprimer assez clairement leur attentes. Dans la négative, l objectif de

15 l exploration des besoins est de concrétiser des besoins décisionnels à partir des données actuelles utilisées par les usagers. Ces besoins sont souvent présentés par l équipe de développement puisque les usagers ont peu ou pas de connaissance en analyses décisionnelles. Par conséquent, il est nécessaire de définir des analyses multidimensionnelles types en proposant des analyses de nature spatiale et de nature multidimensionnelle. Par cette première étude, l équipe de développement sera en mesure de définir les indicateurs d analyse, les classifications, les thématiques et les vues appropriées pour les données. Généralement, une maquette (ou une liste) illustrant les besoins des utilisateurs est produite afin de valider une dernière fois la compréhension de l équipe de développement. La maquette permet très souvent aux usagers d exprimer de nouveaux besoins par la visualisation concrète de leur application potentielle. Plus loin lors de l élaboration du système, la modélisation est essentielle à la mise en place des bases de données ainsi qu à la définition de l ontologie de l application (i.e. vocabulaire). Pour les données transactionnelles, il existe plusieurs formalismes bien établis dont le standard UML avec ou sans extensions pour les données géospatiales. Du côté décisionnel, il existe quelques propositions de formalismes non-spatiaux. Cependant, la modélisation formelle des opérations de transformation des données sources et d agrégation spatiales permettant la production de données agrégées, résumées à différents niveaux de granularité est encore inexistante dans ces formalismes. À partir des résultats de l inventaire précédent, il sera possible de concevoir l architecture du système. Il peut s agir d une architecture 1 tiers, 2 tiers avec entrepôt de données, 2 tiers sans entrepôts de données ou 3 tiers. La conception des modèles conceptuels et d implantation du système opérationnel peuvent être nécessaire, car pour certaines applications décisionnelles, il n y a pas de système opérationnel existant au préalable. La compréhension du système opérationnel permet ensuite la conception des modèles conceptuels et d implantation multidimensionnels (définition des mesures, des dimensions et des niveaux) Construction du système: La mise en place d une base de données géospatiales décisionnelles implique d abord l intégration de données provenant de différentes sources transactionnelles. Toute intégration de données nécessite une sélection a priori des sources à intégrer, souvent dans un contexte de redondance, d'hétérogénéité et d incompatibilité. Il s'agit d'un des principaux problèmes des bases de données géospatiales décisionnelles. Afin d assurer une information de qualité, il devient nécessaire d identifier les meilleures sources

16 de données en considérant leur nature et les efforts d'intégration requis pour une organisation. Les bases de données décisionnelles utilisent des données agrégées à différents niveaux afin de supporter les vues globales et locales désirées par l'utilisateur. L'agrégation des données non-spatiales est prise en charge par le serveur OLAP ou des outils statistiques. Cependant, les agrégations géospatiales doivent être effectuées à l aide d outils spécialisés. L étude des choix de fonctions de fusion, d agrégation, de synthèse et de développement d indicateurs font aussi partie de cette étape. Afin de peupler le cube de données de qualité, il faut implanter des contraintes d'intégrité lors de l'intégration et de l'agrégation des données sources. Il faut évaluer les contraintes techniques reliées aux systèmes actuels et à l organisation et choisir les logiciels pour l implantation de l application reposant sur l architecture proposée ou déjà en place. L évaluation et sélection des sources de données spatiales et descriptives est une étape qui permet de choisir efficacement les données à utiliser dans l application décisionnelle. Il faut toutefois prendre soin de définir les métadonnées de transformation des données sources dans le dictionnaire de données au fur et à mesure que les transformations seront effectuées afin de documenter adéquatement le futur système. Pour les même raisons, la définition des métadonnées relatives aux agrégations des données multidimensionnelles est tout aussi importante. Si nécessaire, le développement du système opérationnel consistera en l extraction des sources de données spatiales et descriptives, leur transformation et leur chargement dans le système opérationnel qui peut être implanté sous la forme d un entrepôt de données ou non. Le développement du système décisionnel (base de données multidimensionnelle) consiste tant qu à lui à l extraction des données du système opérationnel, leur transformation, agrégation et chargement des données dans la base de données multidimensionnelle. Par la suite, un choix sera fait sur l architecture retenue pour la structuration des données descriptives (Multidimensionnelle OLAP ou Relationnelle OLAP). Ensuite, la structuration des données spatiales (par généralisation cartographique ou représentation multi-échelle) pour chaque niveau cartographiable des dimensions spatiales sera requise Transition du système: Finalement, des tests sur la validité des résultats de transformation et d agrégation des données doivent être faits afin d assurer un système de qualité.

17 3.2. Spécificités de la chaîne de production pour les données décisionnelles Lorsque vient le temps de présenter une chaîne de production pour des données décisionnelles, il faut tenir compte des particularités de ce type de système. Premièrement, l étape d analyse des besoins se doit d être plus exhaustive que lors de la définition d un système transactionnel. Les besoins doivent cernés précisément puisque les données requises pour ces analyses doivent être précalculées et souvent stockées dans le système. Par conséquent, pour mieux définir les besoins des usagers, la création d une maquette est souhaitable. Le maquettage est une technique qui permet de surmonter des difficultés de spécification dues au manque de précision dans l'expression des besoins. Elle est un outil permettant de faciliter la communication entre l analyste et les utilisateurs. Cette activité consiste à développer rapidement une ébauche du futur système que les analystes utiliseront pour valider leur compréhension des besoins exprimés par les usagers. Le processus de maquettage est itératif. Différentes versions de la maquette peuvent être produites pour parvenir ultimement à l illustration complète et fidèle des besoins des usagers. Par conséquent, la définition d une maquette prend du temps et ces efforts doivent être considérés dans le plan de développement d une application décisionnelle si l on souhaite atteindre plus précisément les besoins des usagers. Deuxièmement, l étape de transformation des données est plus vaste. Selon la littérature, cette étape de production de données est plus couteuse en temps et en énergie que d autres étapes. «Data acquisition and preparation often accounts for over 70% of a typical data integration project, and results in project delays of two to three times the original estimate.» (Exeros, 2005). Très souvent les organisations possèdent peu de documentation sur les données qu elles possèdent et encore moins sur la compréhension des relations ou transformations que les données ont subies avec le temps. Trop souvent les experts qui comprenaient les données ont quittés l organisation ou ne sont pas disponibles pour participer au processus actuel d intégration. De plus, cette étape qui est très complexe à réaliser en soi doit se faire généralement d une manière manuelle. Peu d outils existent pour automatiser entièrement la chaîne de production de données non-spatiale, par conséquent, la chaîne de production de données spatiale en ressent les contrecoups. En plus d extraire et de transformer les données sources pour les rendre cohérentes et homogènes entres-elles, il faut produire des données à des niveaux agrégés. Ces données agrégées spatiales ou non sont le résultat de traitements qui doivent être préalablement modélisés et documentés. Leur création requiert généralement des processus de calculs complexes et produisent un volume de données important. Cependant, bien que des efforts supplémentaires soient requis au niveau de la définition des besoins et de l agrégation des données, les efforts totaux pour développer une application décisionnelle sont moindres que les efforts totaux requis pour le développement de l application transactionnelle sur laquelle est basé le système décisionnel.

18 4. Analyse des fonctionnalités de logiciels d accès aux données. L objectif de cette section est de détailler les fonctionnalités des logiciels d accès aux données multidimensionnelles du marché afin de permettre ultérieurement d analyser les besoins génériques de la production de données multidimensionnelles à partir de ces technologies. Cette section décrit, à partir d un article publié récemment (Bédard et al, ), trois familles de solutions technologiques pour le développement et l implantation d une application SOLAP, basées sur les technologies utilisées et les fonctionnalités disponibles. Ce regroupement en trois familles origine de la diversité des technologies pouvant être utilisées pour remplir les fonctions descriptives et cartographiques d une application SOLAP. Les fonctions du volet descriptif peuvent évidemment être supportées par un serveur OLAP conventionnel ou par un SGDB relationnel ou objetrelationnel avec structure en étoile, en flocon ou en constellation. Les avantages d'un serveur OLAP pour le volet descriptif incluent les fonctionnalités d agrégation de données et les capacités optimisées d accès aux données, ce qui augmente la rapidité d analyse pour les grands volumes de données. Les fonctions du volet cartographique peuvent, quant à elles, être supportées par un logiciel de visualisation cartographique, un logiciel de cartographie assistée par ordinateur (CAO) ou un SIG. Les trois familles de solutions basées sur les technologies et fonctionnalités disponibles sont : (1) les solutions OLAP dominant, (2) les solutions SIG dominant, et (3) les solutions intégrées ou hybrides qui font appel autant aux fonctions OLAP que SIG [LGS Group 2000]. Au sein de cette classification, c'est l outil dominant qui offre ou qui fait appel à certaines fonctionnalités minimales de l autre outil. Parfois, l'outil dominant fournit l unique interface graphique de l application SOLAP, parfois l'interface unique peut être développée avec un langage de programmation (ex. Java, VB, C++). Pour les deux premières familles, un groupe de fonctionnalités domine largement l'autre groupe et l'application est développée autour de l'outil dominant. Inversement, dans le cas de la solution intégrée, les fonctionnalités tant OLAP que SIG sont offertes à un niveau supérieur, l'interface graphique principale est unique et construite au-dessus des technologies sous-jacentes (i.e. OLAP et SIG) et l'application SOLAP est développée pour tirer profit de l'intégration des fonctions OLAP et SIG. Dans ce dernier cas, lorsque ces fonctionnalités et l'interface principale forment un produit logiciel autonome (ex. JMap Spatial OLAP Extension [KHEOPS 2005]), nous parlons d'une technologie SOLAP (similairement à la situation relative à la technologie SIG vs le couplage des technologies CAO et SGBD). Les trois familles de solutions répondent à des besoins différents. Dans le premier cas, le volet cartographique n'est qu'accessoire. Dans le deuxième cas, c'est le volet OLAP qui est 1 Pour plus de détails sur les types de solutions SIG domainant, OLAP dominant et intégrée, le lecteur est invité à lire l article (Bédard et al., 2005) présentée en annexe.

19 accessoire. Dans le dernier cas, les deux volets sont jugés importants et leur coordination ou synchronisation est une particularité clé de cette technologie. Les technologies étudiées dans cette section sont : Syntell 4i (Syntell), une solution classée dans la famille des OLAP dominants, mais qui est avant tout un environnement de développement d applications analytiques de tableaux de bord spatiaux. Un élément distinctif entre les applications standard OLAP et les tableaux de bord est que, le tableau de bord permet l accès à un éventail de données tant transactionnelles que multidimensionnelles (OLAP). Le tableau de bord peut ainsi faciliter l accès aux différents systèmes de l organisation par un accès unique, contrairement à une application SOLAP où l application permet typiquement l accès à des cubes multidimensionnels. De grandes distinctions existent aussi entre ces deux types de solutions au niveau de la navigation dans les données et de la conception de l application 2. JMAP Spatial OLAP (Kheops-Technologies), la solution intégrée de l Université Laval; OLAP Add-On for ArcGIS (ESRI), une solution plutôt limitée de SIG dominant; SAS 9.9- SAS Web OLAP Viewer for Java (SAS), une solution OLAP dominant dont les capacités de traitement statistiques sur les données sont très avancées. Cognos 8 BI (Cognos), une solution OLAP dominant très populaire dans le marché des OLAP; et Proclarity 9.0 (Proclarity), une solution OLAP dominant qui vient d être achetée récemment par le géant Microsoft. Ces technologies illustrent bien les architectures multidimensionnelles disponibles sur le marché tant Multidimensionnelle OLAP (MOLAP) que Relationnelle OLAP (ROLAP) 3. Les aspects étudiés seront axés sur les structures supportées par ces architectures ainsi que les formats descriptifs. De plus le volet cartographique sera analysé en regard aux engins de visualisation cartographiques et formats géométriques supportés. Un tableau synthèse résume les critères d analyse. 2 Pour plus d information sur les tableaux de bord, le lecteur est encouragé à lire le rapport de recherche (Proulx, Bernier & Bédard, 2006) sur les tableaux de bord et le SOLAP. 3 Afin de bien comprendre l évaluation des technologies, le lecteur est encouragé à lire la section suivante du rapport rédigée en 1997 pour le CRDV portant sur les architectures multidimensionnelles OLAP qui se trouve en annexe au présent rapport.

20 4.1. Syntell 4i (Syntell): http: // La technologie SYNTELL 4i est basée sur les règles d'affaires de l'entreprise. Ceci implique que l'application analytique en entier soit décrite à l'aide de règles d'affaires. Ce sont ces règles qui produiront l'application. La technologie Syntell 4i supporte une architecture MOLAP utilisant son propre serveur Syntell ou les serveurs OLAP populaires. Cette technologie permet aussi d interfacer des bases de données relationnelles pour effectuer du reporting, le tout encapsulé dans une application analytique (type tableau de bord). Il s agit d une technologie dont l une de ses composantes est l OLAP. Elle intègre aussi des visualisateurs cartographiques plus ou moins évolués selon les besoins de navigation exprimés par les usagers. Type de solution: OLAP Dominant Type d interface : Client html Figure 2. Application CITS-Gestion d inventaire cartographique. Architecture multidimensionnelle : HOLAP Engin OLAP supportés : Structure ROLAP supportées : Tableau 1. Syntell 4i (Syntell) Syntell 4i OLAP Server, SQL Server OLAP Services, Hyperion Essbase, IBM BD2 OLAP Services, SAP BW et tout OLE DB pour OLAP. Via modélisation étoile. Engin de visualisation cartographique supporté : Connecteur SIG-ESRI Formats de données géométriques ShapeFile supportés : Engin de visualisation cartographique supporté : JMAP 3.0 (Kheops-technologies) Formats de données géométriques supportés : Formats matriciels supportés : Autres formats : Oracle 10g Spatial, Shape (ESRI), MapInfo, AutoCad, MicroStation, Digital Exchange Format, Personal geodatabase et ArcSDE (ESRI) TIFF et GEOTIFF SVG (Scalable Vector Graphics, WMS (Open GIS consortium) Navigation dans les données spatiales : De minimale à avancée, selon la programmation faite dans l application analytique. Outils facilitant la mise en place du système : Suite Syntell 4i Outils de modélisation : Outils ETL : Rafraîchissement des données : Gestion des métadonnées : Repository Modeler SynLoader SynLoader Repository Syntell 4i et CatalogOLAP

21 4.2. JMAP Spatial OLAP (Kheops-Technologies) JMAP Spatial OLAP est la toute première technologie Web qui intègre complètement les dimensions géospatiales dans un environnement d'aide décisionnelle en intelligence d'affaires. Il offre une interface graphique intuitive permettant à des nontechniciens d'accéder très facilement à leurs données géospatiales pour les visualiser ou les analyser. Les interfaces utilisateur peuvent inclure plusieurs cartes thématiques, des diagrammes statistiques (diagrammes à barres, camemberts, etc.) et des tableaux affichés en fonction d'une symbologie définie pour les valeurs ou les membres de la classification. Figure 3. Application SOLAP-Sport 4 Type de solution : Solution intégrée Type d interface: Client Java Tableau 2. JMAP Spatial OLAP (Kheops-Technologies) Architecture multidimensionnelle : ROLAP sans serveur Engin OLAP supportés : Aucun Structure ROLAP supportées : Modèle en étoile, en flocon, en constellation et la structure parent-enfant. Toutes bases de données possédant une connexion Java Database Conection (JDBC). (ex. Oracle, Acces, SQL Server). Engin de visualisation cartographique supporté : JMAP 3.0 (Kheops-technologies) Formats de données géométriques supportés : Formats matriciels supportés : Autres formats : Navigation dans les données spatiales : Avancée Oracle 10g Spatial, Shape (ESRI), MID/MIF (MapInfo), DWG (AutoCad), DGN (MicroStation), DXF (Digital Exchange Format), Personal geodatabase et ArcSDE (ESRI) TIFF et GEOTIFF WMS (OGC) Outils facilitant la mise en place du système : Aucun Outils de modélisation : Outils ETL : Rafraîchissement des données : Gestion des métadonnées : 4 Centre recherche en bases de données géospatiales multidimensionnelles ( )

22 4.3. OLAP Add-On for ArcGIS (ESRI) L extension OLAP pour ArcGIS permet aux utilisateurs de serveur OLAP (ex. Microsoft SQL Server, SAS OLAP Server et SAP BW) de visualiser leurs données dans l environnement ArcGIS sous la forme d une vue en lecture seulement. L outil offre un utilitaire permettant d effectuer manuellement la connexion d une vue OLAP sauvegardée à une couche cartographique ArcGIS. Les vues OLAP doivent être connectées une à une dans ArcGIS et la navigation n est possible que sur les données OLAP descriptives. La navigation Spatiale OLAP n est pas supportée. Cette solution demeure par conséquent la solution la plus limitée présentée. Figure 4. OLAP Add-ON for ArcGIS (ESRI) 5. Tableau 3. OLAP Add-ON for ArcGIS (ESRI) Type de solution : SIG Dominant Type d interface: Client Desktop Architecture multidimensionnelle : MOLAP Engin OLAP supportés : Microsoft SQL Server, SAS OLAP Server et SAP BW Engin de visualisation cartographique supporté : ArcGIS Web Server 9.0 (ESRI) Formats de données géométriques DB2 with Spatial type,informix with Spatial type, SQL Server,Oracle with supportés : Spatial or Locator, Personal geodatabases (Microsoft Access) Formats matriciels supportés : Voir annexe C Navigation dans les données spatiales : Aucune Outils facilitant la mise en place du système : Aucun Outils de modélisation : Outils ETL : Rafraîchissement des données : Gestion des métadonnées : 5 tiré de ( )

23 4.4. SAS 9.9- SAS Web OLAP Viewer for Java (SAS) A map is one form of a graphical representation of data, in addition to bar charts, tile charts or line charts, that lets users explore data by drilling up and down hierarchies and slicing through data. Maps from ESRI s ArcGIS Server can be used to display SAS OLAP data just like other views of the data. SAS Web OLAP Viewer for Java can display OLAP data as color coding on top of ESRI maps within its standard feature set. Users can drill on map regions to visualize information from an OLAP data source in real time. SAS OLAP supports synchronized drill and display for map and table view. Users can drill on regions in the map visualizing information from an OLAP data source in real time, enabling a zoom down to the level of individual houses on a road. Figure 5. SAS 9.9- SAS Web OLAP Viewer for Java 6 Tableau 4. SAS 9.9- SAS Web OLAP Viewer for Java Type de solution: OLAP Dominant Type d interface: Client Java Architecture multidimensionnelle : MOLAP Engin OLAP supportés : Connection OLE DB pour: SAP BW, SAS Olap server, SQL server Structure ROLAP supportées : Aucune Engin de visualisation cartographique supporté : ArcGIS Web Server 9.0 (ESRI) Formats de données géométriques DB2 with Spatial type,informix with Spatial type, SQL Server,Oracle with supportés : Spatial or Locator, Personal geodatabases (Microsoft Access) Formats matriciels supportés : Voir annexe C Navigation dans les données spatiales : Avancée. Outils facilitant la mise en place du système : SAS Enterprise BI Outils de modélisation : Outils ETL : Rafraîchissement des données : Gestion des métadonnées : SAS Enterprise ETL Server SAS Enterprise BI Server SAS Information Map Studio (metadata) 6 tiré de ( )

24 4.5. Cognos 8 BI (Cognos) Analysis with Cognos 8 Business Intelligence (BI) is based on the industry s acknowledged best-selling OLAP and analysis software, Cognos PowerPlay. The new analysis capability with Cognos 8 BI expands this functionality to cover a complete range of data sources and to provide seamless movement among reports, queries, and analysis. Cognos 8 Business Intelligence offers reporting, query, and analysis; dashboards and scorecarding; event lifecycle management; and the unifying power of centralized metadata in one product, on a single, proven service oriented architecture. Cognos 8 BI delivers all of these capabilities through a 100 percent Web browser interface for all users. Type de solution: OLAP Dominant Type d interface : Client Web Architecture multidimensionnelle : HOLAP Figure 6. Cognos 8 BI 7 Tableau 5. Cognos 8 BI (Cognos) Engin OLAP supportés : PowerCubes PowerPlay, SSAS, BD2 OLAP, Essbase et serveur OLAP populaires SQL Server, Oracle, SAp BW, IBM, Sybase, ODBC. Structure ROLAP supportées : Modèle étoile et BD relationnelle forme normale. IBM DB2 Cube Views, Oracle Materialized Views, and Teradata. Engin de visualisation cartographique supporté : Plusieurs Visualizer 1.5 ou MapX (MapInfo) Formats de données géométriques supportés : Formats matriciels supportés : ARCGIS Server Formats de données géométriques supportés : Formats matriciels supportés : Format TAB (MapInfo) structuré dans un «geoset». Non Navigation dans les données spatiales : Minimale Outils facilitant la mise en place du système : Cognos 8i Suite DB2 with its Spatial type,informix with its Spatial type, SQL Server,Oracle,Oracle with Spatial or Locator,Personal geodatabases (Microsoft Access). Voir annexe C Outils de modélisation : Outils ETL : Rafraîchissement des données : Gestion des métadonnées : Cognos Transformer Cognos Integration Cognos Integration Cognos 8 BI Metadata 7 Tiré de ( )

25 4.6. Proclarity ProClarity, de la compagnie Knosys, est un logiciel client OLAP qui permet de manipuler des cubes de données créés à l aide d Analysis Services de Microsoft SQL Server. ProClarity permet de visualiser les données descriptives d un cube sous différentes formes graphiques telles que des tableaux ou d autres diagrammes. Récemment, cette compagnie a été achetée par Microsoft. Figure 7. Proclarity Tableau 6. Proclarity 2.0 Type de solution: OLAP Dominant Type d interface : Client desktop ou Web (version light du desktop) Architecture multidimensionnelle : MOLAP Engin OLAP supportés : Cube Analysis Services de Microsoft SQL Server exclusivement. Structure ROLAP supportées : Aucune Engin de visualisation cartographique supporté : KMapX (Proclarity) Le plugiciel KMapX, développé à l aide de MapX de la compagnie MapInfo, permet la visualisation, sous forme cartographique, des données géométriques associées à une dimension spatiale géométrique d un cube. Formats de données géométriques Format TAB (MapInfo) structuré dans un «geoset» utilisable par supportés : KMapX. Formats matriciels supportés : Aucun (car le logiciel utilise des «geosets» MapInfo. Aucun format matriciel actuellement supporté par MapInfo ne permet de relier des attributs aux pixels). Navigation dans les données spatiales : Avancée. Outils facilitant la mise en place du système : Aucun Outils de modélisation : Outils ETL : Rafraîchissement des données : Gestion des métadonnées : 8 Tirée de site Web Centre recherche en bases de données géospatiales multidimensionnelles ( )

26 Tableau 7. Tableau synthèse des outils clients Outils clients Syntell 4i JMAP Spatial OLAP OLAP Add-On for Kheops-Technologies ArcGIS (ESRI) Type de solution: OLAP dominant Solution intégrée SIG Dominant SAS 9.9- SAS Web Cognos 8 BI Proclarity 2.0 OLAP Viewer for Java OLAP Dominant OLAP Dominant OLAP Dominant Type d interface Client html Client Java Client Desktop Client Java Client Web Client desktop ou Web Architecture HOLAP ROLAP sans serveur MOLAP MOLAP HOLAP MOLAP multidimensionnelle : Engin OLAP supportés : Syntell 4i OLAP Server, SQL Server OLAP Services, Hyperion Essbase, IBM BD2 OLAP Services, SAP BW Toutes sources conformes à la norme OLE DB OLAP Aucun Microsoft SQL Server, SAS OLAP Server et SAP BW Connection OLE DB pour: SAP BW via readonly tables, SAS Olap server, MSQL server PowerCubes multidimensionnel PowerPlay, SSAS, BD2 OLAP, Essbase et serveur OLAP populaires SQL Server, Oracle, SAp BW, IBM, Sybase, ODBC. Cube Analysis Services de Microsoft SQL Server exclusivement. Structure ROLAP supportées : Engin de visualisation cartographique supporté : Navigabilité dans les données spatiales Via modélisation étoile. Connecteur SIG-ESRI JMAP 3.0 (Kheopstechnologies) (de minimale à avancée) Programmable dans l application analytique Modèle en étoile, en flocon, en constellation et la structure parent-enfant. Toutes bases de données (JDBC). (ex. Oracle, Access, SQL Server). JMAP 3.0 (Kheopstechnologies) Avancée Aucune Aucune Modèle étoile et BD relationnelle forme normale: IBM DB2 Cube Views, Oracle Materialized Views, and Teradata. ArcGIS Web Server 9.0 (ESRI) ArcGIS Web Server 9.0 (ESRI) Visualizer 1.5 (Cognos) MapX (MapInfo) ARCGIS Server Aucune Aucune Avancée Minimale Avancée Outils facilitant la mise en Suite Syntell 4i Aucune Aucune SAS Enterprise BI Cognos 8i Suite Aucune place du système : Outils de modélisation : Repository Modeler Cognos Transformer Outils ETL : SynLoader SAS Enterprise ETL Cognos Integration Server Rafraîchissement des SynLoader SAS Enterprise BI Server Cognos Integration données : Gestion des métadonnées : Repository Syntell 4i et CatalogOLAP SAS Information Map Studio (metadata) Cognos 8 BI Metadata KMapX (Proclarity)

27 5. Analyse du potentiel des solutions déjà utilisées par RDDC pour produire des données géospatiales. RDDC est un intégrateur de données important et il produit des données dans différents formats que ce soit civil ou militaire. Pour ces raisons, il utilise un éventail d outils pour la production de celles-ci. Cette section dressera donc partiellement la liste des outils utilisés par RDDC ainsi que les formats militaires utilisés afin de les inclure éventuellement dans la chaîne de production de données. Un premier produit utilisé par RDDC est la libraire Open Source Geospatial Data Abstraction (GDAL). Il s agit d un traducteur de fichiers matriciels. Cette librairie est utilisée entre autre par les applications telles que MapServer et GRASS. Les formats supportés par GDAL sont multiples et sont listés en annexe à ce rapport. Un sous-projet de la librairie appelé OGR Simple Feature Library est une librairie permettant de lire (et parfois d écrire) dans des formats vectoriels incluant ESRI Shapefiles, S-57, SDTS, PostGIS, Oracle Spatial, et Mapinfo mid/mif et TAB. RDDC utilise aussi l Open Geographic Data Store Interface (OGDI) pour accéder à des données géospatiales de différents formats d une manière neutre. OGDI est une API qui utilise des méthodes d'accès standardisées pour travailler en conjonction avec des progiciels GIS et des produits de données géospatiaux divers. OGDI utilise une architecture de client/serveur pour faciliter la diffusion de données géospatiales sur n'importe quel réseau TCP/IP et une approche driver-oriented pour faciliter l accès à différents formats de données vectoriels et matriciels géospatiaux. L organisation utilise évidemment des formats de données géospatiaux militaires, comme le Vector Map (VMap). Les jeux de données VMap utilisent "le format de produit vectoriel" (vpf) utilisé d'abord par l' US Defense Mapping Agency et plus tard par son successeur, le National Imagery and Mapping Agency (NIMA). Ce jeu de données représente un nombre énorme de fichiers organisés dans des bibliothèques selon différents niveaux de détails. VMap Level 0 Représente un niveau d information équivalent aux échelles 1:1 million- 1:2 millions des cartes papier. VMap Level 1 - Représente un niveau d information équivalent à l échelle 1:250,000 des cartes papier. VMap Level 2 - Représente un niveau d information équivalent aux échelles 1:50,000-1:100,000 des cartes papier. Du coté des données matricielles, le format Compressed ARC Digitized Raster Graphics (CADRG) est utilisé. Celui-ci est une représentation digitalisée de produits papier. Le CADRG est dérivé directement du format ADRG et de d autres sources après des traitements de compression et de filtrage. CADRG est produit à différentes

28 échelles, soient les cartes opérationnelles de navigation ARC1 1: , les cartes tactiques de pilotage ARC2 1: , les graphiques d opérations ARC5 1: et les cartes topographiques ARC6 1: et ARC7 1: Finalement, le format de modèle numérique d élévation Digital Terrain Elevation Data (DTED) de l armée américaine est utilisé. Ce format, développé par le National Imagery and Mapping Agency (NIMA), se définit comme une matrice uniforme de valeurs d élévation de terrain qui fournit des données quantitatives de base pour des systèmes et les applications qui exigent l'élévation du terrain, la pente, et-ou des informations sur l état superficielle de la surface du terrain. Aucune information sur les outils d inventaires de données, les outils modélisation de données, les systèmes de gestion de bases de données et les systèmes d information géographiques utilisés au RDDC n ont été transmis lors de ce projet. Après vérification, il semble plutôt qu une grande variété de ceux-ci soit en fait utilisée dans l organisation, ce qui fait en sorte que le choix définitif de ces outils sera à faire pour la production de données géospatiales décisionnelles.

29 6. Solutions logicielles d un grand intérêt pour l extraction, le traitement et le chargement des données dans une application SOLAP Les outils SOLAP sont reconnus pour leur grande facilité de composition des requêtes et leur rapidité d affichage des résultats. Cependant, pour avoir cette facilité et rapidité, il faut au préalable structurer et charger les données. Cette tâche peut être très longue à réaliser dépendamment de l effort d intégration nécessaire pour obtenir des données homogènes ainsi que de l efficacité des outils utilisés pour agréger et généraliser les données des différents niveaux des dimensions et pour calculer les mesures. Ces opérations d extraction, de structuration, de transformation et de chargement des données sont effectuées par des outils d alimentation ou ETL tools (Extract, Transform and Load). Ces outils se composent d un ensemble d opérations permettant d effectuer ces tâches décrites dans le présent rapport. Les outils ETL spatiaux ont vu le jour avec la disponibilité massive des données et ce dans tous les formats. Cette abondance des données engendre plusieurs problèmes d intégration des jeux de données entre eux soit au niveau informatique (format des données), géospatial (projection cartographique), sémantique (cohérence des attributs), temporelle, etc. Le rôle de ces outils est donc de rendre les données accessibles par les applications SIG et homogènes entre elles. Les SIG et les outils ETL sont donc des outils complémentaires. Les applications SOLAP de par leur nature où tout doit être calculé à l avance, requièrent beaucoup plus de traitements ETL que les applications SIG. Premièrement, tout comme dans les applications SIG, il est nécessaire de charger les données détaillées dans la base de données. À ce niveau, les traitements ETL à réaliser pour les deux types d applications sont les mêmes. Ils consistent principalement à extraire les données des jeux de données sources, à les nettoyer et à les intégrer. Les deux types d applications se distinguent au niveau des données agrégées car une application SOLAP a obligatoirement plusieurs niveaux d abstraction tandis que ce que n est pas toujours le cas pour une application SIG. Les opérations de généralisation sont alors grandement utilisées afin de générer les géométries pour les niveaux d abstraction plus élevés de même que pour les valeurs d attribut, généralisées par une moyenne par exemple. Cette section décrira premièrement, de façon générale, trois outils pouvant être utiles pour l ETL des données dans un cube multidimensionnel spatial. Par la suite, les principales fonctions de ces outils seront présentées selon des catégories d opérations d ETL spatiales utilisées pour le développement d une application SOLAP.