3. Chaîne de production de données

Transcription

Copie No :_________
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
2006-05-25
http://mdspatialdb.chair.scg.ulaval.ca/
Table des matières
1.
Mise en contexte............................................................................................................ 9
2.
Rappel des concepts multidimensionnels. ................................................................... 11
3.
Chaîne de production de données multidimensionnelles géospatiales ........................ 12
3.1.
3.2.
4.
Chaîne de production de données................................................................... 12
3.1.1.
Démarrage: ........................................................................................ 13
3.1.2.
L’élaboration du système: ................................................................. 14
3.1.3.
Construction du système: .................................................................. 15
3.1.4.
Transition du système:....................................................................... 16
Spécificités de la chaîne de production pour les données décisionnelles ....... 17
Analyse des fonctionnalités de logiciels d’accès aux données. ................................... 18
4.1.
Syntell 4i (Syntell):......................................................................................... 20
4.2.
JMAP Spatial OLAP (Kheops-Technologies)................................................ 21
4.3.
OLAP Add-On for ArcGIS (ESRI) ................................................................ 22
4.4.
SAS 9.9- SAS Web OLAP Viewer for Java (SAS)........................................ 23
4.5.
Cognos 8 BI (Cognos) .................................................................................... 24
4.6.
Proclarity 2.0 ................................................................................................. 25
5.
Analyse du potentiel des solutions déjà utilisées par RDDC pour produire des données
géospatiales.................................................................................................................. 27
6.
Solutions logicielles d’un grand intérêt pour l’extraction, le traitement et le
chargement des données dans une application SOLAP............................................... 29
6.1.
Trois outils d’un grand intérêt pour l’ETL ..................................................... 30
6.1.1.
6.1.2.
Produits FME .................................................................................... 30
6.1.1.1.
FME ............................................................................... 30
6.1.1.2.
Spatialdirect - FME Web Services................................. 31
6.1.1.3.
FME Data Servers.......................................................... 31
6.1.1.4.
FME Developer Tools ................................................... 31
Produits de Vivid Solutions............................................................... 31
6.1.2.1.
JUMP Unified Mapping Platform.................................. 31
6.1.3.
6.2.
6.1.2.2.
JTS Topology Suite ....................................................... 32
6.1.2.3.
RoadMatcher.................................................................. 32
6.1.2.4.
JCS Conflation Suite...................................................... 32
GEOXYGENE .................................................................................. 33
Opérations ETL .............................................................................................. 34
6.2.1.
Sélection et extraction ....................................................................... 34
6.2.2.
Nettoyage des données ...................................................................... 36
6.2.3.
Intégration de données....................................................................... 37
6.2.4.
Intégration informatique.................................................................... 38
6.2.5.
Intégration sémantique ...................................................................... 38
6.2.6.
Fusion multisource ............................................................................ 38
6.2.7.
Intégration horizontale ...................................................................... 39
6.2.8.
Intégration verticale........................................................................... 40
6.2.9.
Intégration géospatiale ...................................................................... 40
6.2.10. Passage de primitives à objet explicite. ............................................. 40
6.2.11. Passage d’attributs graphiques textuels à des attributs descriptifs. ... 40
6.2.12. Intégration temporelle ....................................................................... 41
6.2.13. Généralisation cartographique des données ...................................... 41
6.2.13.1.
Raffinement ................................................................... 42
6.2.13.2.
Agrégation des données ................................................. 43
6.2.13.3.
Reclassification.............................................................. 44
6.2.13.4.
Réduction de dimension................................................. 46
6.2.13.5.
Simplification des données ............................................ 47
6.2.13.6.
Resymbolisation............................................................. 48
6.2.13.7.
Caractérisation ............................................................... 48
6.2.13.8.
Exagération symbolique ................................................ 49
6.2.13.9.
Déplacement .................................................................. 49
6.2.13.10. Déformation ................................................................... 49
6.2.13.11. Lissage ........................................................................... 49
6.2.14. Traitement des images....................................................................... 50
6.2.15. Traitements des données 3D.............................................................. 50
6.2.16. Autres opérations intéressantes ......................................................... 50
6.3.
Conclusion...................................................................................................... 51
7.
8.
Nouveaux outils produits dans le cadre de la chaire de recherche industrielle en bases
de données géospatiales décisionnelles. ...................................................................... 53
7.1.
Méthode et outils d’analyse des besoins des utilisateurs................................ 53
7.2.
Outils supportant l’élaboration de systèmes................................................... 54
7.3.
Outils supportant la construction de systèmes................................................ 55
7.4.
Outils supportant la transition du système...................................................... 56
Intégration des différents outils dans la chaîne de production de données
multidimensionnelles proposée. .................................................................................. 58
8.1.
Bilan de la situation organisationnelle: .......................................................... 58
8.2.
Exploration des données:................................................................................ 58
8.3.
8.4.
8.2.1.
Inventorier les données :.................................................................... 58
8.2.2.
Évaluer les besoins et produire une maquette : ................................. 60
Conception du système :................................................................................. 62
8.3.1.
Modéliser les systèmes opérationnel et multidimensionnel : ............ 62
8.3.2.
Définir les contraintes d’intégrité...................................................... 63
Réalisation du système : ................................................................................. 64
8.4.1.
Choix des plateformes et implantation de l’architecture du système. 64
8.4.2.
Développer le système....................................................................... 66
8.4.3.
Extraire, transformer et charger les données : ................................... 68
8.4.4.
8.4.3.1.
Données descriptives : ................................................... 68
8.4.3.2.
Données géospatiales :................................................... 69
Tester la validité du processus ETL. ................................................. 72
9.
Conclusion................................................................................................................... 75
10.
Références ................................................................................................................... 76
Annexe A- Lecture suggérée 1. ................................................................................................ 78
Annexe B : Lecture suggérée 2................................................................................................ 96
Annexe C : Formats matriciels supportés par ArcGIS. .......................................................... 100
Annexe D : Formats de données supportés par GDAL. ......................................................... 103
Annexe E - Formats supportés par FME 2006 ....................................................................... 106
Annexe F – Formats supportés par Spatialdirect.................................................................... 114
Annexe G – Synthèse des opérateurs de généralisation cartographique présenté par Martel
[1999] ........................................................................................................................ 116
Liste des figures
Figure 1. Chaîne de production de données introduites dans les phases de développement de la
méthode UP. ...................................................................................................................... 13
Figure 2. Application CITS-Gestion d’inventaire cartographique. ................................... 20
Figure 3. Application SOLAP-Sport ........................................................................................ 21
Figure 4. OLAP Add-ON for ArcGIS (ESRI). ......................................................................... 22
Figure 5. SAS 9.9- SAS Web OLAP Viewer for Java ............................................................. 23
Figure 6. Cognos 8 BI .............................................................................................................. 24
Figure 7. Proclarity 2.0 ........................................................................................................... 25
Figure 8 : Architecture de la plate-forme GeOxygene avec des exemples de composantes
logiciels. [Extrait de Badard, 2005] .................................................................................. 33
Figure 9. Exemple de l’utilisation des opérateurs d’extraction et sélection de FME. .............. 35
Figure 10. Exemple en (a) de découverts et (b) de chevauchement. Extrait de JCS Conflation
Suite User Guide. .............................................................................................................. 36
Figure 11. Déplacement latéral entre deux jeux de données de type polygone. Extrait de JCS
Conflation Suite User Guide. ............................................................................................ 40
Figure 12. Différence entre l’opérateur Aggregator et Dissolver de FME............................... 44
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.................................. 45
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............................................................ 46
Figure 16. Distinction entre les opérateurs CenterOfGravityReplacer, CenterLineReplacer ,
CenterPointReplacer.......................................................................................................... 47
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
Figure 18. Outils pouvant être utilisés dans la chaîne de production des données aux étapes
d’exploration des données................................................................................................. 61
Figure 19. Outils pouvant être utilisés dans la chaîne de production des données aux étapes de
conception de système....................................................................................................... 64
Figure 20. Différentes architectures OLAP possibles pour la réalisation du système.............. 66
Figure 21. Outils pouvant être utilisés dans la chaîne de production des données à l’étape
d’implantation de la structure multidimensionnelle. ......................................................... 68
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................................................................ 71
Figure 23. Outils pouvant être utilisés dans la chaîne de production des données à l’étape des
tests de validation. ............................................................................................................. 72
Liste des tableaux
Tableau 1. Syntell 4i (Syntell).................................................................................................. 20
Tableau 2. JMAP Spatial OLAP (Kheops-Technologies) ....................................................... 21
Tableau 3. OLAP Add-ON for ArcGIS (ESRI)....................................................................... 22
Tableau 4. SAS 9.9- SAS Web OLAP Viewer for Java .......................................................... 23
Tableau 5. Cognos 8 BI (Cognos) ............................................................................................ 24
Tableau 6. Proclarity 2.0......................................................................................................... 25
Tableau 7. Tableau synthèse des outils clients ......................................................................... 26
Tableau 8. Domaines d’application des types d’opérateurs de généralisation. Extrait de Martel
[1997]. ............................................................................................................................... 42
Tableau 9. Synthèse de la planification de développement des outils..................................... 57
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).
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.
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. 1-20.
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.
Figure 1. Chaîne de production de données introduites dans les phases
de développement de la méthode UP.
Dans la section 3.1.1 et suivantes, chaque étapes de la chaîne de production est discutée.
3.1.1.
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
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.
3.1.2.
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
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).
3.1.3.
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
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.
3.1.4.
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é.
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.
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, 20051), 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.
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’application2.
•
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.
4.1. Syntell 4i (Syntell):
http: //www.syntell.com
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.
Figure 2. Application CITS-Gestion d’inventaire cartographique.
Tableau 1. Syntell 4i (Syntell)
Type de solution: OLAP Dominant
Type d’interface : Client html
Architecture multidimensionnelle : HOLAP
Engin OLAP supportés :
Syntell 4i OLAP Server, SQL Server OLAP Services, Hyperion Essbase,
IBM BD2 OLAP Services, SAP BW et tout OLE DB pour OLAP.
Structure ROLAP supportées :
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)
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
4.2. JMAP Spatial OLAP (Kheops-Technologies)
http://www.kheops-tech.com/en/jmap/solap.jsp
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-Sport4
Tableau 2. JMAP Spatial OLAP (Kheops-Technologies)
Type de solution : Solution intégrée
Type d’interface: Client Java
Architecture multidimensionnelle : ROLAP sans serveur
Aucun
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)
supportés :
Autres formats :
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)
Navigation dans les données spatiales : Avancée
Outils facilitant la mise en place du système : Aucun
Outils ETL :
4
Centre recherche en bases de données géospatiales multidimensionnelles (31-01-2006.)
4.3. OLAP Add-On for ArcGIS (ESRI)
http://www.esri.com/software/arcgis/extensions/olap/about/overview.html
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
Microsoft SQL Server, SAS OLAP Server et SAP BW
Engin de visualisation cartographique supporté : ArcGIS Web Server 9.0 (ESRI)
supportés :
DB2 with Spatial type,Informix with Spatial type, SQL Server ,Oracle with
Spatial or Locator, Personal geodatabases (Microsoft Access)
Voir annexe C
Navigation dans les données spatiales : Aucune
Outils ETL :
5
tiré de http://www.esri.com/software/arcgis/extensions/olap/about/overview.html (31-01-2006)
4.4. SAS 9.9- SAS Web OLAP Viewer for Java (SAS)
http://www.sas.com/technologies/bi/query_reporting/webolapviewer/factsheet.pdf
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 Java6
Tableau 4. SAS 9.9- SAS Web OLAP Viewer for Java
Type d’interface: Client Java
Connection OLE DB pour: SAP BW, SAS Olap server , SQL server
Aucune
Engin de visualisation cartographique supporté : ArcGIS Web Server 9.0 (ESRI)
supportés :
DB2 with Spatial type,Informix with Spatial type, SQL Server ,Oracle with
Spatial or Locator, Personal geodatabases (Microsoft Access)
Voir annexe C
Navigation dans les données spatiales : Avancée.
Outils facilitant la mise en place du système : SAS Enterprise BI
Outils ETL :
SAS Enterprise ETL Server
SAS Enterprise BI Server
SAS Information Map Studio (metadata)
6
tiré de http://www.sas.com/technologies/bi/query_reporting/webolapviewer/factsheet.pdf (31-01-2006)
4.5. Cognos 8 BI (Cognos)
http://www.cognos.com/pdfs/factsheets/fs_c8bi_analysis.pdf
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.
Figure 6. Cognos 8 BI 7
Tableau 5. Cognos 8 BI (Cognos)
Type d’interface : Client Web
Architecture multidimensionnelle : HOLAP
PowerCubes PowerPlay, SSAS, BD2 OLAP, Essbase et serveur OLAP
populaires SQL Server, Oracle, SAp BW, IBM, Sybase, ODBC.
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)
supportés :
Non
ARCGIS Server
supportés :
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
Format TAB (MapInfo) structuré dans un « geoset ».
Navigation dans les données spatiales : Minimale
Outils facilitant la mise en place du système : Cognos 8i Suite
Outils ETL :
7
Cognos Transformer
Cognos Integration
Cognos Integration
Cognos 8 BI Metadata
Tiré de http://www.cognos.com/c8demo/content/launcher.html (31-01-2006)
4.6. Proclarity 2.0
http://www.proclarity.com/products/
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 2.0 8
Tableau 6. Proclarity 2.0
Type d’interface : Client desktop ou Web (version light du desktop)
Cube Analysis Services de Microsoft SQL Server exclusivement.
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.
Format TAB (MapInfo) structuré dans un « geoset » utilisable par
supportés :
KMapX.
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 ETL :
8
Tirée de site Web Centre recherche en bases de données géospatiales multidimensionnelles (31-01-2006)
Tableau 7. Tableau synthèse des outils clients
Outils clients
Syntell 4i
OLAP Add-On for
ArcGIS (ESRI)
SIG Dominant
SAS 9.9- SAS Web
OLAP Viewer for Java
OLAP Dominant
Cognos 8 BI
Proclarity 2.0
OLAP dominant
JMAP Spatial OLAP
Kheops-Technologies
Solution intégrée
Type de solution:
OLAP Dominant
OLAP Dominant
Type d’interface
Client html
Client Java
Client Desktop
Client Java
Client Web
Architecture
multidimensionnelle :
HOLAP
ROLAP sans serveur
MOLAP
MOLAP
HOLAP
Client desktop ou
Web
MOLAP
Syntell 4i OLAP Server,
SQL Server OLAP
Services, Hyperion
Essbase, IBM BD2 OLAP
Services, SAP BW
Toutes sources conformes
à la norme OLE DB OLAP
Via modélisation étoile.
Aucun
Microsoft SQL Server,
SAS OLAP Server et
SAP BW
Connection OLE DB
pour: SAP BW via readonly tables, SAS Olap
server , MSQL server
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)
Aucune
Aucune
ArcGIS Web Server 9.0
(ESRI)
ArcGIS Web Server 9.0
(ESRI)
Avancée
Aucune
Avancée
PowerCubes™
multidimensionnel
PowerPlay, SSAS, BD2
OLAP, Essbase et serveur
OLAP populaires SQL
Server, Oracle, SAp BW,
IBM, Sybase, ODBC.
Modèle étoile et BD
relationnelle forme
normale: IBM DB2 Cube
Views, Oracle
Materialized Views, and
Teradata.
Visualizer 1.5 (Cognos)
MapX (MapInfo)
ARCGIS Server
Minimale
Aucune
Aucune
SAS Enterprise BI
Cognos 8i Suite
Structure ROLAP
supportées :
Engin de visualisation
cartographique supporté :
Navigabilité dans les
données spatiales
Outils facilitant la mise en
place du système :
Outils ETL :
Rafraîchissement des
données :
Connecteur SIG-ESRI
JMAP 3.0 (Kheopstechnologies)
(de minimale à avancée)
Programmable dans
l’application analytique
Suite Syntell 4i
Repository Modeler
SynLoader
SynLoader
SAS Enterprise ETL
Server
SAS Enterprise BI Server
Repository Syntell 4i et
CatalogOLAP
SAS Information Map
Studio (metadata)
Cognos Transformer
Cognos Integration
Cognos Integration
Cognos 8 BI Metadata
Cube Analysis
Services de Microsoft
SQL Server
exclusivement.
Aucune
KMapX (Proclarity)
Avancée
Aucune
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
échelles, soient les cartes opérationnelles de navigation ARC1 1:1 000 000, les cartes
tactiques de pilotage ARC2 1: 500 000, les graphiques d’opérations ARC5 1:250 000
et les cartes topographiques ARC6 1:100 000 et ARC7 1:50 000.
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.
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.
6.1. Trois outils d’un grand intérêt pour l’ETL
Les outils ETL ou outils d’alimentation sont définis par l’Office de la langue française
comme étant un: “outil informatique qui est destiné à extraire des données de diverses
sources (bases de données de production, fichiers, Internet, etc.), de les transformer et
de les charger dans un entrepôt de données. » [OLF, 2000]. Cette définition est
précisée par cette note : « Tous les auteurs ne découpent pas cette phase du processus
de construction et d'entretien d'un entrepôt de données de la même manière, car les
outils qui existent, sur le marché, ne possèdent pas tous les mêmes fonctionnalités.
Toutefois, on peut dire que l'alimentation d'un entrepôt de données renferme, grosso
modo, les étapes suivantes : l'acquisition ou collecte des données (qui implique leur
sélection et leur extraction des diverses sources), leur transformation (qui implique
leur nettoyage, leur intégration et parfois leur agrégation) et enfin leur chargement ou
leur migration. » [OLF, 2000].
Cette section décrira les produits FME de la compagnie Safe Software, les produits
Open-source de la compagnie Vivid Solutions et la plate-forme logicielle GeOxygene.
6.1.1.
Produits FME
Les produits FME sont développés par la compagnie Canadienne Safe
Software, fondée en 1993 en Colombie-Britannique. Cette compagnie a
développé quatre logiciels, soit : FME, FME Web Services (Spatialdirect),
FME Data servers et FME Developer Tools, que nous présenterons dans les
paragraphes qui suivent.
6.1.1.1.
FME
FME (Feature Manipulation Engine) est une collection intégrée d’outils ETL
spatiaux nommés transformers, utilisée pour la transformation et la
translation des données. Il permet:
•
•
•
•
de combiner plusieurs sources de données en une seule opération de
translation;
de joindre des données de systèmes différents;
de transformer des données d’un format à un autre;
d’effectuer des tests permettant d’assurer la qualité des données
spatiales.
Le logiciel FME comprend trois composantes:
Workbench: permet d’effectuer des traitements ETL très sophistiqués.
Universal Viewer: permet une vue rapide des données pouvant être dans l’un
des nombreux formats de données supportés par FME.
Universal Translator: permet le transfert rapide de système de coordonnées et
de format de données (150 différents) d’un jeu de données.
6.1.1.2.
Spatialdirect - FME Web Services
Ce produit permet d’effectuer le transfert de système de coordonnées et de
format de données (54 différents) via une application Web. Celui-ci peut-être
utilisé via une interface HTML ou sous forme de plugiciel (plug-in) offrant
ainsi aux serveurs Web de données spatiales du marché, la possibilité de
distribuer leurs données sous différents formats et systèmes de coordonnées.
6.1.1.3.
FME Data Servers
Ce produit fournit aux applications OLE DB client un accès direct à plus de
100 formats de données. Il existe présentement une solution pour les logiciels
MapGuide d’Autodesk et GeoMedia WebMap d’Intergraph. Ce produit offre
la possibilité de publier les données client en format natif sans avoir besoin de
les convertir. Les transferts de format et projection sont effectués à la volée
afin d’afficher de manière intégrée, des jeux de données de formats et
systèmes de coordonnées hétérogènes.
6.1.1.4.
FME Developer Tools
Ce produit consiste en un ensemble de librairies servant au développement
d’application incorporant les fonctionnalités de FME. Par exemple, la
compagnie ESRI a incorporé la technologie FME dans son extension
« ArcGIS Data Interoperability » à l’aide de la librairie d’objets de FME.
6.1.2.
Produits de Vivid Solutions
La compagnie Vivid Solutions est une compagnie Canadienne localisée à
Vancouver et fondée en 1996. Cette compagnie a développé entre autres, une
suite de produits Open Source en collaboration avec la communauté R&D en
géomatique qui sont utilisés partout à travers le monde. Ces produits sont :
JUMP Unified Mapping Platform, RoadMatcher, JTS Topology Suite et JCS
Conflation Suite.
6.1.2.1.
JUMP Unified Mapping Platform
C’est une application ayant une interface utilisateur graphique (GUI)
permettant la visualisation et le traitement des données spatiales. Elle procure
un cadre d’applications (application framework) utilisé pour le
développement et l’exécution d’applications personnalisées de traitements
spatiaux.
6.1.2.2.
JTS Topology Suite
Ce produit est une interface de programmation (API) 100% JAVA fournissant
des prédicats 2D spatiaux et des fonctions pour des opérations géométriques
fondamentales, conformes avec le modèle géométrique de la norme Simple
Features Specification for SQL de l'OpenGIS Consortium (OGC). Les
fonctions fournies sont :
•
•
•
•
•
•
Les prédicats spatiaux (basé sur le modèle DE-9IM (Dimensionally
Extended Nine-Intersection Model)
Fonctions de superposition (intersection, différence, union, différence
symétrique),
Zone tampon,
Enveloppe convexe,
Fonctions de distance et d’aire,
Validation de la topologie.
JTS fournit une fondation solide pour la construction d’applications spatiales
telles un visualiseur, un programme général de requêtes spatiales et des outils
pour la validation, le nettoyage et l’intégration des données spatiales.
6.1.2.3.
RoadMatcher
Cette application réduit grandement le temps nécessaire à la fusion de jeux de
données routières linéaires en fournissant un ensemble d’outils assistant la
fusion multisource automatique et manuelle. Cette application utilise la
plateforme JUMP.
6.1.2.4.
JCS Conflation Suite
Ce produit est une interface de programmation 100% JAVA construite à
partir de l’API JTS et utilisant la plateforme JUMP. Elle permet la fusion
multisource de jeux de données spatiales et opère indépendamment des
logiciels commerciaux. Elle ne supporte pas les formats natifs des outils SIG
et utilise le format GML en entrée et sortie. JCS permet principalement la
fusion multisource de données polygonales et comprend aussi un menu Roads
permettant la fusion des routes. Cependant, RoadMatcher offre plus
d’opérations pour les réseaux routiers linéaires. JCS offre :
•
•
•
plusieurs traitements de fusion multisource de données géospatiales
tels le nettoyage de zones adjacentes, l’alignement de zones
adjacentes et l’appariement des routes;
des fonctions d’assurance de la qualité permettant la détection et
l’affichage des erreurs ainsi que des fonctions de nettoyage
automatiques et manuelles pour ajuster la géométrie
des outils d’édition manuelle pour la fusion des données ne pouvant
être exécutée automatiquement.
6.1.3.
GEOXYGENE
GeOxygene est « une plate-forme logicielle, ouverte et modulaire dédiée aux
applications en information géographique, avec une architecture et un modèle
de données communs, permettant le partage des codes, leur documentation et
leur maintenance. » [Badard et Braun, 2005]. Ce projet Open-source est issu
des développements menés au laboratoire COGIT de l’Institut Géographique
National (IGN, France) par ses auteurs M. Thierry Badard, maintenant
professeur au département des sciences géomatiques à l’Université Laval et
M. Arnaud Braun. La plate-forme GeOxygene est développée en JAVA et
permet le déploiement d’application sous la forme de service Web. Elle
s’appuie sur les standards de l’ISO et l’OGC et permet l’implémentation de la
norme ISO 19107 ainsi que des spécifications relatives à la notion de feature
(Features, Feature Collection et Relationships between features). Elle est un
bon point de départ pour l’utilisation de JAVA Data Objects (JDO) pour les
bases de données géographiques. Cette plate-forme constitue ainsi une base à
la construction de solutions logicielles, s’appuyant sur des données
géographiques, réellement interopérables car implémentant l’ensemble des
spécifications OGC et normes ISO.
Figure 8 : Architecture de la plate-forme GeOxygene avec des exemples de composantes logiciels.
[Extrait de Badard, 2005]
Les composants de l’architecture inclus dans la distribution open-source sont
les suivants:
•
un schéma orienté-objet compatible avec les spécifications et normes de
l’OGC et de l’ISO permettant de modéliser et manipuler toutes les
facettes de l’information géographique (sémantique, géométrie,
topologie, métadonnées). Les utilisateurs modélisent leur application en
UML et la code en Java, en s’appuyant sur ce schéma.
•
•
•
des scripts SQL permettant de manipuler la BD (Oracle avec sa cartouche
spatiale et PostGIS (open source) avec sa sur-couche géographique
PostgreSQL sont supportés). Les données sont stockées dans un SGBD
relationnel afin d’assurer des temps de réponse et d’accès rapides.
un composant open-source, OJB (ObJect relational Bridge, de la
fondation Apache) assure le « mapping » (i.e. « telle classe Java
correspond à telle table ») entre le schéma objet et les tables
relationnelles. Les utilisateurs ont ainsi une perception entièrement objet
de l’information qu’ils manipulent.
les opérateurs géographiques codés dans des bibliothèques séparées, afin
d’assurer l’indépendance des développements. Ces algorithmes
proviennent du Web (ex. : la bibliothèque open-source JTS pour les
calculs de géométrie algorithmique.) ou d’anciens développements déjà
réalisés au COGIT.
Deux outils ont aussi été inclus dans la distribution open-source. Il s’agit d’un
visualisateur d’objets géographiques (Geotools version 1) et un navigateur
graphique permettant l’affichage des propriétés des objets et le
déclenchement dynamiquement des méthodes.
6.2. Opérations ETL
Cette section décrira des catégories d’opérations ETL pouvant être utilisées dans le
développement d’application SOLAP et regroupera sous ces catégories les principales
opérations ETL disponibles dans FME et JTS/JCS.
6.2.1.
Sélection et extraction
Cette catégorie regroupe toutes les opérations permettant de filtrer les
données afin de pouvoir n’en récupérer qu’une partie.
Les outils FME supportent la sélection descriptive et spatiale des données
ainsi que leurs extractions. Voici quelques exemples de ces transformers:
•
AttributeFilter: permet de filtrer les enregistrements suivant les valeurs
possibles d’un attribut. Les valeurs de cet attribut doivent être discrètes
car cet opérateur supporte uniquement l’opérateur « = ».
•
GeometryFilter : permet de filtrer les géométries suivants leur type (point,
ligne, polygone).
•
AggregateFilter : permet de séparer les géométries étant des agrégats des
géométries simples.
•
SpatialFilter : permet de comparer chaque enregistrement d’un jeu de
données Candidat avec tous les enregistrements d’un jeu de données Base
afin de récupérer uniquement les objets candidats satisfaisant la relation
topologique spécifiée avec les objets Bases.
•
Joiner: effectue une jointure entre enregistrements de deux jeux de
données via un ou des champs communs.
•
SQL executor: Permet de filtrer les enregistrements d’une base de
données via une requête SQL. Les formats SIG tel Shapefile, MapInfo,
etc. sont non supportés par cet opérateur.
•
Clipper : Permet de récupérer les données se retrouvant à l’intérieur ou à
l’extérieur de zones.
•
ExpressionEvaluator : Permet d’évaluer si une expression mathématique
est vraie ou fausse. L’opérateur AttributeFilter doit ensuite être utilisé
pour diriger les enregistrements ayant la valeur « vraie » et ceux ayant la
valeur « fausse » vers des destinations différentes.
•
AreaCalculotor, LengthCalculator : Le premier permet de calculer l’aire
de polygones et le second de calculer en 2D ou 3D, la longueur des lignes
ou bien le périmètre d’un polygone. L’aire, le périmètre et la longueur
peuvent ensuite être utilisés comme critère de sélection.
L’exemple de la figure ci-bas montre comment il est possible d’extraire les
bâtiments, du fichier ShapeFile de gauche, ayant une superficie calculée
supérieure à 100 000 m². Le premier opérateur calcule la superficie, le second
évalue si oui ou non (1 ou 0), cette superficie est supérieure à 100 000m² et le
dernier récupère uniquement les enregistrements ayant satisfait la requête
précédente, i.e dont la valeur au champ « _result » est égal à 1.
Figure 9. Exemple de l’utilisation des opérateurs d’extraction et sélection de FME.
FME permet aussi d’extraire uniquement les attributs voulus. Par exemple,
dans l’exemple de la figure ci-haut, le champ « Comment » n’a pas été
récupéré. Il est possible aussi de renommer les attributs. Dans l’exemple de la
Figure 9, les attributs ID_COURANT et _AREA ont été renommés en
ID_BAT et SUPERFICIE.
Le cadre d’applications JUMP permet de sélectionner les objets
géographiques tout comme un SIG, soit :
•
•
•
•
•
objet par objet à l’aide de la souris dans la fenêtre cartographique.
à l’aide d’un rectangle dessiné dans la fenêtre cartographique et
permettant la sélection de plusieurs objets.
à l’aide de la souris dans la fenêtre affichant les enregistrements;
à l’aide de la souris et en mode édition afin de sélectionner qu’une partie
de la géométrie d’un agrégat ou bien le trou d’un polygone.
à l’aide d’une clôture préalablement dessinée.
JTS fournit des opérations géométriques qui pourraient être utilisées pour
l’extraction des données par rapport à leurs types de géométrie et leurs
relations spatiales avec d’autres objets.
6.2.2.
Nettoyage des données
Le nettoyage des données géométriques consiste à rendre les données
exemptes d’incohérences de nature spatiale comme les dépassements
(overshoot), les espacements (undershoot), les découverts (gaps) et les zones
de chevauchement (overlaps).
“Gaps are places where two adjacent polygons are separated by a small
amount along some or all of their boundary (see Figure 10a below). Since
some coverages can contain legitimate spaces between polygons, gaps are
always defined relative to a specified distance tolerance. Only spaces which
have the adjacent line segments separated by less than the distance tolerance
are considered to be gaps”.[JCS, 2003]
“Overlaps are places where two polygons overlap (see Figure 10b below).
No distance tolerance is needed, since any overlap is always considered to be
an error in a coverage.” [JCS, 2003]
Figure 10. Exemple en (a) de découverts et (b) de chevauchement. Extrait de JCS Conflation Suite
User Guide.
“Overshoot is the portion of an arc digitized past its intersection with another
arc.” [ESRI, 2006]
“Undershoot is a line that falls short of another line that it should intersect.”
[ESRI, 2006]
FME comprend :
•
Snapper qui permet d’accrocher les nœuds de lignes ou bien les
sommets de lignes et polygones se retrouvant à distance inférieure à
la distance de tolérance spécifiée. Il permettra de corriger les
dépassements et les espacements.
•
SelfIntersector : Permet du supprimer les intersections de l’objet sur
lui-même.
•
DuplicateRemover permet de filtrer selon les valeurs d’un attribut clé
afin d’éliminer les enregistrements doublons.
JUMP permet d’effectuer une série de tests permettant de valider la topologie
d’une couche spatiale. Entre autres, s’assurer : que les segments ont une
longueur minimum, qu’un polygone ou une ligne ne s’intersecte pas avec luimême.
JCS comprend la fonction Find Coverage Gaps et Remove Coverage Gaps
qui permettent de trouver et détruire les erreurs de découvert. Les
chevauchements peuvent être trouvés grâce à la fonction Find Coverage
Overlaps. Ils doivent cependant être corrigés manuellement. Cependant, les
plus petits d’entre eux ont pu être détectés et corrigés avec les commandes
Find Coverage Gaps et Remove Coverage Gaps. Certains de ces
chevauchements sont aussi dus à des objets géométriques dupliqués.
RoadMatcher comprend aussi des fonctions permettant de corriger les
espacements et les dépassements, mais ces fonctions ne permettent pas de
traiter le jeu de données au complet de façon automatique. Chaque erreur doit
être corrigée l’une après l’autre en utilisant la commande Extend/clip segment
afin d’allonger ou raccourcir le segment jusqu’au segment à intersecter qui
sera scindé en deux. Il est possible cependant à l’aide d’une requête de
trouver les segments en défaut.
6.2.3.
Intégration de données
Lorsque le système se compose de données provenant de sources
hétérogènes, il est inévitable de faire face à des problèmes d’intégration de
données. Avant de charger ces données dans le système, il faut les rendre
homogènes entre elles et les intégrer.
L’intégration multisource est définie selon l’Office québécois de la langue
française comme étant : « Opération qui consiste à transformer les données
qui proviennent de sources hétérogènes (bases de données de production
d'une entreprise, bases de données externes, Internet, etc.), de manière
qu'elles forment un tout cohérent et homogène, au moment où elles sont
versées dans l'entrepôt de données, pour alimenter ou rafraîchir celui-ci. »
[OLF, 2002].
6.2.4.
Intégration informatique
L’intégration informatique des données géospatiales consiste à convertir les
formats de données géométriques des systèmes sources en celui du système
cible. Par exemple, convertir le format DGN en format .SHP d’ESRI. FME
supporte plus de 150 formats différents.
Pour les données descriptives issues des bases de données, elles peuvent
facilement être lues et transférées vers un autre outil via l’interface ODBC
(Open Database Connectivity). Il est aussi possible de convertir les données
descriptives en format ASCII et de pouvoir les importer dans tout système de
gestion de base de données et même dans la plupart des SIG. Les données de
géométrie ponctuelle en format ASCII peuvent aussi être importées
directement dans la plupart des SIG.
6.2.5.
Intégration sémantique
Opération consistant à assurer une cohérence entre le nom des classes (ex. :
bâtiment, construction), le nom des attributs (no civique, numéro civique) et
les valeurs de domaine d’attributs (vrai/faux, oui/non). L’intégration
sémantique comprend aussi la fusion et la scission de classes, le recodage
d’attributs, la généralisation et la spécialisation de classes d’objets.
Les opérateurs ValueMapper et SchemaMapper de FME peuvent être utilisés
pour faire le « mapping » des schémas de deux jeux de données ainsi que des
valeurs des domaines de valeurs. Le « mapping » des noms d’attribut est fait
directement avec l’interface du Workbench de FME.
6.2.6.
Fusion multisource
La fusion multisource (conflation) est un type particulier d’intégration
sémantique utilisant la géométrie des objets pour apparier les sources entre
elles. Selon l’Office de la langue française, elle est définie
comme: « Traitement géomatique qui consiste à transposer les attributs d'une
carte thématique sur une carte géographique de référence, en utilisant
comme points de repère leurs entités géométriques communes. » [OLF,
2001]. ESRI la définit aussi comme étant: « A set of procedures that aligns
the features of two geographic data layers and then transfers the attributes of
one to the other. » La fusion multisource est un processus irréversible, i.e.
qu’il n’est pas possible de reproduire les sources dans leurs états initiaux
puisque seuls les attributs sont conservés.
FME comprend les opérations RubberSheeter et AffineWarper qui
permettent d’ajuster un ensemble d’objets géométriques cibles afin qu’ils
correspondent mieux à la géométrie d’objets géométriques sources. Une fois
les géométries appariées, les attributs peuvent être transférés d’une source à
une autre via l’opérateur Matcher. Dans le cas où, les classes d’objets ont un
attribut commun, l’opérateur FeatureMerger peut être utilisé dans le but de
copier les attributs de la source dans la classe d’objets cible.
Road Matcher de Vivid Solutions a été conçu dans le but de permettre la
fusion multisource de données linéaires de réseaux routiers. Cet outil permet
de créer un nouveau réseau routier à partir de deux sources différentes en
récupérant les segments de la source de meilleure qualité lorsqu’il y a
appariement et d’inclure ou non les segments non appariés dans le jeu de
données résultant. Cet outil comprend donc toutes les opérations nécessaires
pour la fusion multisource de données linéaires.
JCS permet d’apparier des données polygonales ayant une couverture
continue telle les lots cadastraux, les limites administratives, etc. Il permet
aussi l’appariement des routes.
6.2.7.
Intégration horizontale
Elle consiste en l’intégration des jeux de données couvrant des territoires
adjacents et ayant le même contenu, i.e. les mêmes thèmes.
JCS permet d’aligner des données polygonales provenant de plusieurs
sources :
•
Boundary Alignment : permet d’éliminer les découverts et les zones de
chevauchements entre données surfaciques pouvant provenir de deux
jeux de données différents. Cet outil pourrait entre autre permettre
d’aligner les limites administratives de deux jeux de données adjacents.
•
Offset Boundary Corner finder : permet de détecter les déplacements
latéral (offset) entre deux jeux de données polygonales.
Figure 11. Déplacement latéral entre deux jeux de données de type polygone. Extrait de JCS
Conflation Suite User Guide.
6.2.8.
Intégration verticale
Ce type d’intégration consiste à rendre cohérent des jeux de données couvrant
le même territoire mais ayant un contenu différent. Dépendamment des
relations spatiales possibles entre les deux jeux de données à apparier,
plusieurs opérations décrites dans cette section pourraient être utilisée.
6.2.9.
Intégration géospatiale
L’intégration géospatiale fait référence au changement de systèmes de
coordonnées. FME supporte plusieurs systèmes de coordonnées et il est facile
et rapide de convertir les données d’un système de référence à un autre à
l’aide d’Universal Translator.
6.2.10.
Passage de primitives à objet explicite.
Les fichiers CAD sont composés de primitives linéaires et les objets
surfaciques y sont rares. Lorsque l’on récupère de telles données, on doit
construire les surfaces à partir de lignes qui les composent. Il faut parfois
ajouter des lignes virtuelles pour fermer ces polygones, comme dans le cas de
lac.
FME comprend l’opération PolygonBuilder qui permet de contruire
automatiquement des polygones à partir de lignes fermées. Il peut être
préalable à cette opération, d’utiliser les opérations Snapper, Intersector et
SelfIntersector pour nettoyer les données.
6.2.11. Passage d’attributs graphiques textuels à des attributs
descriptifs.
Souvent certaines données descriptives sont uniquement graphiques, visibles
sur la carte sous forme d’étiquette et non rattachées à l’objet géométrique
principal, comme dans le cas du numéro de lot inscrit au centre du polygone
de lot. Lorsque l’on sélectionne les attributs du lot, on ne retrouve pas le
numéro inscrit en étiquette. Il faut donc utiliser des fonctions qui permettent
de lire ces valeurs d’attribut graphique et de les stocker dans un attribut
descriptif rattachée à l’objet géométrique principal.
FME comprend :
•
PointOnAreaOverlay : Chaque point reçoit les attributs du polygone
qui l’inclut et chaque polygone reçoit les attributs de chaque point
qu’il inclut.
•
6.2.12.
NeighborFinder : Apparie les géométries les plus près de deux classes
d’objets. Il est possible de spécifier une distance maximum. Dans ce
cas, il est possible qu’il y ait des géométries non appariées.
Lorsqu’apparié, les attributs des la seconde classe sont copiés dans la
première classe. La géométrie de la première classe est conservée.
Intégration temporelle
L’intégration temporelle peut être au niveau de la donnée elle-même et au
niveau des spécifications de la donnée. Par exemple, un attribut « nombre
d’étage » a été ajouté en mars 2000 au spécification de la classe d’objets
Bâtiment. Donc tous les bâtiments ayant été saisis avant 2000 n’auront pas
cet attribut. Au niveau de la donnée, si la source de données de bâtiments est
plus récente que la source des rues par exemple, on pourrait avoir comme
résultat des bâtiments sans accès à aucune rue.
FME comprend les operations suivantes relatives à l’intégration temporelle :
•
Matcher : Permet de détecter si les objets de deux jeux de données
correspondent au niveau de la géométrie, de leurs valeurs d’attributs ou
bien les deux. Il est possible de définir une tolérance au-delà de laquelle
les sommets de deux géométries seront considérés comme différents.
•
ChangeDetector: Ce transformer ressemble beaucoup à Matcher à
l’exception qu’il catégorise les objets n’ayant pas de correspondance,
comme étant « ADDED » s’ils proviennent du jeu de données le plus à
jour et « DELETED » s’ils proviennent du jeu de données à mettre à jour.
6.2.13.
Généralisation cartographique des données
Selon l’OLF, la généralisation cartographique est : « L’action de simplifier les
éléments cartographiques et leur représentation, en fonction d'un besoin
particulier et selon des règles précises. La généralisation cartographique fait
appel à la simplification des formes, à la modification de la position des
entités spatiales et à la suppression ou au regroupement d'entités spatiales.
Elle est utilisée notamment pour le passage à une échelle cartographique
inférieure. »
Puisque cette opération ETL comprend plusieurs opérateurs, il est important
de les catégoriser. De plus, ces catégories nous permettrons de mieux décrire
ces opérateurs très importants dans le développement d’une application
SOLAP. Nous utiliserons donc les types d’opérateurs définis par Martel
[1997] afin de classifier les différents opérateurs des outils à l’étude (voir
l’annexe F pour une synthèse de ces opérateurs). Le tableau suivant montre
les types d’opérateurs ainsi que les types de géométrie, temporalité et
sémantique auxquels ils s’appliquent.
0D
Vectoriel
Temporel
Sémantique
1D 2D 0D 1D Objet Attribut Relation
Raffinement
Agrégation
Reclassification
Réduction de dimension
Simplification
Resymbolisation
Caractérisation
Exagération symbolique
Déplacement
Déformation
Lissage
Tableau 8. Domaines d’application des types d’opérateurs de généralisation. Extrait de Martel
[1997].
6.2.13.1.
Raffinement
Le raffinement consiste à supprimer des détails afin de conserver
que ce qui est important sans toutefois le modifier. Au niveau
géométrique, il serait possible par exemple de supprimer sur une
carte topographique les lacs ayant une superficie inférieure à un
certain seuil, de supprimer les bâtiments de géométrie ponctuelle
afin que conserver uniquement ceux de géométrie surfacique. Au
niveau temporel, les événements de plus courte durée pourrait être
supprimés, par exemple, on supprime les feux ayant durée moins
de 15 minutes. On pourrait aussi supprimer les événements ayant
une durée de vie instantanée et conserver uniquement ceux ayant
une vie durable dans le cas où la classe d’objets à une temporalité
alternative, i.e. soit instantanée soit durable. Au niveau
sémantique, on pourrait, par exemple, supprimer toutes les routes
dont la classification n’est pas autoroute.
Il est aussi possible de raffiner la structure du jeu de données en
supprimant des attributs ou des relations non essentiels. La
géométrie et la temporalité pouvant aussi être considérées comme
des attributs pourraient être supprimées afin d’éliminer des détails.
Par exemple, la géométrie des bâtiments pourrait être supprimée,
sachant qu’il est possible de déduire par la suite sa position
approximative à partir de son adresse ou bien son code postal.
Le raffinement s’apparentant à la sélection et l’extraction, les
mêmes opérateurs des outils à l’étude, peuvent être utilisés pour
réaliser cette opération de généralisation.
6.2.13.2.
Agrégation des données
L’agrégation permet de combiner plusieurs objets pour n’en
former qu’un seul (i.e. une relation de type n:1) dans le but de
simplifier la représentation lorsque la densité devient trop grande.
Il en résulte une nouvelle classe d’objets dont le niveau
d’abstraction est supérieur et qui conserve l’apparence générale de
la classe d’objets originale. Les objets d’origine peuvent
appartenir à une même classe d’objets (p.ex. plusieurs petits
bâtiments qui s’agrègent pour en former un plus significatif) ou à
des classes différentes (p.ex. l’agrégation des pistes et bâtiments
pour former l’aéroport).
Cet opérateur peut aussi être utilisé au niveau temporel. Dans ce
cas, il combine des événements ponctuels et/ou linéaires pour
former des événements de plus longue durée.
FME comprend les opérations d’agrégation suivantes:
•
Aggregator : Cette opération permet de combiner différentes
géométries en un agrégat. Les géométries sont agrégées selon
leurs valeurs d’attributs.
•
Deaggregator : Permet de décomposer un agrégat en ses
composantes.
•
Dissolver : Génère des polygones de plus grandes superficies
en supprimant les limites communes de polygones adjacents.
Cette opération pourrait être utilisée pour générer les limites
du pays à partir des limites des provinces.
•
NeighborhoodAggregator : Crée un agrégat d’objets basé sur
leurs proximités.
Figure 12. Différence entre l’opérateur Aggregator et Dissolver de FME.
Dans la partie du haut de la figure 12, les peuplements forestiers
sont agrégés sans supprimer les limites entre les peuplements
contrairement à ceux de l’exemple du bas. Dans les 2 cas, les
géométries sélectionnées correspondent à un enregistrement de la
base de données.
6.2.13.3.
Reclassification
La reclassification est l’une des opérations de généralisation les
plus utilisées dans le développement d’un SOLAP. Chaque niveau
hiérarchique, supérieur au niveau détaillé d’une dimension d’un
cube, doit être reclassifié. Par exemple, l’attribut discret type
d’utilisation des bâtiments dont le contenu est détaillé (maison
mobile, maison unifamilial, commerce de restauration, etc.) peut
être reclassifé à un niveau d’abstraction supérieur selon les
valeurs: résidentiel, commercial et industriel. Un attribut continu
tel la marge de recul, peut être classifié selon les catégories :
moins de 2m, 2 à 5m, 5 à 10m, 10 à 30m et plus de 50m tel
qu’illustré dans l’exemple suivant.
Figure 13. Exemple de classification de la dimension « marges de recul » dans un SOLAP.
La principale difficulté de cette tâche est de définir les classes de
chaque niveau. Une fois les classes définies, l’opérateur
ValueMapper peut être utilisé dans le cas d’un attribut discret, afin
d’associer à chaque valeur possible, la valeur du niveau supérieur.
L’exemple ci-bas montre le cas de l’attribut « nombre d’étages »
ayant un domaine de valeurs possibles de 1 à 9 étages, classifié en
3 catégories, soit de 1 à 3 étages, de 4 à 6 étages et de 7 à 9 étages.
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.
Dans
le
cas
d’attributs
continus,
les
opérateurs
ExpressionEvaluator, AttributeFilter et AttributeCreator doivent
être utilisés pour générer les catégories. L’exemple ci-bas reprend
le même exemple que la Figure 14, mais cette fois-ci le domaine
de valeurs du nombre de d’étages est de 1 à 120. Afin de
catégoriser les enregistrements en 3 classes, les opérateurs
ExpressionEvaluator sont utilisés. Ensuite, les opérateurs
AttributeFilter permettent de récupérer les enregistrements dont la
valeur du champ « _result » est à 1 (vrai), donc ayant satisfait
l’expression définie dans l’opérateur ExpressionEvaluator. Les
opérateurs AttributeCreator permettent par la suite de créer un
nouvel attribut « Clas_Etag » qui contiendra les valeurs 1, 2 ou 3,
soit l’identifiant de nos trois catégories d’étage.
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.
Lorsque la reclassification a un impact sur la géométrie, on doit en
plus utiliser un opérateur d’agrégation spatiale afin de générer la
géométrie agrégée résultante. Si la géométrie résultante doit être
des agrégats de géométries l’opérateur Agregate doit être utilisé.
Si par contre les limites adjacentes entre les objets doivent être
supprimées afin de générer de nouveaux objets simples,
l’opérateur Dissolver est à utiliser. Il est aussi possible d’utiliser
les deux commandes dans le cas où on aurait besoin d’agréger les
objets généralisés générés par Dissolver selon le même attribut (si
les objets ayant la même valeur ne sont pas tous adjacents) ou
bien sur un attribut différent.
6.2.13.4.
Réduction de dimension
Cette opération consiste à réduire la dimension de l’objet. Par
exemple, une classe d’objets surfacique à grande échelle, telle une
route, pourrait être représentée par une ligne à petite échelle. La
dimension de l’univers pourrait aussi être réduit, par exemple,
passer d’un univers 3D (x, y, z) à un univers 2D (x, y).
Pour réduire la dimension de l’univers d’un fichier, on a qu’à
diriger un fichier source 3D vers un fichier de destination en 2D et
la coordonnée Z sera automatiquement supprimée. Pour la
réduction de dimension de la géométrie des objets, FME
comprend les opérateurs suivants :
•
CenterLineReplacer : Remplace la géométrie d’une surface
par une ligne traversant le centre du polygone.
•
CenterPointReplacer : Remplace la géométrie linéaire ou
surfacique par un point se trouvant au centre du rectangle
englobant minimum de celle-ci. Dans le cas d’une surface, il
est possible que le point se retrouve à l’extérieur de celle-ci.
•
CenterOfGravityReplacer : Remplace la géométrie par un
point se retrouvant au centre de gravité de celle-ci. Le centre
de gravité correspond à la position obtenu de la moyenne des
coordonnées x, y et possiblement z. Dans le cas d’une surface,
il est possible que le point se retrouve à l’extérieur de celle-ci.
•
LabelPointReplacer : Remplace la géométrie de l’objet par un
point. Si la géométrie est linéaire, le point correspondra au
centre de la ligne. Si la géométrie est une surface, le point se
retrouvera quelque part à l’intérieur de la surface et à
l’extérieur d’un trou.
Figure 16. Distinction entre les opérateurs CenterOfGravityReplacer, CenterLineReplacer ,
CenterPointReplacer..
6.2.13.5.
Simplification des données
La simplification consiste à supprimer des parties de la géométrie
de l’objet tout en conservant la forme générique de celui-ci.
Contrairement au raffinement qui s’applique à la classe d’objets,
la simplification s’applique à l’objet. Un objet ponctuel ne peut
donc pas être simplifié mais une classe d’objets ponctuelle peut
être raffinée. Au niveau temporel, des événements avec présence
ou fonction discontinue peuvent être simplifiés.
FME comprend les opérations suivantes pouvant servir à
simplifier les géométries:
6.2.13.6.
•
AreaGeneralizer: Réduit la densité de sommets composant la
limite des polygones de manière à préserver la couverture
topologique originale.
•
LineGeneralizer : Réduit la densité des sommets d’une
polyligne.
Resymbolisation
Cette opération combinée à une opération de reclassification, est
aussi très importante dans une application SOLAP afin d’associer
à des géométries ponctuelles, une symbologie différente
dépendamment du niveau d’agrégation sur lequel elles sont
représentées.
FME ne comprend pas d’opérateur permettant d’attribuer une
symbologie à des géométries. Cet aspect est géré directement dans
les outils SIG et SOLAP.
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).
6.2.13.7.
Caractérisation
La caractérisation est similaire au raffinement, car elle est utilisée
lorsqu’il y a trop d’éléments pas assez significatifs
individuellement et trop denses. Cependant, contrairement au
raffinement, il ne s’applique pas au domaine sémantique mais
créer un motif (pattern) représentatif des éléments originaux. La
position exacte et le nombre exact de géométries sont alors
abandonnés.
Il n’existe pas d’opérateurs permettant d’exécuter ce type
d’opération automatiquement dans les outils à l’étude.
6.2.13.8.
Exagération symbolique
Cette opération est gérée automatiquement par les SIG. La
dimension du symbole à l’écran de l’ordinateur est déterminée en
fonction de l’échelle d’affichage et des paramètres fournis par
l’usager.
6.2.13.9.
Déplacement
Sur des cartes numériques, le déplacement est une opération de
généralisation moins importante que lorsqu’on utilisait des cartes
papiers. Cependant, si l’on a à imprimer une carte à petite échelle,
les géométries très près l’une de l’autre peuvent se chevaucher. Le
déplacement peut alors être utilisé dans le but de rendre la carte
lisible.
FME comprend la commande OffSetter qui permet de décaler la
géométrie suivant une distance en x, y et/ou z.
6.2.13.10.
Déformation
Contrairement à l’exagération où c’est le symbole qui subit un
agrandissement, la déformation implique une modification (forme
et dimension) de l’entité géométrique elle-même afin d’améliorer
la lisibilité. Cette opération intervient par exemple lorsqu’il s’agit
d’élargir l’entrée d’un port afin de ne pas créer un lac en réduisant
l’échelle. Cet opérateur n’a pas d’application temporelle.
Cette opération doit être réalisée de façon manuelle et n’est pas
très utilisée dans une application SOLAP.
6.2.13.11.
Lissage
Cette opération consiste à déplacer les sommets d’un objet
géographique pour simplifier la forme de l’objet et ne retenir que
les tendances générales. Elle est semblable à la simplification à la
différence que les sommets sont déplacés plutôt qu’éliminés.
Cette opération a une forte connotation esthétique puisqu’elle
améliore l’apparence de l’objet géographique en diminuant les
pics et les fluctuations moins importantes.
Nous n’avons pas eu l’occasion d’utiliser cette opération de
généralisation dans le cadre de nos projets SOLAP.
6.2.14.
Traitement des images
JUMP comprend des transformations affines et de rubber-sheet pour la
correction des images.
FME comprend les opérations suivantes :
•
RasterLineExtractor: convertit tous les objets de format raster en des
lignes individuels.
•
RasterPointExtractor: convertit tous les objets de format raster en des
points individuels.
•
RasterResampler: Redimensionne un fichier raster.
•
RasterSegmenter : Segmente un fichier raster en analysant l’histogramme
des composantes et en identifiant les unités qui sont homogènes avec la
technique fuzzy c-means.
6.2.15.
Traitements des données 3D
FME comprend les transformers suivants pour la transformation des données
3D :
•
ContourGenerator: génère des courbes de niveaux à partir d’un modèle
numérique de terrain.
•
DEMGenerator: Genère un modèle numérique de terrain de format Raster
à partir de points, lignes de cassures et lignes 3D.
•
SurfaceDraper: Pour chaque coordonnée composant la géométrie des
objets d’une classe d’objets, dérive les coordonnées z d’une surface 3D.
•
SurfaceModeler : Permet de générer un modèle numérique de structure
TIN à partir de plusieurs sources de données, tels des points, des lignes de
cassure, des courbes de niveaux, etc..
•
TINGenerator: Génère un modèle numérique de format TIN.
•
VoronoiDiagrammer: Génère un diagramme de type Voronoi.
6.2.16.
Autres opérations intéressantes
FME comprend d’autres opérations de transformations des données pouvant
être utile dans le développement d’une application SOLAP :
•
UUIDGenerator: Calcule un identifiant de type UUID pour chaque objet.
Le UUID est composé 32 chiffres hexadécimaux.
•
TimeStamper : Ajoute un attribut de type horodatage et donne à chaque
objet la date d’aujourd’hui.
•
GOIDGenerator : Calcule un GOID (Geographic Object Identifier) pour
chaque objet.
•
StatisticCalculator: Cet opérateur peut être d’un grand intérêt dans le
développement d’une application SOLAP afin de calculer les mesures du
cube.
6.3. Conclusion
Cette section a permis de monter le nombre impressionnant d’opérations ETL pouvant
être utilisées dans le développement d’une application SOLAP. La technologie
d'intégration de données géospatiales la plus répandue et qui nous apparaît la plus
complète présentement sur le marché est le logiciel FME (Feature Manipulation
Engine) de la compagnie Safe Software de Vancouver. Elle est très rapide et offre
plusieurs fonctions avancées utiles pour faire du ETL-Spatial. Par contre, comme toute
technologie, elle ne couvre pas tous les besoins et les résultats produits devraient être
testés avant d'être intégrés dans une chaîne de production de cubes de données
géospatiales. Les produits de Vivid Solutions sont quant à eux complémentaires : JTS
est utilisé pour effectuer des relations spatiales entre objets, JCS et Road Matcher pour
la fusion de données et JUMP comme une plateforme offrant les fonctions SIG de base
ainsi qu’une interface graphique aux produits JCS et RoadMatcher. GeOxygene
comprend une librairie de classes permettant le chargement, la gestion et l’affichage
des données géospatiales sous forme de classes JAVA définies selon les normes ISO et
OGC.
Tel que spécifié dans cette section, ce sont les opérations de généralisation qui sont les
plus utilisées par rapport à une application SIG, afin de pouvoir charger l’information
des niveaux d’abstraction moins élevés. Cependant, le développement d’application
SOLAP peut nécessiter l’utilisation de fonctions agrégatives qui ne sont pas offertes
par les outils ETL du commerce, et ce, malgré leur grand éventail d’opérateurs.
Généralement, le processus d’agrégation implique l’utilisation d’un opérateur sur les
membres d’une seule dimension spatiale. Cependant, il peut s’avérer fort intéressant
de représenter la relation existante entre deux, voire même N dimensions spatiales
d’un même hypercube de données, telle que l’adjacence, l’inclusion ou l’intersection.
De plus, des opérateurs agrégatifs mixtes, résultant de la combinaison d’opérateurs
spatiaux et non-spatiaux, permettent d’obtenir des résultats numériques pour une
analyse spatiale comme le dénombrement des intersections, la moyenne d’adjacence
ou la somme des superficies, et ce, par région. Il est également possible d’y ajouter la
notion de temporalité en effectuant les calculs selon les périodes représentées. Il reste
donc un large éventail de travaux de recherche à effectuer dans ce domaine tels que
détaillés dans la section suivante.
7. Nouveaux outils produits dans le cadre de la chaire
de recherche industrielle en bases de données
géospatiales décisionnelles.
L’objectif de cette section est de mettre en perspective les travaux planifiés de la
chaire de recherche industrielle en bases de données géospatiales décisionnelles
(http://mdspatialdb.chair.scg.ulaval.ca) du Dr Bédard qui cadrent dans les processus de
production de données multidimensionnelles géospatiales. Plusieurs outils sont
actuellement en conception ou en développement et seront vraisemblablement
disponibles aux partenaires de la chaire d’ici trois ans, soit pour la fin de la Chaire
industrielle. Les outils planifiés ne sont présentement pas disponibles sur le marché et
permettront de compléter ou remplacer avantageusement les tâches manuelles
actuelles ou encore les outils existants qui sont sans référence spatiale, le tout pour le
processus de production de données multidimensionnelles.
La mise en place d’un référentiel informatique enrichi ,intégrant les données spatiotemporelles avec les données décisionnelles (c.f. Projet 1 : Référentiel ISTory), est la
pierre angulaire d'un environnement intégré de méthodes, services web et logiciels
interopérables de conception, traitement et exploitation de la donnée géodécisionnelle.
La mise en place d'un tel référentiel assurera l'évolutivité des systèmes développés au
sein de la chaire de recherche. Ce référentiel, baptisé ISTory (Information SpatioTemporelle + RepositORY, ou en anglais Integrated Spatio-Temporal RepositORY)
contiendra les connaissances sur le domaine géospatial et géodécisionnel
(métastructures transactionnelle, décisionnelle ontologique et de spécifications,
registre d'applications, métadonnées, contraintes d’intégrité, gestion multilingue, etc.).
Il intégrera, les concepts normalisés facilitant l'interopérabilité des systèmes (cf.
normes ISO, OGC, OMG et W3C). Ce nouveau référentiel et ses concepts théoriques
unifiés constituent la recherche fondamentale servant de base à l'ensemble des projets
et des outils qui seront développés dans la chaire. Le résultat sera matérialisé par une
métastructure fédérée XML accessible via des API et des services web. Aucune
technologie similaire n’existe à ce jour ou n’est présentée dans les conférences
académiques. Quoique des projets géodécisionnels soient réalisés depuis peu, ce
nouvel environnement va permettre d’améliorer de façon notable le processus complet
de conception-traitement-exploitation sur les plans méthodologique et technologique.
Afin de positionner adéquatement les méthodes et outils de la chaire de recherche,
nous procéderons à leur présentation en suivant le cycle de développement d’un
système dont la première étape consiste à l’analyse des besoins des utilisateurs.
7.1. Méthode et outils d’analyse des besoins des utilisateurs.
La chaire de recherche industrielle vise le développement d’outil de définition des
besoins géodécisionnels sous la forme d’outil de maquettage et de prototypage rapides
(cf. Projet 2). L’environnement de cet outil sera divisé en trois volets : (1) un volet
didacticiel sur le web permettant de se familiariser avec les applications
géodécisionnelles, (2) un volet maquettage très flexible permettant de simuler
rapidement une solution pour un échantillon de besoins des utilisateurs, et (3) un volet
participatif pour encadrer les discussions, recueillir les commentaires des utilisateurs et
prioriser leurs besoins. Deux niveaux d’analyse des besoins seront distingués : un
niveau global permettant de définir les grandes lignes du système grâce au maquettage
et un niveau détaillé permettant de définir les spécifications détaillées grâce au
prototypage rapide. La recherche et le développement pour cette méthode et ces outils
est déjà en cours. Le volet (1) devrait être terminé pour l’automne 2006 (du moins en
français) et sera accessible aux partenaires de la chaire industrielle dans un premier
temps (incluant RDDC). Le volet (2) a fait l’objet de recherches théoriques depuis le
début de la chaire ainsi que l’objet d’une expérimentation avec Syntell à l’hiver 2006.
Suite à ces travaux, il est prévu qu’un projet soit fait avec l’outil de maquettage RAPT
de Syntell pour enrichir celui-ci dans un contexte de maquettage rapide. Le volet (3) a
été discuté dans le mémoire de MSc de Louis-Étienne Guimond et sera potentiellement
poursuivi ultérieurement s’il s’avérait prioritaire.
7.2. Outils supportant l’élaboration de systèmes
Un projet vise à définir un formalisme de modélisation multidimensionnelle avec le
langage UML étendu pour la référence spatiale et de définir un outil de modélisation
multidimensionnelle (cf. Projet 13). Il en résultera la publication d'un formalisme
supportant la modélisation des différents types de dimensions spatiales d'états et
d'évolutions spatio-temporels, 3D, en temps réel et pour applications mobiles. Ce
projet vise aussi à développer des générateurs automatiques de code pour des outils du
marché, servant ainsi à tout développement d'applications géodécisionnelles. De plus
la modélisation formelle des opérations d’agrégation spatiales permettant la production
de données agrégées, résumées à différents niveaux de granularité telles que la fusion,
la généralisation et la représentation multiple des données multidimensionnelles sera
intégrée à l’outil par le bais du projet 5 (cf. Enrichissement du formalisme de
modélisation multidimensionnel des processus de production de l’information
géodécisionnelle). Ce projet débutera par une étude des fonctions de fusion,
d’agrégation, de synthèse et de développement d’indicateurs. La recherche et le
développement spécifique est débuté et se déroulera jusqu’en 2007. La recherche et le
développement pour l’outil de modélisation est également débutée et se déroulera
jusqu’à 2009 avec différentes dates de livraison pour les différents modules. Plus
particulièrement, cela donnera lieu à 3 versions de Perceptory : Perceptory for
databases, Perceptory for datacubes, Perceptory for GeoWeb services.
Finalement, depuis la définition du web sémantique, la gestion des ontologies est
devenue d’intérêt dans la communauté géomatique. L'équipe de la chaire y travaille
aussi depuis quelques années avec ses partenaires, dont principalement Ressources
Naturelles Canada et Intélec. L’outil ontologique géospatial (cf. Projet 4) fera partie
des outils exploitant le référentiel ISTory (cf. Projet 1) qui sera enrichi d’une structure
d'ontologie, des fonctionnalités d'échange et d'intégration d'ontologies en XML ainsi
qu'un générateur de code OWL. La recherche et le développement de cet outil est
débuté et se déroulera jusqu’en 2008. Une très grande interopérabilité avec les outils
de modélisation objet (ex. les 3 versions de Perceptory) et les méthodes de
spécification fait partie intégrante de ce projet.
7.3. Outils supportant la construction de systèmes
Une méthode d'évaluation et de sélection de données sources (cf. Projet 3) sera
développée et sera compatible avec les normes internationales ISO (ISO TC211 2004)
et OGC (OGC 2004). Il est présentement trop tôt pour affirmer qu’il en résultera un
outil pour assister la méthode, voire pour planifier la forme même de cet outil.
Cependant, cette méthode utilisera le référentiel ISTory (cf. Projet 1) et des services
web externes d’accès aux données et métadonnées (d’où dépend la forme du logiciel
potentiel). Cette méthode et son outil permettront d'évaluer le potentiel
d'interopérabilité et les efforts d'intégration/agrégation des différents jeux de données.
La recherche et le développement de cet outil se déroule de 2005 à 2009.
Un autre projet (cf. Projet 21) vise à développer un outil d’intégration et d’agrégation
des données géospatiales en utilisant l’information du référentiel ISTory (i.e. la
modélisation UML cf. projet 5, l’information ontologique cf. projet 4, ou le contenu de
spécifications cf. partie du projet 1), les résultats de recherche en généralisation
cartographique et représentation multiple du projet GEMURE et fonctionnant pardessus les meilleurs outils d'intégration actuels FME (Safe Software 2004) et JUMP
(Vivid Solutions 2003). La recherche et le développement de cet outil a débuté par le
développement d’extensions spatiales au langage MDX (en collaboration avec Syntell)
et se déroulera jusqu’en 2008.
Plus particulièrement, un outil très spécialisé (sous-ensemble du projet 21, fait en
collaboration avec un projet GEOIDE) est présentement en phase design et son
développement devrait débuter à l’été 2006. Cet outil, appelé RN-ETL (Road Network
ETL), est spécialisé dans la production de cubes de données pour les réseaux
(particulièrement routiers, mais potentiellement génériques). La recherche en cours
vise le volet transactionnel (cf. partie GEOIDE du projet), i.e. la resegmention
personnalisée d’un réseau sur demande et la modification sur demande du système de
référence spatiale (linéaire ou cartographique). La partie multidimensionnelle sera
réalisée en 2007 (i.e. volet agrégatif et analyses spatiales avancées).
Afin de peupler les cubes avec des 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. Dans un premier
temps, peu de méthodes formelles existent pour définir les contraintes d'intégrités
géospatiales, peu d’outils les supportent (ex. Radius Technology de LaserScan,
certaines fonctions réseau de SIG, JCS, etc.) mais aucune ne traite le volet agrégatif
des cubes. Les contraintes d’intégrité utilisent abondamment les matrices topologiques
d’Egenhofer et Herring (1994) ou de Clementini et Di Felice (1995) maintenant
reconnues dans la norme ISO-TC211 ou les capacités d'expression formelle en
langages UML, OCL ou autre. Cependant, rien n'a été fait à ce jour pour définir les
contraintes d'intégrité agrégatives géospatiales (il faut ici mentionner que
contrairement aux données non-spatiales, les données géospatiales agrégées peuvent
provenir d'une source distincte des données détaillées). Ce projet (cf. Projet 16) vise
donc à reprendre les travaux de notre équipe ayant conduit au prototype CSory, puis de
les adapter aux problèmes multidimensionnels. L’outil d'assurance qualité
décisionnelle a priori (i.e. CSory multidimensionnel) sera intégré à la suite de
prototypes basés sur le référentiel ISTory (projet 1). Les pictogrammes de Perceptory
seront également intégrés à la matrice ISO pour en accroître la capacité d’expression.
La recherche et le développement de cet outil sont débutés et se déroulent jusqu’en
2007.
7.4. Outils supportant la transition du système
Lors de l’opération du système, une des difficultés pour les utilisateurs est d'apprécier
la qualité des données qu'ils emploient. Cette problématique apporte plusieurs soucis
quant aux risques d'utilisation inadéquate, d'interprétation fautive, de résultats
incorrects voire de répercussions juridiques (Gervais 2003; Bédard et al. 2004). Les
méthodes actuelles reposent sur l'exploitation simple des métadonnées tant dans le
monde décisionnel que géomatique transactionnel. Un projet (cf. Projet 11) de
recherche conduira à un outil pour évaluer la qualité décisionnelle a posteriori qui
conseillera l'usager sur la qualité globale des données géospatiales visualisées, sur la
valeur d'indicateurs spécifiques de qualité, sur la qualité d'un type de données, pour un
secteur donné, pour une époque donnée, et ainsi de suite selon des critères qu'il aura
définis préalablement. Il s’agit d’une continuité du projet MUM pour lequel un article
de l’équipe du Dr Bédard vient de remporter le ESRI Award 2006 de l’American
Society of Photogrammetry and Remote Sensing. La recherche et le développement de
cet outil sont débutés et se dérouleront jusqu’en à 2007.
Des travaux sont en cours pour permettre des services web de création de minicubes
géospatiaux pour utilisation sur PDA. L’outil en résultant sera un module de services
web spécialisés (cf. projets 8 et 10).
D’autres travaux visant à améliorer les fonctions géodécisionnelles (ex. projets 7, 9 12,
17 et 22) sont présentement à leurs débuts, particulièrement concernant l’intégration de
métadonnées dans les cubes, la modification en temps réel du contenu de cubes, la
prise en charge des évolutions sémantiques pour de longues périodes temporelles,
l’utilisation de structures spatiales matricielles et de fonctions de Data Mining pour
peupler les cubes SOLAP. Il est probable que certaines de ces fonctions se
retrouveront dans les technologies utilisées par les partenaires de la chaire pour leurs
applications (ex. GEOLAP, JMap SOLAP, M3Cat, M3GO).
Tableau 9. Synthèse de la planification de développement des outils.
Projet
R&D
1
Nom de l’outil
Référentiel ISTORY
2005
●
2006
●
Échéancier
2007 2008
●
●
2009
●
2
Outil de définition des besoins géodécisionnels
●
●
●
●
●
3
Outil d'évaluation et de sélection de données sources (si
jugé approprié pour supporter la méthode)
●
●
●
●
●
4
Outil ontologique géospatial
●
●
●
●
●
●
●
●
●
8 et 10
Module de service web de création de minicubes
11
Outil pour évaluer la qualité décisionnelle a posteriori
●
●
●
13
Outil de modélisation multidimensionnelle
●
●
●
●
●
- Enrichissement des processus de production de
l’information (projet 5)
16
CSory, outil d'assurance qualité décisionnelle a priori
(contrainte d’intégrité spatio-temporelles pour cubes)
●
●
●
21
Outil d’intégration et d’agrégation des données
géospatiales
●
●
●
●
●
●
●
●
●
- RN-ETL spécialisé pour réseau routier
plusieurs
Fondations pour l’amélioration d’outils des partenaires
de la Chaire
●
●
8. Intégration des différents outils dans la chaîne de
production de données multidimensionnelles
proposée.
Dans cette section, l’ensemble des étapes de la chaîne de production des données
multidimensionnelles seront discutées en regard des outils utiles pour procéder à ces
étapes. La chaîne de production ayant déjà été introduite à la section 3.0, nous
discuterons directement des outils utiles pour produire les données
multidimensionnelles.
8.1. Bilan de la situation organisationnelle:
Cette étape consiste à évaluer les ressources humaines et matérielles de l’organisation
et d’évaluer les aspects de sécurité et de confidentialité des données.
À cette étape, peu de choses sont directement liées à proprement parler à la production
des données géospatiales décisionnelles, mis à part, si une architecture d’entrepôt de
données décisionnelles existe déjà sur place, on pourrait tenir compte des plateformes
utilisées pour identifier des formats de données à produire.
8.2. Exploration des données:
Cette étape consiste à inventorier les données, évaluer les besoins et si nécessaire
produire une maquette. Le résultat de l’analyse des besoins permet de produire la liste
des indicateurs et des analyses types.
8.2.1.
Inventorier les données :
L’étape d’inventaire des données est semblable au processus d’inventaire
relatif au développement d’une application transactionnelle, c’est pourquoi
les outils existant dans l’organisation pour produire un inventaire de données
descriptifs et spatiaux peuvent être utilisés.
De plus en plus, les produits commerciaux offrent un outil spécifique pour la
saisie des métadonnées des fichiers graphiques qui est intégré ou
complémentaire à leur outil SIG. Par exemple ESRI®ArcCatalogue permet
de saisir les métadonnées selon les normes ISO-TC211 et de les visualiser
ensuite selon différentes normes telle la norme Content Standard for Digital
Geospatial Metadata (CSDGM) du Federal Geographic data Committee
(FGDC). Aussi l’équivalent existe avec Geomedia® 6.0, il s’agit de Spatial
Metadata Management System (SMMS) qui permet la gestion des
métadonnées spatiales selon la norme CSDGM.
Il est aussi possible de se procurer un outil de gestion de métadonnées
disponible en gratuiciel sur le Web, tels Metadata Parser (US Geological
Survey), MetaScribe (NOAA Services Center) ou M3Cat®9 (Intelec
Géomatique). Ce dernier est développé par une compagnie québécoise
partenaire de notre Chaire industrielle et permet de documenter les
métadonnées des normes reconnues et de se développer un profil de
métadonnées personnel. Conçu sur une base de métamodèle, il offre un
niveau de flexibilité supérieur ainsi qu’un lien avec un outil de gestion des
ontologies également développé par Intélec (N.B. notre équipe a contribué
grandement à la conception de cet outil). Il existe des évaluations de certains
outils de métadonnées gratuits sur le site du Federal Geospatial Data
Committee10 .
Finalement, le développement d’un outil de gestion de métadonnées maison
est toujours intéressant puisqu’il permet de compléter plus facilement les
normes de métadonnées par des informations utiles pour le développement de
l’application. Au Centre de recherche en géomatique, un outil de gestion de
métadonnées a été développé l’été dernier pour le projet de recherche sur la
gestion intégrée des données géospatiales et non géospatiales multi-sources
pour le suivi environnemental des sites en érosion le long des infrastructures
routières en Gaspésie et aux Îles-de-la-Madeleine pour le Ministère des
Transports. Dans cet outil, des indications sur la nature des données ont été
ajoutées afin d’identifier facilement quelles données avaient un potentiel
multidimensionnel (ex. quelles pouvaient être agrégées, quelles avaient des
niveaux hiérarchies, quelles pouvaient définir un indicateur). Donc, par un
développement maison simple autour de MS-Access, nous avons ajusté
l’inventaire aux besoins multidimensionnels. Il faut noter ici que nous
n’avions pas besoin de prendre en compte une représentation graphique de la
couverture spatiale de chaque jeu de données (comme le fait M3Cat ou autres
outils de saisie de métadonnées pouvant servir également de géorépertoires).
Donc, à chaque occasion, il faut évaluer les besoins en terme d’inventaire et
ressources disponibles et choisir entre les trois options suivantes: utiliser tel
quel un outil existant, modifier un outil existant (lorsqu’ils le permettent) ou
en construire un. Chaque situation est différente.
De plus, plusieurs infrastructures de données géospatiales tant canadiennes
(Infrastructure canadienne de données géospatiales (ICDG)11 qu’américaines
(National Spatial Data Infrastructure (NSDI12) permettent de télécharger
gratuitement des jeux de données géospatiaux ainsi que leurs métadonnées. Il
est ainsi possible de compléter facilement les données que possède
l’organisation par celles-ci. Ceci peut même se faire automatiquement avec la
mise en place de services Web permettant la découverte automatique de jeux
9
http://www.intelec.ca/technologie_f.html#m3cat
10
http://www.fgdc.gov/metadata/geospatial-metadata-tools
11
http://www.geoconnexions.org/ICDG.cfm/fuseaction/aboutGcs.welcome/gcs.cfm
12
http://www.fgdc.gov/nsdi/nsdi.html
de données spatiaux à partir des métadonnées. Les spécifications OGC pour
les services de catalogue (OGC Catalogue Services Specification 2.0.1) Cette
spécification décrit les interfaces d'accès de services de catalogues. Ces
services permettent la publication de catalogues de métadonnées sur des
données spatiales, sur des services et autres ressources ainsi que la recherche
parmi les entrées de catalogues. Les services de catalogues permettent la
découverte de ressources enregistrées au sein d'une communauté.
Puisqu’aucun outil d’inventaire de données n’a été identifié par RDDC
comme étant à privilégier dans cette étude, un choix définitif devra être fait
lors de l’implantation de la chaîne de production de données géospatiales
décisionnelles.
8.2.2.
Évaluer les besoins et produire une maquette :
À cette étape, il est nécessaire de définir des analyses multidimensionnelles
types avec les usagers afin d’être en mesure de définir les indicateurs
d’analyse, les classifications, les thématiques et les vues appropriées pour les
données. La procédure normale d’évaluation des besoins des usagers consiste
à des entrevues avec les usagers. Malheureusement, aucun outil n’assiste
l’équipe dans ce processus, seule l’expérience de l’équipe de développement
est garante du succès de cette étape. Par conséquent, la chaire de recherche en
simplement dessiner sa maquette dans Powerpoint® en prenant soin de
dessiner les interfaces voulues dans un outil de dessin.
Lorsque les besoins des usagers sont définis, on poursuit généralement avec
la production d’une maquette qui permet de valider ces besoins avant le
développement de l’application. Les outils de maquettage permettent de
produire une maquette selon le visuel propre de l’application résultante. Pour
faire une maquette, on peut utiliser des outils bureautiques connus tels
Word®13 ou Visio® qui contiennent des gabarits de modélisation dont un
d’interfaces Windows permettant de maquetter rapidement une application
composée de fenêtres, boutons et menus déroulants. Autrement, on peut
simplement dessiner sa maquette dans Powerpoint® en prenant soin de
dessiner les interfaces voulues dans un outil de dessin.
Finalement, des outils de maquettage spécifiques peuvent être utilisés comme
Toolbook Instructor® ou Macromedia Director® qui permettent de créer des
animations interactives et des simulations de logiciels et de les distribuer sous
forme de pages web. Avec ces outils, l’équipe de développement peut créer
une simulation de l’application logicielle, y insérer des comportements, des
animations et de la navigation. L’équipe de développement peut par la suite
récupérer l’interface simulée pour l’appliquer pour le développement d’une
nouvelle maquette. Le degré de réutilisation des composantes de la maquette
13
Utiliser la barre d’outils « Contrôle toolbox » de Word.
devient alors plus important que dans le cas de maquettes dessinées avec des
outils bureautiques.
Il existe aussi des outils de maquettage dédiés à des technologies spécifiques.
L’équipe de la chaire a eu recours à l’outil de maquettage RAPT® (Syntell
4i) l’hiver dernier pour maquetter une application de tableau de bord. Ce
genre d’outil permet de produire rapidement une illustration des besoins des
usagers pour le développement d’un tableau de bord spatial. Par conséquent,
si l’outil de maquettage est flexible et extensible, une adaptation des gabarits
visuels de ces outils peuvent permettre de maquetter des applications pour
d’autres technologiques que la technologie dédiée. Ainsi, le développement
d’un gabarit visuel SOLAP permettrait l’utilisation de cet outil pour le
maquettage d’une telle application (il est actuellement limité à l’approche
tableau de bord et le volet spatial est limité aux fonctions de base). Ceci
constitue une orientation technologique à insérer dans les projets de la chaire
et permettra de tirer davantage profit des travaux de L.E. Guimond à ce sujet.
Aucun outil de définition des besoins et de maquettage semble être
actuellement utilisé au RDDC. Un choix définitif devra alors être fait lors de
l’implantation de la chaîne de production de données géospatiales
décisionnelles. La figure suivante fait la synthèse des outils pouvant être
utilisés dans la chaîne de production aux étapes d’exploration des données.
Figure 18. Outils pouvant être utilisés dans la chaîne de production des
données aux étapes d’exploration des données.
8.3. Conception du système :
8.3.1.
Modéliser les systèmes opérationnel et
multidimensionnel :
La modélisation est essentielle à la mise en place de bases de données
efficaces. Pour les données transactionnelles, il existe plusieurs formalismes
bien établis dont le standard UML avec ou sans extension pour les données
géospatiales. Par conséquent, plusieurs outils commerciaux existent et
assistent l’usager dans cette tâche, comme Micosoft Visio® avec son gabarit
UML, Oracle® Designer 2000, IBM® Rational Rose et Borland ®Together.
Par contre, afin d’accroître la productivité de la modélisation des données
spatiales transactionnelles, différentes solutions ont été avancées (ex.
Perceptory, MADS, ArgoGEOUML, GEOFRAME) mais seulement
Perceptory développé par l’équipe du Dr Bédard est utilisé dans plusieurs
pays pour des projets à l’extérieur du milieu académique. Plusieurs fonctions
propres aux données spatiales permettent d’améliorer l’offre des produits
UML standards (ex. modèles plus efficaces à créer et éditer, génération de
code pour SIG, génération de documents de spécifications, compatibilité
accrue avec les normes ISO-TC211)
Du côté décisionnel, aucun logiciel commercial ne semble couvrir cette tâche.
Il existe des propositions de formalisme conceptuel dans les projets de
recherche, mais rien encore de concret n’a été proposé à la communauté. Par
conséquent, la chaire BDGD travaille actuellement à intégrer à leur outil de
modélisation conceptuel Perceptory14 un formalisme de modélisation
multidimensionnel basé sur le formalisme UML étendu à la référence
spatiale. Actuellement, même sans le support d’un outil de modélisation, les
composantes UML actuelles de Perceptory peuvent être utilisées pour
modéliser tous les éléments multidimensionnels (cube, dimension, mesure,
niveau et membre). Les paquetages sont utilisés pour les cubes et les
dimensions alors que les classes sont utilisées pour décrire les mesures, les
niveaux et les membres. La méthode de modélisation prévoit trois niveaux
d’abstraction, soit les niveaux Cube (1), Dimension (2) et Membre (3). Le
premier niveau permet la description générale du ou des cube(s) de
l’application ainsi que de ses composantes (dimensions et mesures). Le
deuxième niveau permet la description détaillée des dimensions (hiérarchies
et niveaux). Finalement, le troisième niveau permet de décrire plus
spécifiquement les membres des dimensions. Pour de plus amples
information sur le formalisme et son application se référer au livrable 2 de ce
projet (cf. Rapport et démonstrateur technologique pour la création de
données, des métadonnées et leur utilisation).
Le support d’un outil de modélisation multidimensionnelle assistera l’usager
dans cette tâche en permettant de:
14
http://sirs.scg.ulaval.ca/perceptory
•
gérer la syntaxe du modèle (liens entre les cubes, dimensions,
niveaux et membres);
•
documenter les métadonnées de transformation et d’agrégation;
•
créer les modèles multidimensionnels à partir de modèles
transactionnels ou de bases de données source;
•
générer l’implantation (en schéma en étoile);
•
générer le code d’implantation de la base de données.
Ce sera la première solution du genre, i.e. intégrant à la fois les
préoccupations multidimensionnelles et spatiales et de plus, à partir d’UML.
Puisqu’aucun outil de modélisation de données n’a été identifié par RDDC
comme étant à privilégier dans cette étude parmi l’ensemble des outils
utilisés, un choix définitif devra être fait lors de l’implantation de la chaîne de
production de données géospatiales décisionnelles.
8.3.2.
Définir les contraintes d’intégrité
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. Dans un premier temps, peu de méthodes formelles existent pour
définir les contraintes d'intégrités géospatiales. Plusieurs sont définies durant
la modélisation de la base de données (cf. étape précédente), mais cette façon
de faire est rapidement limitée et doit être réalisée de manière distincte pour
être efficace, particulièrement dans le cas des données géospatiales où des
milliers de possibilités existent et des choix stratégiques doivent être faits (ex.
outil CSory/G6 développés au CRG il y a quelques années suite aux projets
avec Géomatique Canada et Ressources Naturelles Québec sur des BD
d’envergure). Il s’agit alors d’un exercice en soi qui doit être supporté par une
méthode et un outil appropriés tel que démontré par différents travaux de
recherche antérieurs et actuels.
Dans un deuxième temps, rien n'a été fait à ce jour pour définir les contraintes
d'intégrité agrégatives géospatiales telles que retrouvées dans les cubes. Il
faut ici mentionner que contrairement aux données non-spatiales, les données
géospatiales agrégées peuvent provenir d'une source distincte des données
détaillées, les contraintes d’intégrités entre celles-ci deviennent d’autant plus
complexes à décrire. Pour ces raison, un outil d'assurance qualité
décisionnelle a priori (contrainte d’intégrité spatiale) est en cours de
conception et de développement dans le cadre de la chaire de recherche, le
tout basé sur CSOry/G6 et la matrice topologique 3x3 ISO enrichie des PVL
de Perceptory afin d’exprimer ce qu’elle ne peut exprimer présentement.
Aucun outil de définition de gestion des contraintes d’intégrités semble être
actuellement utilisé au RDDC. Un choix définitif devra alors être fait lors de
décisionnelles
La figure suivante fait la synthèse des outils pouvant être utilisés dans la
chaîne de production à l’étape de conception.
données aux étapes de conception de système.
8.4. Réalisation du système :
8.4.1.
Choix des plateformes et implantation de l’architecture
du système.
À cette étape, il faut choisir l’architecture OLAP qui supportera le système et
par conséquent les plateformes logicielles (SGBD, OLAP) associées.
Toutefois, les efforts reliés au calcul des agrégations et à la gestion des mises
à jour de la base de données multidimensionnelle varieront selon le type
d’architecture OLAP choisi. Si l’architecture retenue est Multidimensionnelle
ou Hybride OLAP, le serveur OLAP assistera l’usager dans la structuration
de la base de données multidimensionnelle, effectuera le calcul des
agrégations des données et permettra la gestion des mises à jour de la base de
données multidimensionnelle. Ces serveurs ne disposent toutefois pas
d’opérateurs spatiaux et ne permettent pas souvent de lier des primitives
géométriques pour supporter la cartographie. Si par contre l’architecture
retenue est relationnelle OLAP, il n’y a pas de serveur OLAP d’impliqué
mais le lien avec les primitives cartographiques ainsi que l’utilisation
d’opérateurs spatiaux est alors possible. La base de données doit être
structurée sans assistance et le recours à une équipe d’analystes expérimentée
est souhaitable. Ensuite, les agrégations devront être précalculées et stockées
dans la table de faits. Selon la complexité du cube de données, le nombre de
combinaisons impliquées et le volume de données total, le calcul des
agrégations peut rapidement devenir une tâche longue et complexe.
L’utilisation des index relationnels permet d’optimiser l’accès aux données,
mais la taille du cube ROLAP demeure assez importante.
Finalement, sans serveur OLAP la mise à jour incrémentielle de la base de
données multidimensionnelle requiert des programmes maison afin de lancer
périodiquement les calculs d’agrégations des données selon la fréquence de
rafraîchissement souhaitée par les usagers. Cette tâche devient rapidement un
obstacle à l’utilisation des structures ROLAP si la fréquence de
rafraîchissement des données est plus courte que le temps de calcul requis
pour effectuer les agrégations et les indexer. Il devient alors avantageux
d’utiliser un serveur MOLAP qui gère le rafraîchissement des agrégations, en
réduit le temps de traitement et leur volume de par sa structure optimisée. Par
contre, aucun serveur MOLAP ne supporte les données spatiales et les
opérateurs spatiaux. Il faut donc une structure parallèle pour le stockage des
données spatiales. Des travaux de la chaire ont toutefois débuté afin
d’extensionner le langage multidimensionnel MDX (utilisé par SQL-Server,
Syntell 4i, Mondrian, etc.) avec des opérateurs spatiaux et ainsi permettre de
tenir compte automatiquement des données spatiales dans un serveur
MOLAP.
Puisqu’aucun système de gestion de bases de données (SGBD) et systèmes
d’information géographiques (SIG) n’ont été identifié par RDDC comme
étant à privilégier dans cette étude, un choix définitif devra être fait lors de
décisionnelles. Par contre, le choix définitif d’une technologie SGBD fera en
sorte de limiter le choix de l’architecture OLAP possible pour l’application.
Par contre, les technologies OLAP de Syntell 4i et JMAP ont déjà été testées
par RDDC dans le projet GEOLAP comme serveur d’application analytique.
La figure suivante fait la synthèse des différentes architectures OLAP
possibles pour la réalisation du système selon les technologies OLAP et
SOLAP étudiées à la section 4.0.
Figure 20. Différentes architectures OLAP possibles pour la réalisation du
système.
8.4.2.
Développer le système
Peu importe le choix de l’architecture retenue, une application OLAP se doit
d’être structurée selon ce type de modèle à la base. Des opérations
particulières sont donc nécessaires afin de structurer les données selon la
structure multidimensionnelle (ex. modèle étoile, en flocon ou en
constellation) modélisée au préalable. D'abord, il faut importer les données
composant les membres des dimensions dans leurs tables respectives.
Ensuite, il faut stocker les identifiants des éléments parents afin de concrétiser
la relation de hiérarchie entre les niveaux de la dimension. Par la suite, à
l’aide des données du système transactionnel, il faut peupler la table des faits.
Pour se faire, il faut créer les identifiant uniques, peupler les identifiants des
niveaux inférieurs (i.e. les plus détaillés) de toutes les dimensions et les
informations correspondants aux mesures du cube (ex. nombre de bâtiments,
nombre de personnes et nombre de lignes électriques). Il faut aussi gérer
l’évolutivité des données et l’historique de celles-ci, c’est pourquoi dans
l’implantation de structures multidimensionnelles complexes, le recours à une
équipe de développement expérimentée est nécessaire.
À notre connaissance, il n’existe pas encore d’outil permettant de générer une
structure multidimensionnelle à partir de la modélisation faite au préalable.
C’est pourquoi l’outil de modélisation Perceptory développé par la Chaire
permettra par son générateur de code de produire cette structure selon le
SCGB relationnel choisi (cf. 8.3.1). Par contre, l’ensemble des outils de
modélisation du marché pourrait être utilisé pour la modélisation
multidimensionnelle en prenant soin de générer manuellement la structure
multidimensionnelle requise.
Le module « administrateur » du logiciel OLAP retenu permet d’effectuer les
configurations de la base de données multidimensionnelle. Par exemple, dans
le cas de la technologie JMAP® Spatial OLAP, l’administrateur permet de
configurer la connexion à la base de données source structurée selon une
structure multidimensionnelle ROLAP et configurer les cubes en définissant
leurs composantes (i.e. définir les dimensions, les hiérarchies, lier les
dimensions à la table de fait et déterminer les mesures). Il est aussi possible à
partir de l’administrateur de créer de nouvelles mesures (dites calculées) dans
le cube de données à partir des mesures de base stockées.
Puisqu’aucun outil de modélisation de données n’a été identifié par RDDC
comme étant à privilégier dans cette étude, un choix définitif devra être fait
lors de l’implantation de la chaîne de production de données géospatiales
décisionnelles.
chaîne de production à l’étape d’implantation de la structure
multidimensionnelle.
données à l’étape d’implantation de la structure multidimensionnelle.
8.4.3.
Extraire, transformer et charger les données :
8.4.3.1.
Données descriptives :
L’étape d’extraction, de transformation et de chargement (ETL) des données
est une étape cruciale dans le processus de production de données
décisionnelle (cf. section 6.0). Plusieurs outils ETL commerciaux existent
pour traiter les données descriptives. Très souvent, les serveurs de bases de
données multidimensionnelles en possèdent un qui lui est intégré, comme
c’est le cas de Microsoft SQL Server® avec Data transformation Services.
Aussi, les serveurs OLAP incluent très souvent dans leur suite de produits un
outil ETL comme Cognos ® Data Integration ou SAS® Enterprise ELT
Server. Aussi, la documentation des transformations appliquées sur les
données est primordiale si on veut bien comprendre le résultat des analyses
produites. Ces outils commerciaux ont souvent un outil de métadonnées
intégré au serveur OLAP ou un outil complémentaire réalisant cette tâche,
comme Cognos® BI Metadata Integration. Malheureusement, à ce jour,
aucun outil ETL pour les cubes de données n’existe et les outils non-spatiaux
ne peuvent pas traiter les données spatiales. Il s’agit ici d’un important
élément de recherche de notre chaire industrielle.
Comme mentionné précédemment les efforts reliés à la réalisation, la
structuration des données multidimensionnelle et à l’agrégation des données
varient selon le type d’architecture OLAP choisi. Sans serveur OLAP, les
agrégations doivent être précalculées et stockées dans la table de faits. Pour
précalculer les agrégations des données, l’usager peut avoir recours à un
logiciel statistique comme SAS® ou développer son programme d’agrégation
maison. À l’aide d’un algorithme combinant les dimensions entre-elles, il est
possible de faire calculer la somme, la moyenne, le minimum ou le maximum
d’une mesure et de la stocker à la suite des autres faits dans la table de faits.
A ce jour cependant, aucun calcul spatial n’est effectué.
8.4.3.2.
Données géospatiales :
Suite à ces constats, il faut tout d’abord faire judicieusement le choix des
sources de données spatiales et non spatiales à intégrer car elles auront un
impact important sur les efforts déployés et la qualité des résultats. En regard
aux différentes contraintes (budget, délais, expertise), il faut identifier les
sources de données de qualité qui nous permettront avec un minimum
d’efforts et de temps d’obtenir la donnée résultante souhaitée avec la qualité
souhaitée. De toute évidence, il n’existe pas encore d’outil qui permettraient
d’assister l’usager dans ces choix et d’évaluer ainsi la meilleure source de
données géospatiales à utiliser selon ses besoins. C’est pourquoi un tel outil
d'évaluation et de sélection de données sources est prévu dans le
développement de la Chaire de recherche, lequel supportera la méthode
actuellement en cours de développement.
Les produits ETL pour le traitement des données spatiales sont plus rares et le
traitement de ces données est beaucoup plus complexe. Lorsque vient le
temps de structurer les données géospatiales, un outil comme Feature
Manipulation Engine (FME) de Safe Software (cf. section 6.0) est tout
indiqué pour produire les données géospatiales décisionnelles.
Quoiqu’aucunement destiné au peuplement de cubes de données spatiales, il
peut être utilisé pour plusieurs fonctions. Plusieurs manipulations simples
peuvent également être faites dans un outil SIG (ex. changement de format de
données, de projection et de datum, fusion de polygones), par contre l’outil
FME permet de décrire le processus de transformation appliqué sur les
données à l’aide d’une séquence de processus qui peut servir à elle seule de
documentation. Différentes opérations doivent être réalisées afin d’intégrer
les données géospatiales, comme uniformiser le datum et le système de
projection de tous les jeux de données.
Comme le processus d’agrégation de données géospatiales nécessaires pour
produire les couches spatiales requises pour les dimensions spatiales des
SOLAP peuvent être complexes, le développement d’un outil d’intégration et
d’agrégation des données géospatiales est planifié dans les travaux de la
Chaire afin de couvrir spécifiquement cette tâche au lieu d’utiliser des outils
SIG ou d’intégration de données comme FME. Ceci permettra d’automatiser
davantage l’ensemble des opérations requises. La première partie d’un tel
outil spécialisé pour les réseaux routiers, appelé RN-ETL, est d’ailleurs en
développement dans notre équipe. Le projet RN-ETL consiste en la
conception et le développement d’une méthode générique et d’un logiciel
permettant la transformation (intégration/agrégation) de données routières
selon des paramètres personnalisables. Disponible sous forme d’un service
Web interopérable, cette application constituera un sous-ensemble de services
ETL (Extract–Transform–Load) pour la création de cubes de données
géodécisionnelles, mais spécialisée sur deux aspects pour le volet
transactionnel: la resegmentation sur demande et le transfert des données
routières entre différents systèmes de référence spatiale (linéaires et
géographiques).
Puisqu’aucun outil ETL n’a été identifié par RDDC comme étant à privilégier
dans cette étude, un choix définitif devra être fait lors de l’implantation de la
chaîne de production de données géospatiales décisionnelles. Seul GDAL
avait été identifié par RDDC comme étant utilisé pour transformer des
données matricielles. Aucun outil de transformation de données vectoriel
n’avait été identifié.
chaîne de production à l’étape d’ETL.
données à l’étape d’extraction, de transformation et d’intégration.
8.4.4.
Tester la validité du processus ETL.
Avant de mettre une telle application entre les mains des usagers, il faut
s’assurer que les données produites sont de qualité. Pour ce faire, FME
possède des fonctionnalités de validation des données spatiales qui peuvent
être utilisées (mais qui devraient être testées auparavant, spécialement pour
les opérations de type agrégatif et généralisant). Afin de compléter ces
fonctionnalités selon les besoins spécifiques des données géospatiales
décisionnelles, un outil pour évaluer la qualité décisionnelle externe (cf.
fitness-for-use) a posteriori sera développé dans la chaire de recherche en
continuation des travaux du projet de manuel à l’usager multidimensionnel
(MUM). Ce projet avait pour objectif le développement d’un outil permettant
de limiter les risques de mauvaise utilisation des données géospatiales en
indiquant des indicateurs de qualité sur les métadonnées.
Aucun outil de définition de test de validité ne semble être actuellement
utilisé au RDDC. Un choix définitif devra alors être fait lors de
décisionnelles
chaîne de production à l’étape de tests de validation.
données à l’étape des tests de validation.
La figure suivante présente dans une figure synthèse l’ensemble des outils
utiles pour traverser les étapes du processus de production des données
géospatiales décisionnelles.
Exploration des données
Inventaire des
données
• ESRI
• ArcCatalogue
• Geomedia SMMS
• Metadata Parser
• MetaScribe
• M3Cat
• Outil maison
• Services de
catalogue OGC
Réalisation du système
Conception
Analyse des besoins
et maquettage
• Microsoft Word
• Microsoft Visio
• Microsoft Powerpoint
• ToolBook Instructor
• Macromedia Director
• Syntell 4i RAPT
• Outil de définition des
besoins géospatiaux
décisionnels (Chaire)
Extraction, transformation et
d’integration des données
spatiales
Contraintes
d’intégrité
Modélisation
• Perceptory
• Micosoft Visio avec
son gabarit UML
• Oracle Designer
2000
• IBM Rational Rose
• Borland Together
• Outil de
Implanter l’architecture OLAP
• Outil
d'assurance
qualité
décisionnelle a
priori (Chaire)
Geomedia
ESRI ShapeFile
Extraction
• FME
• Geospatial Data Abstraction (GDAL)
• JUMP
• Java Topology Suite
• Outil d'évaluation et de sélection de
Architecture ROLAP
Algorithme de calcul
des agrégations
Algorithme de mise à
jour des données
MID-MIF
modélisation
multidimensionnelle
(Chaire)
données sources (Chaire)
Oracle spatial
Bases de
données
JDBC
Autres
Admin SOLAP
Client Jmap
Spatial OLAP
Transformatio
• FME
• JUMP
• Java Conflation Suite
• DVP Vectorization
• DVP Image Batch Processing
• RN-ETL- Outil d’intégration et
Star schema
Architectures MOLAP
MID-MIF
Microsoft
SQL
Server
Données géospatiales utilisées au RDDC
Compressed
ARC Digitized
Raster
Graphics
ERDAS
Geomedia
Vector Map
MID-MIF
ESRI ShapeFile
Oracle spatial
Autres formats
ArcGIS
SAP
BW
Microsoft
SQL
Server
ESRI Shapefile
Oracle spatial
Autres
Microsoft
Serveur
SQL
Syntell 4i Server
SAP
BW
Autres
BD …
• Outils en développement
• Outils utilisés au RDDC
• Outils développés par les
partenaires de la chaire.
Serveur OLAP
Client SAS
Web OLAP
for Java
Microsoft
SQL
Server
Autres
BD …
Bases de
données
JDBC
ArcGIS
MID-MIF
Power
Cubes
Oracle
Serveur OLAP
Client
Syntell 4i
Hyperion
Essbase
Autres
BD …
Serveur OLAP
Star schema
Implanter la
structure
multidimensionelle
• Perceptory
• Micosoft Visio avec
son gabarit UML
• Oracle Designer
2000
• IBM Rational Rose
• Borland Together
• Outil de
modélisation
multidimensionnelle
(Chaire)
Star schema
Données descriptives utilisées au RDDC
d’agrégation des données
Intégration
Architectures HOLAP
MID-MIF
MS
Access
Client
Proclarity
Geomedia
Digital Terrain
Elevation Data
(DTED)
Oracle
Serveur OLAP
• FME
• Java Conflation Suite
• JUMP
• RN-ETL- Outil d’intégration et
d’agrégation des données
Extraction, transformation et
integration des données
descriptives
• SAS (Calcul des aggregations ROLAP)
• SQL Server Data transformation
Services
• Syntell 4i SynLoader
• SAS Enterprise ETL Server
Client
Cognos BI
Tests de validité
• FME
• MUM- Outil
d'assurance qualité
décisionnelle a
posteriori (Chaire)
9. Conclusion
Cette étude visait à 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 spatiales ou de petits comptoirs de données spatiales. Plusieurs
technologies se côtoient lorsque vient le temps de préparer les données géospatiales
décisionnelles, le processus de production de ces données est donc davantage
complexe à mettre en œuvre que pour les données non-spatiales. Ceci est
particulièrement vrai pour chaque étape qui nécessite d’ajouter, d’enrichir ou de
changer des méthodes et des outils. Sans de tels outils, il est possible de faire des
applications qui exploitent la référence spatiale mais avec davantage d’efforts et de
plus grandes limitations. Le plein potentiel de la référence spatiale n’est possible
qu’avec des méthodes et outils adaptés. Les avantages qui en découlent, et
particulièrement la possibilité de comprendre les phénomènes étudiés de façon
beaucoup plus complète et de découvrir des informations autrement impossibles à
découvrir, justifient les efforts de R&D dans cette direction. Ce besoin et la pertinence
des solutions avancées ont été évalués et chaudement supportés par différents
chercheurs et organismes subventionnaires majeurs.
Le présent rapport propose donc une chaîne de production de données géospatiales
multidimensionnelles intégrant différents outils et méthodes, existant ou en
développement. Pour ce faire, les technologies déjà utilisées par RDDC pour produire
des données géospatiales ont été évaluées pour la production de données
multidimensionnelles. De nouvelles solutions commerciales pouvant être d’un grand
intérêt pour RDDC ont aussi été proposées ainsi que des propositions d’outils logiciels
planifiés dans le programme de R&D de la chaire de recherche, lesquels impliquent les
partenaires industriels de la chaire dont certains sont également des partenaires de
RDDC. Les outils de RDDC, de la chaire et de leurs partenaires industriels qui sont
impliqués dans une telle chaîne incluent la suite Syntell 4i (Syntell) dont l’application
GEOLAP (RDDC), JMAP SOLAP (Kheops Technologies), M3CAT (Intélec), DVP
Vectorization et DVP Image batch processing (Groupe Alta).
Aussi une autre avenue de recherche importante est la production de base de données à
représentations multiples. Différentes méthodes de saisis ont été développées afin de
permettre de nouvelles possibilités pour la généralisation cartographique à la volée et
la cartographie web sur demande. Premièrement l’introduction de patrons
géométriques lors de la saisie à représentation multiple est une première voie de
recherche (Cardenas, 2004; Sabo et al, 2005). Ensuite, l’enrichissement de méthodes
photogrammétriques pour l’acquisition 3D (Fredericque et al, 2005) en est une autre.
Par conséquent, l’application de ces méthodes peuvent permettre d’aider à construire
des cubes spatiaux plus riches que ce qu’il est possible de faire présentement en
adaptant le peuplement de cube géospatiaux dès le départ.
Fort de cet inventaire, la définition d’une chaîne de production des données
multidimensionnelles a été introduite et l’intégration des outils discutés précédemment
a été faite à l’intérieur de la chaîne de production.
10. Références
1. Badard, T. et A. Braun. Plate-forme GeOxygene – Guide utilisateur. Institut
Géographique National, mars 2005.
2. 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. 1-20 »
3. Bédard, Y., S. Larrivée, M.-J. Proulx, F. Létourneau & P.-Y. Caron, 1997, Étude
de l'état actuel et des besoins de R&D relativement aux architectures et
technologies des data warehouses appliquées aux données spatiales, Rapport de
recherche remis au CRDV, 98p., Mars.
4. Cardenas, A. ,2004, Utilisation de patrons géométriques comme support à la
généralisation automatique. MSc Thesis, Laval University, Dept. Geomatics
Sciences, Quebec, Canada, 77 pp.
5. ESRI GIS Dictionary, février 2006,
http://support.esri.com/index.cfm?fa=knowledgebase.gisDictionary.gateway
6. Exeros, 2005, Solution Brief, The Economics of Data Integration: Making
Integrated Data Strategies Economically Viable, White Paper, 6 pages.
7. Geoxygene, 2006. http://oxygene-project.sourceforge.net/index.html
8. JCS Conflation Suite User Guide, Vivid Solutions, novembre 2003.
9. Martel, C., 1997. Analyse des capacités et limites de MGE/Map Generalizer pour
la généralisation des cartes routières, Rapport produit dans le cadre du cours
Projet de levés intégrés, Département des sciences géomatiques, Université Laval.
10. Martel, C., 1999. Développement d'un cadre théorique pour la gestion des
représentations multiples dans les bases de données spatiales, Thèse de Maîtrise,
Département des sciences géomatiques, Université Laval.
11. Proulx, MJ, Bernier, E. et Bédard, Y., 2006, Exploration d’applications
décisionnelles à la Direction des inventaires forestiers : Développement d’un
tableau de bord et d’une application Spatial OLAP (SOLAP), Rapport de R&D,
Centre de recherche en géomatique, Université Laval, mars, 69 pages.
12. Sabo M.N, A. Cardenas, Y. Bédard & E. Bernier (2005). Introduction du concept
de patron géométrique et application aux bâtiments afin de faciliter leur
généralisation cartographique à la volée. Geomatica, Journal of the Canadian
Institute of Geomatics, Vol. 59, No. 3, pp. 295-311.
13. Safe Software (produits FME), 2006. http://www.safe.com/
14. Vivid Solutions (produits JTS, JCS et JUMP), 2006.
http://www.vividsolutions.com/
Annexe A- Lecture suggérée 1.
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. 1-20.
Enrichissement du OLAP pour l'analyse géographique:
exemples de réalisations et différentes possibilités
technologiques
Yvan Bédard*, Marie-Josée Proulx**, Sonia Rivest ***
Chaire industrielle CRSNG en bases de données géospatiales décisionnelles
Centre de recherche en géomatique,
0611 Pavillon Casault,
Département des Sciences géomatiques
Faculté de Foresterie et de Géomatique
Université Laval, Québec, Canada,
G1K 7P4
*[email protected]
http://sirs.scg.ulaval.ca/YvanBedard
**[email protected]
***[email protected]
Résumé. 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 sur le territoire. Ces systèmes reposent toutefois
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. Par
conséquent, les nouvelles applications Spatial OLAP (SOLAP) arrivent à point pour
permettre efficacement le déploiement d’applications d’aide à la décision et d’exploration
des données géographiques. Cet article vise à faire connaître les besoins et avantages liés
aux applications SOLAP, particulièrement à l'exploration cartographique des données.
Puisque de telles applications n'ont pratiquement pas été abordées par la communauté
informatique, cet article délaisse les aspects scientifiques traditionnels du OLAP déjà
bien couverts par cette dernière au profit d'exemples concrets d'applications SOLAP et
d'un survol des principaux concepts propres à celles-ci. Notamment, une catégorisation
en trois familles de solutions y est proposée, soit OLAP-dominant, SIG-dominant et
intégrée. Chaque exemple d'application y est positionné et les avantages d'une
technologie SOLAP y sont présentés. Riche de ces expériences, nous terminons avec
quelques "difficultés cachées" de la référence spatiale qui font l'objet de nos
préoccupations de recherche.
Introduction
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 d'euros. Cependant, les données ainsi produites sont surtout de nature opérationnelle et
Présenté à la 1ere Journée Francophone sur les entrepôts de données et l’analyse en ligne (juin 2005).
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é, voire l'impossibilité d'agréger et synthétiser automatiquement 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 sousexploitation des technologies de l'information et des communications par la communauté géomatique,
et (5) un manque de technologies décisionnelles géospatiales efficaces. Le présent article traite de ce
dernier point, particulièrement de l'analyse spatiale en ligne (SOLAP).
Il est déjà reconnu que pour soutenir leurs processus décisionnels, les organismes déploient des
entrepôts de données et utilisent des outils clients spécifiques afin d'accéder, visualiser et analyser leurs
données intégrées. Puisqu'une grande partie de ces données peut avoir une composante spatiale (ex.
position GPS, adresse civique, polygone cartographique), de nouveaux outils sont nécessaires pour
profiter pleinement de la position et la forme des phénomènes analysés. Il a été démontré [Caron 1998]
que les technologies OLAP sans visualisation et navigation cartographiques présentent d'importantes
limitations pour l'analyse de phénomènes géographiques et spatio-temporels comme on en rencontre en
environnement, foresterie, agriculture, urbanisme, sécurité, transport, etc. Malheureusement, cette
solution prévaut encore aujourd'hui malgré que différentes possibilités existent pour développer des
applications d'analyse spatiale en ligne (appelées "applications SOLAP").
L'objectif de cet article est de présenter ces différentes possibilités tout en mettant l'accent sur la
solution la plus évoluée : la "technologie SOLAP". Ainsi, la prochaine section résume les besoins
spécifiques au monde géodécisionnel et présente les opportunités qui conduisent depuis 1997, au
développement d’applications SOLAP avec différentes solutions (ex. combinaisons SIG + OLAP,
technologie SOLAP). La troisième section définit la technologie SOLAP et présente certains concepts
spécifiques aux données spatiales accompagnés d'exemples d’applications. La quatrième section
présente les différentes méthodes de développement d’applications SOLAP, incluant l'utilisation de la
technologie Spatiale OLAP et chaque exemple d'application y est positionné. Finalement, nous
concluons avec des avenues de recherche importantes pour le développement d’applications SOLAP du
point de vue de géomaticiens spécialisés sur la donnée géospatiale.
Les besoins spécifiques du géodécisionnel.
Les données emmagasinées dans les entrepôts de données forment la base des analyses et guident
l’organisation dans sa prise de décision. Cependant, les données ne sont pas toujours exploitées selon
leur plein potentiel et une partie de leur richesse, c'est-à-dire, leur composante spatiale, est souvent
inutilisée. "Hidden in most data is a geographical component that can be tied to a place : an address,
postal code, global positioning system location, (…) region or country" [ESRI 2000]. En effet, il est
estimé qu’environ quatre-vingt pour cent des données stockées dans les bases de données corporatives
possèdent une référence spatiale [Franklin 1992], laquelle référence peut inclure, en plus de la position,
une forme, une orientation et une taille. La simple visualisation de cette composante spatiale permet de
répondre à un premier besoin, soit de mieux comprendre le phénomène en question en voyant sa
position dans un cadre de référence géographique, en voyant son étendue sur le territoire, en voyant sa
distribution sur le territoire (concentrée, dispersée, par groupes, aléatoire, régulière, etc.). Une telle
visualisation permet de découvrir des informations non disponibles dans les outils OLAP traditionnels,
soit des modes de distribution géographique du phénomène ne suivant pas les découpages territoriaux
prédéfinis comme membres d'une dimension (ex. nom du pays, nom de la région, nom de la ville).
L'utilisation de la composante spatiale permet également de répondre à un deuxième besoin, soit de
découvrir des relations spatiales entre différents phénomènes géographiques (ex. corrélation spatiale
entre une fréquence d’une maladie X et un taux d'émission d'un polluant Y). Cette découverte peut se
faire par visualisation même si une corrélation ne suit pas la hiérarchie de la dimension territoriale telle
que définie dans le cube de données (i.e. dont la délimitation géographique est uniquement identifiée
par un nom de lieu, comme pays – province - région administrative). Cette découverte peut également
se faire par l'ajout de plusieurs découpages territoriaux ou l'ajout de dimensions d'analyse spatiale
[Marchand et al 2004]. Souvent, l’affichage cartographique révèle des informations (ex. proximité
entre deux phénomènes isolés, étendue d’un phénomène, forme d’un phénomène longeant une rive,
orientation des phénomènes selon un flanc de montagne) qui n’auraient pas été soupçonnées en faisant
appel à d’autres méthodes de représentation telles que les tableaux et les graphiques.
Un troisième besoin majeur dans un contexte d'analyse spatiale en ligne est celui de pouvoir
naviguer dans une carte aussi librement que ce que permet un outil OLAP dans les tableaux et
graphiques statistiques. Ainsi, l'utilisateur a besoin de pouvoir regarder les détails d'une région d'intérêt
grâce à un forage spatial, comparer ces détails avec ceux d'une autre région qui n'est pas adjacente,
découvrir s'il y a des caractéristiques communes entre les distributions spatiales du phénomène dans ces
deux régions, remonter à une vision plus globale pour comparer un phénomène local avec un
phénomène national, voir l'évolution du phénomène sur le territoire sans être restreint au découpage
géographique de la dimensions spatiale utilisée, obtenir des valeurs statistiques spatiales et temporelles
sur l'évolution de ce phénomène, etc. Beaucoup de connaissances géographiques peuvent être obtenues
par l'utilisation appropriée de la visualisation et de la navigation cartographique à la OLAP, et ceci
même pour des références spatiales non prévues dans le cube de données.
L'utilisation de la carte comme médium d'exploration de données permet d'avoir un modèle
informatisé se rapprochant davantage de la réalité de l'utilisateur et conséquemment lui demandant un
moins grand effort d'abstraction, ce qui accroît son efficacité. L'utilisation de la cartographie impose
également une utilisation plus judicieuse, grâce à la sémiologie graphique [Bertin 1977, Tufte 1992],
des variables visuelles telles que la couleur, la teinte, le poids des traits et la trame, mettant ainsi en
action de façon plus efficace les principales facultés corticales (mot, image, nombre, couleur,
conscience spatiale, etc.). Les cartes se prêtent mieux que les tableaux et graphiques statistiques à
l'ajout de codes, symboles et couleurs significatifs permettant de mieux supporter l'exploration
interactive des données.
La possibilité de naviguer dans la carte permet de chercher des associations, favorisant la
découverte de relations spatiales insoupçonnées et potentiellement la construction d'un nouveau cube de
données avec un découpage différent du territoire. Une application SOLAP, comparativement à une
application OLAP, réveille davantage notre capacité de visualisation exceptionnelle car la capacité de
perception et de réflexion du cerveau humain, tout comme sa mémoire, relèvent du domaine de l'image.
Plusieurs études, dont principalement celle de Standing [1973], ont démontré que la capacité de
rétention de la mémoire est beaucoup plus grande pour les images que pour les mots [Fortin et
Rousseau 1989] et que pour les chiffres. Selon [Buzan et Buzan 2003], "les images sont donc souvent
plus évocatrices que les mots, plus précises et plus aptes à déclencher un vaste éventail d'associations".
L'application de la théorie soutenue par ces deux auteurs et de plusieurs autres recherches sur le cerveau
(ex. [Standing 1973]) nous amène à déduire que l'effet stimulant que procurent les cartes incite à une
meilleure exploration des données en gardant le cerveau plus alerte, en encourageant un meilleur
rythme visuel, en développant davantage la conscience spatiale et en améliorant la vision globale.
Pour obtenir une telle efficacité avec les données géospatiales, plusieurs défis doivent être
surmontés et des avenues de recherche importantes doivent être adressées puisque certains aspects
demeurent problématiques. Alors que certaines avenues relèvent davantage de l'informatique
traditionnelle (ex. indexation et compression des données), d'autres relèvent typiquement de la
géomatique (ex. généralisation cartographique, représentation multiple, précision spatiale, sémiologie
cartographique, intégration et agrégation spatiale).
De toute évidence, les outils client actuellement utilisés pour exploiter les entrepôts ne sont pas
adaptés aux entrepôts de données géospatiales, car ils n’exploitent pas la structure géométrique des
données [Han et Kamber 2001]. Certes, ils peuvent être utilisés, mais sans la capacité de manipuler la
composante cartographique, ils ne peuvent pas supporter d’analyses ni d'explorations avancées [Rivest
et al 2003].
De nouveaux outils client sont requis pour exploiter le plein potentiel de cette composante
cartographique. Les systèmes d’information géographique (SIG) qui permettent d'assembler, stocker,
manipuler et afficher l'information à référence spatiale [Longley et al 2001] représentent un premier
candidat potentiel. Par contre, malgré ses capacités d’analyse spatiale poussées, il est reconnu que le
SIG seul, avec son architecture OLTP limitée, souffre d'un interface de requête complexe et de temps
de réponse lents aux requêtes agrégatives, en plus de ne pas offrir les fonctions temporelles et
navigationnelles nécessaires pour soutenir l’aide à la décision. Des solutions alternatives doivent être
développées [Bédard et al 2001]. Dans un premier temps, l'utilisateur doit pouvoir se concentrer sur
l'information recherchée (le "quoi") et non pas sur les opérations nécessaires pour y parvenir (le
"comment"). Dans un deuxième temps, pour être efficace, le processus de prise décision doit suivre le
flux de pensée de l’utilisateur. Il ne doit pas être interrompu par des manipulations complexes et des
temps de réponse trop longs. Les requêtes spatiales, la navigation, l'affichage des cartes avec niveau de
détail et la sémiologie graphique appropriée, ainsi que la synchronisation entre les vues
cartographiques, tabulaires et graphiques doivent s'effectuer à l'intérieur de 10 secondes, soit à
l'intérieur de la bande cognitive identifiée par [Newell 1990]. Ce haut niveau de convivialité associé à
une interactivité très fluide sont nécessaires pour naviguer à la vitesse de la pensée [Vitt et al 2002].
Enfin, le tout représente en soi un défi majeur pour les SIG lorsqu’ils sont utilisés seuls. Ainsi, parmi
les solutions potentielles, le couplage des technologies spatiales et non-spatiales, comme SIG et OLAP,
semble être une bonne option et a été expérimenté par notre équipe depuis 1997. Ce couplage a pavé la
voie à l’émergence d’une nouvelle famille d’outils mieux adaptée pour les analyses spatiales et
spatiotemporelles, c’est-à-dire les technologies SOLAP. Cette nouvelle famille est conçue dès le départ
pour exploiter les entrepôts de données spatiales multiéchelles, l'enrichissement des concepts
d'exploration de données en fonction d'une référence spatiale explicite et le paradigme
multidimensionnel, ce qui lui procure plusieurs avantages sur les simple couplages SIG-OLAP.
Qu’est-ce qu'une technologie SOLAP ?
La technologie SOLAP peut être définie comme "un type de logiciel qui permet la navigation rapide
et facile dans les bases de données spatiales et qui offre plusieurs niveaux de granularité d'information,
plusieurs thèmes, plusieurs époques et plusieurs modes d'affichage synchronisés ou non : cartes,
tableaux et diagrammes " [Bédard 2004]. La technologie SOLAP supporte la structure
multidimensionnelle telle qu'utilisée en informatique décisionnelle, ce qui lui confère un immense
avantage sur les logiciels de déploiement d’application cartographique sur le Web (ex. ArcIMS,
GeoMedia WebMap, MapX), même lorsque ceux-ci offrent des opérations appelées forage (ex.
Push’n’See [Korem 2005]), car ces derniers sont basés sur une structure transactionnelle. La
technologie SOLAP offre aussi de nouvelles fonctions d’aide à la décision non disponibles dans les
SIG traditionnels ni dans les outils OLAP (cf. section 3.2). Malgré une histoire courte, le SOLAP
atteint déjà un premier niveau de maturité avec ses propres concepts, technologies et applications.
Une technologie SOLAP 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. Dans une technologie SOLAP la création des cartes résultantes des analyses
est dynamique, contrairement à certains logiciels de visualisation OLAP (ex. Visualizer de Cognos) où
chacune des opérations de navigation spatiales (ex. forage) doit être prédéfinie dans l’application et
associée à une carte. Cette limitation complexifie la mise à jour des données géométriques en
répartissant l’information sur plusieurs cartes. De plus, un tel outil SOLAP gère adéquatement les
règles de représentation cartographique des résultats des analyses sur les cartes. Par conséquent,
l’utilisation d’un tel outil ne nécessite pas le support d’un expert en cartographie même s'il permet à
l'utilisateur de créer des centaines de milliers de cartes différentes par quelques clics de souris. Dans la
présentation des résultats, la technologie SOLAP utilise les mêmes règles sémiologiques (ex. couleur,
trame, contour) pour l'ensemble des affichages, i.e. tableaux, graphiques et cartes. Cela permet d’avoir
une synchronisation visuelle entre les différents modes de présentation de l’information et d'avoir un
panorama homogène. La sémiologie graphique utilisée pour les différents types d’affichage (i.e.
tableaux, graphiques et cartes) demeure synchronisée lors d’un forage ou lors d’autres opérations,
conservant ainsi une continuité perceptuelle nécessaire à la découverte de corrélations.
Enfin, il faut distinguer les applications SOLAP des technologies SOLAP. Une technologie SOLAP
est une technologie générique construite spécialement pour offrir des fonctions SOLAP de base ou plus
avancées sans nécessiter d’efforts de programmation. Le premier produit commercial SOLAP est le
résultat des travaux de notre laboratoire et est commercialisé sous le nom de JMap Spatial OLAP
[KHEOPS 2005]. Une application SOLAP est une application métier qui fournit à l'utilisateur un
certain nombre de fonctionnalités de type SOLAP et qui peut être construite soit avec la technologie
SOLAP, soit avec des combinaisons de technologies non-SOLAP (ex. SIG et OLAP) et du code de
programmation maison, ou soit avec d'autres technologies (ex. librairies en Java).
Applications SOLAP réalisées avec différentes technologies.
Les outils SOLAP peuvent être utilisés pour déployer une multitude d’applications. À travers les
différents projets de recherche, notre équipe a développé plusieurs applications dans un but
d'expérimentations technologiques diverses et d'identification des lacunes des technologies du marché.
Une des premières expériences a été réalisée en foresterie et a fait appel à deux produits fonctionnant en
parallèle sans interface commune, soit PowerPlay de Cognos et GeoMedia d'Intergraph. Nous avons
également expérimenté l'utilisation d'un logiciel de visualisation scientifique qui semblait offrir les
fonctions recherchées, soit AVS (Advanced Visual Systems) [AVS 2005], mais avons abandonné cette
piste après plusieurs mois de développement car la gestion des objets géométriques était déficiente lors
de son utilisation en 1999 (ex. surfaces avec des trous, surfaces composées de polygones disjoints), le
langage de programmation était propriétaire et le résultat devenait trop lourd à maintenir dans notre
contexte. Par contre, une autre application fut développée pour aider les gestionnaires à distribuer les
budgets de maintenance du réseau routier en se basant sur les périodes budgétaires, les conditions
routières, la classification des routes, le flux de circulation, etc. En plus de croiser, visualiser et explorer
les informations requises, le cube permet de simuler la dégradation de la chaussée et de calculer les
coûts de différents types de maintenance [Rivest et al 2001]. La figure 1 présente cette application qui
fut développée avec l’outil OLAP ProClarity [ProClarity 2005], SQL-Server Analysis Services de
Microsoft et l’API de GeoMedia WebMap avec une interface commune développée en Visual Basic.
Une autre application en transport permet d'analyser les données relatives aux différents types
d'accidents en fonction de leur position sur le réseau routier et des caractéristiques de celui-ci, le tout en
fonction de différentes périodes [cf. Rivest et al 2004]. La figure 2 illustre cette application cette foisci déployée avec une technologie SOLAP, soit JMap Spatial OLAP [KHEOPS 2005] et Oracle 10g.
Contrairement aux autres solutions, celle-ci ne nécessitait pas de développement supplémentaire pour
l’interface à l'usager puisque cette technologie SOLAP inclut l'interface. Les détails des différentes
méthodes utilisées pour ces applications SOLAP sont donnés à la section 4.
FIG. 1. Une application de gestion du réseau routier (ProClarity et GeoMedia WebMap) :
Visualisation de l’état de la chaussée au niveau des segments de route.
FIG. 2. Une application sur les accidents sur le réseau routier (JMap Spatial OLAP et Oracle 10g) :
Visualisation de la fréquence des accidents par découpage territorial (en haut) et selon les types
d’accidents (en bas).
Une application en santé environnementale permet d’explorer les relations entre les états de santé et
les phénomènes environnementaux, comme l’incidence des maladies respiratoires en fonction de la
qualité de l’air pour rapidement valider ou invalider une hypothèse [cf. Bédard 2002]. La figure 3
présente cette application développée par programmation en Visual Basic, MS Access et la librairie du
logiciel de visualisation cartographique SoftMap et la même application à la figure 4 développée avec
ProClarity, SQL-Server Analysis Services de Microsoft et KMapX [Knosys 2000] et une interface
commune développée en VBScript.
FIG. 3. Une application en santé environnementale (Visual Basic et librairie de SoftMap) :
Visualisation des cas de décès de maladies respiratoires.
FIG. 4. Une application en santé environnementale (ProClarity et KMapx).
Visualisation des cas de décès des maladies respiratoires.
Une application sur la cohorte d’étudiants inscrits ces 15 dernières années à l'Université Laval
permet une analyse par programmes d’étude, provenances géographiques, institutions de provenance,
etc. afin de mieux planifier les prochains efforts de recrutement [cf. Proulx et Bédard 2004]. Une
application relative aux sports de haut niveau permet d'analyser les performances (vitesse, vitesse
maximale, durée, constance) atteintes par des athlètes de patinage de vitesse sur différentes sections de
la piste et selon différents facteurs techniques (ex. type de départ), mécaniques (ex. type de patin) et
météorologiques (ex. vitesse et direction du vent), le tout à partir de mesures prises par système de
positionnement satellitaire GPS [cf. Veilleux et al 2004] . Les figures 5 et 6 illustrent ces deux
applications déployées avec la technologie JMAP Spatial OLAP et Oracle 10g.
FIG. 5. Une application sur la cohorte d’étudiants (JMap Spatial OLAP) : Visualisation des étudiants
par provenance géographique.
FIG. 6. Une application sur les performances des athlètes de patinage de vitesse (JMap Spatial OLAP)
: Visualisation de la vitesse moyenne des patineurs sur la piste (gauche) et par segments de parcours
(droite).
Plusieurs autres domaines d’applications ont été explorés par notre équipe, tels que la sécurité
publique et le transport maritime. Récemment, des applications en SOLAP 3D sur la gestion des forêts
et les fouilles archéologiques mettent à profit l’aspect tridimensionnel de l’espace, c’est-à-dire les
volumes. Dans l’application en archéologie, il est possible de naviguer dans les différentes unités
stratigraphiques fouillées afin de comparer les lots de fouille entre eux en fonction de leur couleur, de
leur granulométrie, de leur consistance, de leur position géographique et stratigraphique et du type
d’artéfacts (ex. céramique) trouvés dans le lot [Fortin et Bédard 2004]. La figure 7 illustre l’application
d’archéologie où les lots sont représentés comme des volumes (i.e. en trois dimensions) [Rageul 2004].
La figure 8 présente une application sur la gestion des forêts qui permet de visualiser sur un modèle
tridimensionnel, les volumes de bois, les perturbations naturelles, les essences végétales, etc [Brisebois
2004]. Ces deux projets sont basés sur une interface développée en Visual Basic utilisant le SIG ESRI
ArcGIS, le client OLAP ProClarity et le serveur OLAP SQL-Server Analysis Services de Microsoft.
FIG. 7. Une application tridimensionnelle en archéologie (ESRI ArcGIS et ProClarity) : Visualisation
des lots fouillés sous la forme de volume.
FIG 8. Une application tridimensionnelle pour la gestion des forêts (ESRI ArcGIS et ProClarity) :
Visualisation des chablis sur le modèle 3D.
Vocabulaire du monde SOLAP
Comme c'est le cas pour toute technologie et norme géospatiale moderne, les concepts apportés ici
reposent sur les concepts informatiques standards et apportent les extensions nécessaires pour effectuer
de nouvelles fonctions ou pour améliorer l'exécution des fonctions existantes. Ainsi, en comparaison au
modèle multidimensionnel conventionnel, le modèle multidimensionnel spatial comprend aussi des
faits et des dimensions non-spatiales. Par contre, comme nous le décrivons ci-après, il existe aussi des
dimensions spatiales de différents types, des mesures spatiales et des opérations spatiales. Sans aller
dans les détails, nous en présentons les principaux concepts dans les sous-sections qui suivent.

Dimensions spatiales
Le SOLAP possède des capacités de manipulation de données spatiales qui supportent des
dimensions spatiales non-géométriques, géométriques et mixtes en plus des dimensions non-spatiales
[Han et al 1998; Bédard et al 2001]. La dimension spatiale non-géométrique utilise la référence spatiale
nominale seulement (ex. les noms des lieux) et aucune représentation cartographique n’est associée aux
membres de la dimension. Ce type de dimension spatiale est couramment utilisé dans les outils OLAP
conventionnels. Les deux autres types de dimension spatiale incluent des formes géométriques
référencées spatialement sur une carte qui permettent aux membres de la dimension d’être visualisés et
interrogés d’une manière cartographique. Ces géométries existent pour tous les niveaux de la dimension
spatiale géométrique ou pour seulement certains niveaux dans le cas d’une dimension spatiale mixte.
La figure 9 présente les trois types de dimensions spatiales.
FIG. 9. Les trois types de dimensions spatiales supportées par le SOLAP.
Une autre catégorie de dimension à caractère spatial, plutôt atypique, est parfois créée pour faciliter
la navigation dans les cubes à l'aide d'opérateurs topologiques spatiaux (ex. adjacent, inclus, intersecte)
ou temporels (ex. précède, en même temps, durant). Nous appelons de telles dimensions les dimensions
d'opérateurs topologiques spatiaux, temporels ou spatio-temporels. En faisant correspondre les
opérateurs à des membres, il devient facile de préciser avec plus ou moins de détail la relation désirée
entre différents phénomènes (ex. inclus -> inclus totalement -> inclus totalement sans partage de
frontière). Une telle dimension d'opérateurs a été utilisée avec succès pour l'analyse des déplacements
de radios amateurs [Marchand et al 2004] et pour notre application en archéologie.

Mesures spatiales
Dans un contexte multidimensionnel spatial, il n’y a pas que les dimensions qui possèdent une
composante géométrique, mais aussi les mesures. Par conséquent, en plus des mesures
conventionnelles supportées dans les systèmes OLAP, il existe les mesures spatiales [Rivest et al,
2001].
Le pointeur spatial est le type de mesure spatiale le plus connu [Han et al 1998]. C’est la méthode
utilisée par les technologies SIG pour gérer la composante géométrique des objets spatiaux. Il s’agit
d’un ensemble de pointeurs (stockés dans le cube de données) vers la géométrie d’un objet spatial
stockée dans une autre structure que la structure multidimensionnelle.
Le second type de mesure spatiale est la transposition au monde spatial de la mesure
conventionnelle du OLAP. Elle permet de dériver des valeurs à l’aide d’un opérateur métrique ou
topologique d'analyse spatiale dont le résultat sera ensuite stocké dans le cube de données (ex. surface
d’un objet, distance minimale avec l'objet le plus proche, cumul de longueurs sur un réseau).
Finalement, la dernière mesure spatiale consiste à générer des données géométriques sous la forme
d’un ou plusieurs objets spatiaux obtenus par la combinaison de dimensions spatiales géométriques (ou
mixtes en utilisant les niveaux où les membres possèdent une géométrie). Il s’agit d’un ensemble de
coordonnées obtenu à partir des opérateurs d’analyses spatiaux d’un SIG, par exemple les coordonnées
d'un point, ligne ou polygone résultant de l’intersection spatiale des membres de plusieurs dimensions.
Ainsi en est-il des polygones résultant de l’intersection des polygones délimitant les membres des
dimensions spatiales frontières politiques et bassins versants.

Opérateurs spatiaux de navigation
Finalement, les outils SOLAP possèdent des opérateurs de navigation pour explorer via la carte
l'ensemble des données spatiales. Les opérateurs spatiaux de navigation proposent différents forages,
dont le forage spatial, le remontage spatial et le forage latéral spatial. L’opérateur de forage spatial
permet à l’usager de naviguer d’un niveau général à un niveau plus détaillé à l’intérieur d’une
dimension spatiale géométrique (ex. cartographier les régions sous-jacentes composant un pays). Une
opération de remontage permet la navigation inverse, c'est-à-dire de remonter d’un niveau détaillé des
données vers un niveau plus général (ex. cartographier les données nationales sus-jacentes à une
région). Finalement, un opérateur de forage latéral permet de visualiser les différents membres du
même niveau de détail d’une dimension spatiale (ex. cartographier pour mieux comparer les mesures de
la région sud par rapport à celles de la région nord). Ces opérateurs sont utilisés directement sur la
carte.
Les opérateurs spatiaux de navigation peuvent s’appliquer sur un objet individuel (ex. visualiser les
régions composant l’objet Canada) ou s’appliquer à l’ensemble des objets d’un niveau de détail (ex.
visualiser l’ensemble des régions composant le niveau Pays).
Approches pour le développement d'applications SOLAP
Cette section décrit, à partir des travaux de Rivest [Rivest 2000], 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 objet-relationnel 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 [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 accessoire. Dans le dernier cas, les
deux volets sont jugés importants et leur coordination ou synchronisation est une particularité clé de
cette technologie.
Solutions OLAP dominant
Ce type de solution procure toutes les fonctionnalités d’un outil OLAP, il est donc implicite qu’une
telle solution utilise les capacités d’un serveur OLAP. Par contre cette solution n'intègrera qu’un très
faible sous-ensemble des fonctions d’un SIG, généralement les fonctions d’affichage, de navigation
cartographique (ex. déplacement et changement d'échelle) et de sélection d’éléments géométriques.
Les fonctions d’analyse spatiale, de synchronisation cartes-tableaux-graphiques, de modification de
cartes, etc. ne sont pas disponibles pour ce type de solution qui peut être qualifiée d’application
géospatiale périphérique où la référence spatiale n’est utilisée que comme support à la visualisation
d’analyses non-spatiales [Bédard et al 1997]. Certaines fonctions minimales de forage spatial peuvent
parfois être offertes et permettent alors de développer des applications SOLAP intéressantes.
Des alliances entre compagnies OLAP et SIG font en sorte de faciliter le développement de telles
applications. Un premier exemple de partenariat est celui de ProClarity [ProClarity 2005] et MapInfo.
ProClarity est un logiciel client OLAP qui permet de manipuler des bases de données
multidimensionnelles (cubes) créées à 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 et autres diagrammes. Le plugiciel KMapX, basé sur la technologie MapX de MapInfo,
permettait la visualisation et le forage sous forme cartographique des données géométriques associées à
une dimension spatiale géométrique du cube. Un fichier de configuration permettait de définir les
données spatiales géométriques à coupler à une des dimensions d’un cube. Un partenariat récent entre
les compagnies MapInfo et Microstrategy [BI.com 2004] pourrait bien offrir une solution similaire à
court terme et, selon les fonctionnalités offertes, devenir une offre de la troisième famille (i.e.
intégrée). Un autre produit disponible sur le marché et très représentatif de cette première famille est le
logiciel Visualizer de Cognos. Visualizer est un logiciel de visualisation de données pouvant provenir
de sources diverses telles qu’un serveur OLAP ou une base de données relationnelle. Visualizer permet
d’afficher les données descriptives d’une base de données multidimensionnelle sous forme de différents
types de diagrammes. Le logiciel permet aussi l’affichage cartographique des données spatiales d’une
dimension par le biais de la technologie MapX de MapInfo.
Par contre, une faiblesse principale de cette famille de solutions, outre le temps de programmation
requis, se situe au niveau du nombre de dimensions spatiales géométriques supportées. En effet, les
deux logiciels ne permettent de visualiser qu’une seule dimension spatiale à la fois, ce qui élimine la
possibilité d’étudier des corrélations spatiales. De plus, certains outils (ex. Visualizer) ne sont pas
flexibles au niveau de la construction du volet de visualisation cartographique car chacune des
opérations OLAP spatiales doit être prédéfinie et associée à une nouvelle carte, ce qui complexifie la
mise à jour de ces cartes. En fait, il y a autant de cartes différentes que de vues cartographiques
possibles, ce qui rend une telle approche utilisable uniquement dans un contexte de mises à jour peu
fréquentes et ne nécessitant pas d'interopérabilité.
Solutions SIG dominant
Un serveur OLAP peut être simulé à l’intérieur d’une base de données relationnelle par le biais de la
modélisation en étoile. Lorsque le volume de données à consulter est peu élevé, cette solution peut
s’avérer très avantageuse, puisque les calculs d’agrégation peuvent s’effectuer de manière sélective et
contrôlée à l’aide de requêtes SQL sur la base de données. Ces requêtes peuvent alors être adaptées en
fonction des besoins d’un projet particulier, en évitant par exemple de calculer les agrégations nonsignificatives ou en permettant de joindre les tables impliquées dans les requêtes de manière plus
flexible que ne le permettent habituellement les serveurs OLAP qui utilisent des fonctions d’ « inner
join ». Par contre cette solution doit inclure, dans la base de données, des éléments permettant de gérer
la réalisation d’opérations OLAP telles que le forage et le remontage puisqu’il n’existe pas de serveur
OLAP pour gérer ces opérations.
Les solutions SIG dominant offrent toutes les fonctionnalités de l’outil SIG, mais seulement un
sous-ensemble des fonctionnalités de l’outil OLAP (ex. limitations dans le pivot des dimensions et le
forage cartographique). Cette solution couple une base de données relationnelle simulant un serveur
OLAP à un logiciel SIG ou à un outil de visualisation de données spatiales. L'interface graphique à
l'usager ainsi que les fonctions de forage tant sémantiques que spatiales doivent alors être
programmées. De même en est-il pour les fonctions d’analyse spatiale et temporelle, de la
synchronisation cartes-tableaux-graphiques, etc.
Solutions intégrées
Ce type de solution, intégrant les fonctionnalités d’un outil OLAP et d’un SIG, pourrait être qualifié
d’application centrée-géospatiale où la référence spatiale des objets est utilisée constamment dans
l’exploration et l’analyse des données, de façon aussi libre qu'avec les dimensions non-spatiales
[Bédard et al. 1997].
Ce type de solution est utile lorsque l’application doit s'intégrer dans un environnement géomatique
à fort flux de données (ex. pour les mises à jour cartographiques, l'interopérabilité) ou nécessite
l’utilisation de fonctions spécifiques au SIG, comme par exemple les opérateurs d’analyse spatiaux. Les
solutions de cette famille sont réalisables soit à l’aide des librairies de fonctions de logiciels client
OLAP et de logiciels SIG, soit à l’aide de technologies SOLAP. Dans le premier cas, le développement
d’une telle solution est possible moyennant beaucoup de programmation ad hoc à l’intérieur d’un cadre
applicatif spécifique. Pour ce faire, certaines technologies OLAP, tels que ProClarity de ProClarity et
Essbase d’Hyperion rendent disponibles leurs librairies de fonctions et d’objets pour la réalisation
d’applications spécifiques à l’aide de langages de programmation courants comme Visual Basic ou
C++. Il est alors possible de développer une extension OLAP à intégrer au logiciel SIG comme
MapInfo, ArcView d’ESRI et GeoMedia d’Intergraph qui permettent l’utilisation de leurs librairies de
fonctions avec les produits MapX, MapObjects et GeoMedia respectivement. De plus, le produit
OpenMap qui consiste en un ensemble de composantes Java dédiées à la manipulation des données
spatiales géométriques [OpenMap 2005], peut aussi être utilisé pour le développement du volet SIG.
Une technologie SOLAP permet quant à elle d’intégrer l’ensemble des fonctionnalités OLAP et
SIG, voire de les enrichir. L'interface graphique met à disposition de l’usager des fonctions de forage
tant spatial que sémantique, des fonctions d’analyse spatiale, de séries cartographiques temporelles, etc.
Les bénéfices de l’utilisation d’un tel outil sont nombreux au niveau de la manipulation et de la mise a
jour des données cartographique car on a ici accès à un SIG. D’un autre coté, le couplage entre le volet
géométrique et descriptif des données est déjà programmé, le temps de développement d’une telle
application est donc réduit au minimum. Des outils de navigation cartographique permettent de forer
dans les cartes d’une manière synchronisée avec les autres types d’affichages (ex. tableaux et
diagrammes). Un transfert technologique entre l’Université Laval et la compagnie québécoise
KHEOPS Technologie, propriétaire de la solution SIG-Web JMap, a permis de développer la première
solution commerciale intégrée de SOLAP (printemps 2005).
Les trois familles de solutions exposées dans cette section présentent un parallèle avec l'évolution
de l'intégration CAD-SGBD vs SIG qui eut lieu durant la décennie 1985-95 [Bédard 1991]. Nous
rencontrons encore aujourd'hui les différents types d'intégration SGBD-CAD et SIG et chaque type
d'intégration répond à des besoins et des contextes différents. Enfin, il est possible de grouper
différemment les solutions présentées, soit : avec ou sans programmation ad hoc pour le développement
de solutions SOLAP. Les principales difficultés liées à la programmation ad hoc découlent de la
complexité d'une interface à l'usager qui soit efficace et élégante ainsi que du temps requis pour cette
programmation qui doit être adaptée à chaque nouvelle application.
Positionnement des applications réalisées
Afin d’illustrer l’éventail des applications réalisées dans nos laboratoires, chacune des applications
présentées à la section 3.1 sera positionnée dans leur famille de solution respective. Premièrement,
l’application de santé environnementale (cf. figures 4) développée avec ProClarity et le plugiciel
KMapX, ainsi que l’application sur la gestion du réseau routier (cf. figure 1) développée avec
ProClarity et GeoMedia WebMap d’Intergraph font partie de la catégorie des OLAP dominant. Bien
qu’intéressantes, ces applications auraient nécessitées beaucoup plus de programmation maison pour
atteindre les niveaux de fonctionnalité et de flexibilité offerts par les solutions intégrées.
Ensuite, l’application de santé environnementale (cf. figures 3) développées par programmation
Visual Basic à partir du SGBD MS Access et du logiciel de visualisation cartographique SoftMap fait
partie de la famille des SIG dominant. Cette application a exigé davantage d’efforts de programmation
que les solutions OLAP dominant précédentes étant donné l’absence de serveur OLAP pour la gestion
des données multidimensionnelles.
Les applications tridimensionnelles sur la gestion des forêts et ainsi qu’en archéologie (cf. figures 7
et 8) font partie de la catégorie des SOLAP intégrés, puisqu’un SIG a été utilisé pour la gestion des
objets volumétriques qui était l’intérêt principal de l’application. L’outil OLAP ProClarity a été retenu
pour la gestion du descriptif. Finalement, les applications des figures 2, 5 et 6 ont nécessité très peu
d’effort de développement, puisqu’elles ont été déployées dans une solution SOLAP intégrée toute
prête, soit la version précommerciale de l’outil JMAP Spatial OLAP utilisant Oracle Spatial comme
base de données. Le tableau 1 permet de positionner graphiquement les différentes applications selon
leur catégorie, qu’elle requiert des efforts de programmation ou non (out-of-the-box).
OLAP
Dominant
SIG
Dominant
Solution
toute prête
(out-of-the-box)
Solution
nécessitant de
programmer
SOLAP
Intégré
2,5,6JMap Spatial
OLAP
4- ProClarity/ KMapX,
1- ProClarity/ GeoMedia
WebMap
3- SoftMap/
Visual Basic
7,8-ArcGIS/
Proclarity
TABLEAU 1. Positionnement des applications (cf. numéro des figures)
selon les trois familles de solutions potentielles et leur degré de programmation.
Conclusion
L'objectif de cet article était de faire découvrir les différentes possibilités de développement
d’applications SOLAP tout en mettant l'accent sur la "technologie SOLAP". Par conséquent, pour bien
comprendre les enjeux du développement de telles applications, un résumé des besoins spécifiques du
monde géodécisionnel a été présenté ainsi que quelques éléments du vocabulaire SOLAP. Notre
objectif n'était pas de décrire le tout d'une façon trop formelle et scientifique, mais plutôt de véhiculer
un message sur le fort potentiel du SOLAP jusqu'ici négligé par la communauté informatique. Des
exemples concrets d’applications SOLAP développées à notre centre de recherche ont donc été
présentés non pas comme catalogue de nos réalisations mais pour mieux illustrer ce potentiel et
soutenir le reste de l'article. Trois familles de solutions possibles ont ainsi été décrites pour réaliser de
telles applications SOLAP et nous y avons positionné nos applications. Les principales limitations des
différentes familles ont été discutées, chaque famille pouvant découler de contextes particuliers.
Le développement d’applications SOLAP requiert encore des efforts de recherche importants
puisque certains aspects demeurent problématiques. Plus particulièrement du point de vue géomatique
(i.e. des problèmes liés à la donnée géospatiale), notons la quasi-impossibilité de générer
automatiquement les niveaux agrégés d'information cartographique pour les cubes à partir des données
cartographiques fines (cf. limitations de la généralisation cartographique automatique), la discordance
entre l'agrégation cartographique et la généralisation cartographique (nécessaire pour assurer la
visibilité de la carte), la très grande hétérogénéité spatiale des données (ex. les cartes ne se superposent
jamais correctement), l'enrichissement nécessaire des méthodes de conception pour prendre en compte
la difficulté de production des données géospatiales, la prise en compte des processus complexes de
mise à jour cartographique pour le peuplement des cubes de données géospatiales décisionnelles, le
contrôle des nombreuses métadonnées géospatiales (plus de 400 dans la norme internationale de
métadonnées ISO-19115 [ISO, 2002]), contradiction vs synchronisation entre les règles de sémiologie
graphique utilisées en cartographie vs graphiques statistiques, gestion de l'évolution des découpages
territoriaux vs évolutions sémantiques vs mesures, et ainsi de suite. C'est au développement de
solutions à ce type de problème que nous concentrons nos efforts, en complémentarité avec la
communauté informatique pour les aspects fondamentaux OLAP.
Remerciements
Les auteurs tiennent à remercier les organisations suivantes pour le financement de la Chaire
industrielle en bases de données géospatiales décisionnelles : Conseil de Recherche en Sciences
Naturelles et en Génie du Canada, Recherche et Développement Défense Canada, Hydro-Québec,
DVP, Intélec Géomatique, Holonics, KHEOPS Technologies, Syntell, Ressources Naturelles Canada,
Transports Québec et l’Université Laval.
Références
[AVS 2005] Data Visualization and Visual Analytics, http://www.avs.com/index_wf.html
[BI.com 2004] BusinessIntelligence.com, 2004. MapInfo and MicroStrategy Deliver Location-Enabled
Business
Intelligence,
September
2004,
http://www.businessintelligence.com/ex/asp/id.606/xe/binewsdetail.htm
[Bédard 1991] Bédard, Y., 1991, Les logiciels SIG : une évolution via l'intégration de données
multisources, Journal de la Société Française de Photogrammétrie et de Télédétection, No. 122, p.
58-63
[Bédard et al 1997] Y. Bédard, S. Larrivée, M.-J. Proulx, P.-Y. Caron, F. Létourneau, 1997. Geospatial
Data Warehousing : Positionnement technologique et stratégique, Rapport préparé pour le Centre
de recherche de la défense de Valcartier, Université Laval, 79 pp.
[Bédard et al 2001] Y. Bédard, T. Merrett, J. Han, 2001. Fundamentals of Spatial Data Warehousing
for Geographic Knowledge Discovery, Geographic Data Mining and Knowledge Discovery, Taylor
& Francis, Research Monographs in GIS, Chap. 3, p. 53-73
[Bédard et al 2002] Y. Bédard, P. Gosselin, S. Rivest, et al, 2002. Integrating GIS Components with
Knowledge Discovery Technology for Environmental Health Decision Support, International
Journal of Medical Informatics,Vol. 70, No. 1, p. 79-94
[Bédard 2004] Y. Bédard, 2004. Amélioration des capacités décisionnelles des SIG par l'ajout d'un
module SOLAP. Université de Provence, Centre de Mathématiques et Informatique, LSIS,
Marseille, 8 avril.
[Bertin 1977] J. Bertin, 1977. La graphique et le traitement graphique de l'information, Flammarion
Paris, 273 p.
[Buzan et Buzan 2003] T. Buzan, B. Buzan, 2003. Mind Map, dessine-moi l'intelligence, 2è édition.
Éditions de l'Organisation, Paris, 325 p.
[Brisebois 2004] Analyse du potentiel d'extension du concept SOLAP pour l'exploration des données
spatiales 3D, Mémoire de maîtrise, Département des Sciences géomatique, Université Laval.
[Caron 1998] P.Y. Caron, 1998. Étude du potentiel de OLAP pour supporter l'analyse spatiotemporelle. MSc. Dép. Sciences géomatiques, Centre de recherche en géomatique, Université Laval,
129 p.
[ESRI 2000] ArcView, 2000. GIS Brochure. http://www.esri.com/library/whitepapers/avlit.html.
[Fortin et Bédard 2004] M. Fortin, Y. Bédard, 2004. Développement d'un système de découverte des
connaissances spatio-temporelles issues d'un chantier de fouilles archéologiques, Colloque
Géomatique 2004, 27-28 octobre, Montréal, Canada
[Fortin et Rousseau 1989] C. Fortin, R. Rousseau, 1989. Psychologie cognitive : une approche de
traitement de l'information. Presses de l'Université du Québec, 434 p.
[Franklin 1992] C. Franklin, 1992. An Introduction to Geographic Information Systems : Linking Maps
to Databases. Database, April, pp. 13-21.
[Guimond 2004] L.E. Guimond, 2004. Conception d’un environnement de découverte des besoins pour
le développement de solutions SOLAP, M.Sc.Dép. Sciences géomatiques, Université Laval, 128 p.
[Han et al 1998] J. Han, N. Stefanovic, K. Koperski, 1998. Selective materialization : An Efficient
Method for Spatial Data Cube Construction. Pacific-Asia Conference on Knowledge Discovery and
Data Mining (PAKDD'98), Melbourne, Australia.
[Han et Kamber 2001] J. Han, M. Kamber, 2001. Data Mining : concepts and Techniques, Morgan
Kaufmann Publisher, Inc, 2001.
[ISO, 2002] International Standard Organization, 2002, Geographic Information, 19115-Metadata, 141
pages.
[KHEOPS 2005] KHEOPS, 2005. JMAP Spatial OLAP,
http://www.kheops-tech.com/en/jmap/solap.jsp
[Knosys 2000] Knosys, 2000, Geo Spatial Mapping : MapInfo MapX Plug-In for Knosys ProClarity
3.0,
[Korem 2005] Korem, 2005. Site web Push’n’see, http://www.pushnsee.com/
[LGS Group 2000] LGS Group Inc., 2000. Analysis of Health Surveillance Business Intelligence Tools
and Applications, Final Draft, 111 pp.
[Longley et al 2001] P.A. Longley, M.F. Goodchild, D.J. Maguire, D. Rhind, 2001. Geographic
Information Systems and Science. John Wiley & Son, 454 p.
[Marchand et al 2004] P. Marchand, A. Brisebois, Y. Bédard, G. Edwards, 2004. Implementation and
evaluation of a hypercube-based method for spatio-temporal exploration and analysis, Journal of
the International Society of Photogrammetry and Remote Sensing,Vol. 59, No. 1-2, p. 6-20
[Newell 1990] A. Newell, 1990. Unified theories of cognition. Harvard University Press, Cambridge
MA, 549 p.
[OpenMap 2005] OpenMap, 2005. What is ? http://openmap.bbn.com/whatis.html
[Pestana et al 2004] G. Pestana, M. M. da Silva, H. Madeira, 2004. A Prototype Implementation of a
Spatial Data Warehouse for Integrating Business, Historical and Spatial Data,” 5th Int. Conf. of
Intelligent Data Engineering and Automated Learning.
[Pestana et al 2005] G. Pestana, M. M. da Silva, Y. Bédard, 2005. Spatial OLAP Modeling : An
Overview Base on Spatial Objects Changing over Time, IEEE 3rd International Conference on
Computational Cybernetics, 13-16 avril, Mauritius
[ProClarity 2005] ProClarity, 2005. ProClarity Product Information, http ://www.ProClarity.com/,
[Proulx et Bédard 2004] M-J Proulx, Y. Bédard, 2004. Le potentiel de l'approche multidimensionnelle
pour l'analyse de données géospatiales en comparaison avec l'approche transactionnelle des SIG.,
Colloque Géomatique 2004, 27-28 octobre, Montréal, Canada
[Rageul 2004] Développement d'une application d'exploration de données géospatiales comme support
à la fouille archéologique, Rapport de fin d’études, École d'ingénieurs INSA de Strasbourg, France
[Rivest 2000] S. Rivest, 2000. Investigation des modes d’intégration physique entre un serveur de base
de données multidimensionnelle et un SIG, M.Sc. Dép. Sciences géomatiques, Université Laval, 84
p.
[Rivest et al 2001] S. Rivest, Y. Bédard, P. Marchand, 2001. Towards better support for spatial
decision-making : defining the characteristics of Spatial On-Line Analytical Processing,
Geomatica,Vol. 55, No. 4, p. 539-555
[Rivest et al 2003] S. Rivest, Y. Bédard, M.J. Proulx, M. Nadeau, 2003. SOLAP : a new type of user
interface to support spatio-temporal multidimensional data exploration and analysis, Workshop
ISPRS, Quebec, Canada, October 2-3.
[Rivest et al 2004] S. Rivest, P. Gignac, J. Charron, Bédard, Y, 2004. Développement d’un système
d’exploration spatio-temporelle interactive des données de la Banque d’information corporative du
ministère des Transports du Québec. Colloque Géomatique 2004, 27-28 octobre, Montréal, Canada
[Standing 1973] L. Standing 1973. Learning 10000 pictures. Quaterly Journal of Experimental
Psychology, vol. 25, 207-222.
[Tufte 1992] E.R. Tufte, 1992. The Visual Display of Quantitative Information. Graphics Press, 191 p.
[Veilleux et al 2004] J-P, Veilleux, Lambert, M., Santerre, R., Bédard Y., 2004. Utilisation du système
de positionnement par satellites (GPS) et des outils d'exploration et d'analyse SOLAP pour
l'évaluation et le suivi de sportifs de haut niveau, Colloque Géomatique 2004, 27-28 octobre,
Montréal, Canada
[Vit et al 2002] E. Vitt, M. Luckevich, S. Misner, 2002, Business Intelligence, Making Better
Decisions Faster, Microsoft Press, 202 p.
Summary
Important efforts have been made for the last fifteen years to set up geospatial decision
support systems. However, these systems are based on geographic information systems
(GIS) and usual transactional approaches (OLTP) to produce geodecisional information,
often with unacceptable delays and prohibitive costs up to the point of dropping the
production. Consequently, the new Spatial OLAP (SOLAP) applications arrive just in
time to allow effective implementations of geospatial decision support systems. This
article highlights the needs and the advantages related to SOLAP applications,
particularly for cartographic data exploration. Given that such applications have almost
never been tackled by the computer science community, this paper does not discuss the
traditional scientific issues of OLAP applications which are widely addressed by this
community. Instead, it presents concrete SOLAP examples and an overview of the main
underlying concepts. A categorization in three families of solutions is proposed: OLAPdominant, GIS-dominant and integrated solution. Each given example of applications is
then positioned in regards to these categories and the advantages to use the integrated
solution are addressed. We finally conclude with a brief overview of the typical “hidden
difficulties” related to geographic data which are one of our research preoccupations.
Annexe B : Lecture suggérée 2.
Section 1.11.2 On-line Analytical Processing, Bédard, Y., S. Larrivée, M.-J. Proulx, F.
Létourneau & P.-Y. Caron, 1997, Étude de l'état actuel et des besoins de R&D
relativement aux architectures et technologies des data warehouses appliquées aux
données spatiales, Rapport de recherche remis au CRDV, 98 p., Mars.
L’utilisation d’un outil OLAP dans les data warehouses s’adresse parfaitement aux besoins
d’un data warehouse et permet entre autre de simplifier la navigation dans la base de données
possédant une structure multidimensionnelle.
L’architecture OLAP consiste en trois services: la base de données, le serveur OLAP et le
module client.
1. La base de données détermine comment et où les données sont enregistrées. La base de
données d’une architecture OLAP doit au départ supporter des données agrégées ou
résumées. Cette base de données peut donc provenir d’un data warehouse ou de data marts.
Cette base de données doit ensuite posséder une structure multidimensionnelle qui peut
être implantée dans un SGBD multidimensionnel aussi bien que dans un SGBD
relationnel. Ainsi, “The multidimensional data store15 logically stores the data in arrays
conform to the multidimensional model into a multidimensional database. The relational
data store stores the data conform to the relational data model as keyed records in tables,
and the data can be accessed by a common language SQL in a relational database.” (Gill et
al., 1996).
Dans le SGBD relationnel, l’utilisation du schéma en étoile (star schema) permet de
simuler une structure multidimensionnelle. Ainsi, les informations relatives aux
dimensions des données sont stockées dans des tables relationnelles appelées fact tables.
Ces tables sont ensuite interprétées par le serveur OLAP afin de construire une vue (réelle
ou virtuelle) du cube multidimensionnel relative à ces données. Sans vouloir s’étendre sur
le sujet, notons que la structure modélisée à l’aide du star schema n’est pas normalisée,
c’est pourquoi l’utilisation d’un schéma en flocon (snow flakes schema) permet d’accroître
les performances d’interrogations. Les différents types de modélisation sont bien présentés
dans un article produit par Brooks (1995).
2.
Le serveur OLAP est le logiciel qui gère la base de données de structure
multidimensionnelle et l’accès des usagers. Pour éviter la confusion terminologique
possible entre les serveurs OLAP, Cafasso (1996) les a baptisés selon les SGBD associés.
Ainsi, multidimensional OLAP (MOLAP) s’utilise lorsque le serveur est jumelé à SGBD
multidimensionnel et relational OLAP (ROLAP) s’utilise pour le couplage à un SGBD
relationnel.
3.
Quant au module client, il s’agit du logiciel d’accès et de manipulation/exploration des
données d’essence multidimensionnelle.
À partir de ces trois composantes, l’architecture OLAP peut se développer selon plusieurs
configurations possibles: la configuration multidimensionnelle, la configuration relationnelle
et la configuration combinée multidimensionnelle/relationnelle.
15
Notons ici le terme data store est utilisé dans le sens de base de données.
Extrait du rapport de recherche produit pour le CRDV, section ‘On-line Analytical Processing’
La configuration multidimensionnelle (cf. figure 1.15), consiste en un serveur MOLAP et une
base de données multidimensionnelle propriétaire. Les données sommaires et agrégées du data
warehouse sont stockées dans la base de données selon le cube multidimensionnel. Les
données sont accédées par le serveur MOLAP directement du module client. Dans la majorité
des cas de cette configuration, le serveur MOLAP utilisé est intégré au SGBD
multidimensionnel. Par conséquent la majorité des SGBD multidimensionnels présentés
antérieurement (cf. tableau 1.3) offrent des serveurs MOLAP intégrés.
Modules client
Data Warehouse/Data Mart
dans une base de données multidimensionnelle
Serveur MOLAP
figure 1.15. Architecture OLAP multidimensionnelle.
La configuration relationnelle (cf. figure 1.16), consiste en un serveur ROLAP qui agit entre
le module client et une base de données relationnelle. Les données du data warehouse sont
stockées dans la base de données sous forme de tables relationnelles et ces données sont
extraites par des requêtes SQL pour être ensuite présentées au client dans une vue
multidimensionnelle. Dans cette configuration, le serveur ROLAP utilisé est indépendant du
SGBD relationnel. Cette structure possède certains avantages. Selon Hettler (1997) “ROLAP
proponents argue that this approach eliminates the needs to store large amounts of data
redundantly. They add that relational databases are the only way to store very large amounts
of data and maintain acceptable retrieval performance”.
Data Warehouse/ Data Mart
dans une base de données
relationnelle
Serveur ROLAP
Vue
multidimensionnelle
des données
Modules client
figure 1.16. Architecture OLAP relationnelle.
Finalement, la configuration combinée multidimensionnelle/relationnelle (cf. figure 1.17),
consiste en un serveur ROLAP et deux bases de données distinctes. Les données sommaires et
agrégées du data warehouse sont stockées dans une première base de données selon la matrice
multidimensionnelle. Ensuite, les données détaillées sont stockées dans une autre base de
données sous forme de tables relationnelles. Les données sommaires sont accédées
directement par le serveur ROLAP tandis que les données détaillées sont présentées au client
par le serveur ROLAP selon une vue multidimensionnelle. Dans cette configuration, le
serveur ROLAP utilisé est indépendant des SGBD et permet l’accès conjoint aux deux types
de structures de données. Cette configuration permet d’accroître les performances
d’interrogation puisque les données agrégées sont déjà précalculées dans la structure
multidimensionnelle (Hettler, 1997).
vue
multidimensionnelle
des données
Data Warehouse/
Data Warehouse/Data Mart
Data Mart dans une
dans une base de données multidimensionnelle
base de données relationnelle Serveur ROLAP
Modules client
figure 1.17. Architecture OLAP combinée (relationnelle/multidimensionnelle).
Les avantages et inconvénients propres à chaque configuration sont en fait liés directement au
type de SGBD utilisé. Ainsi la configuration multidimensionnelle souffrira des désavantages
des SGBD multidimensionnels et ainsi de suite. On peut très bien associer les capacités de la
structure combinée aux caractéristiques des SGBD multidimensionnels étendus.
Annexe C : Formats matriciels supportés par ArcGIS.
Format
Description
ARC Digitized Raster
Graphics (ADRG)
Distributed on CD–ROM by the National Imagery and Mapping Agency
(NIMA). ADRG is geographically referenced using the equal arc-second
raster chart/map (ARC) system in which the globe is divided into 18
latitudinal bands or zones. The data consists of raster images and other
graphics generated by scanning source documents.
Band Interleaved by
Line (ESRI BIL),
Band Interleaved by
Pixel (ESRI BIP),
Band Sequential
(ESRI BSQ)
This format provides a method for reading in and displaying decompressed,
BIL, BIP, and BSQ image data. By creating an ASCII description file that
describes the layout of the image data, black-and-white, grayscale, pseudo
color, and multiband image data can be displayed without translation into a
proprietary format.
Bitmap (BMP),
Device-Independent
Bitmap (DIB) format,
or Microsoft Windows
Bitmap
BMP files are Windows bitmap images. They are usually used to store
pictures or clip art that can be moved between different applications on
Windows platforms.
Compressed ARC
Digitized Raster
Graphics (CADRG)
Distributed on CD–ROM by NIMA. CADRG is geographically referenced
using the ARC system in which the globe is divided into 18 latitudinal bands
or zones. The data consists of raster images and other graphics generated by
scanning source documents. CADRG achieves a nominal compression ratio
of 55:1.
Panchromatic (grayscale) images that have been georeferenced and corrected
Controlled Image Base for distortion due to topographic relief distributed by NIMA. Thus, they are
similar to digital orthophoto quads and have similar applications—such as
(CIB)
serving as a base or backdrop for other data or as a simple map.
Digital Geographic
Information Exchange
Standard (DIGEST)
Arc Standard Raster
Product (ASRP),
UTM/UPS Standard
Raster Product
(USRP)
DIGEST datasets are digital replicas of graphic products designed for
seamless worldwide coverage. ASRP data is transformed into the ARC
system and divides the earth's surface into latitudinal zones. USRP data is
referenced to UTM or UPS coordinate systems. Both are based on the WGS
1984 datum.
Digital Terrain
Elevation Data
(DTED) Level 0, 1, &
2
Created by NIMA (formerly the Defence Mapping Agency—DMA).
ER Mapper
A proprietary raster format from ER Mapper. Produced using the ER Mapper
image processing software.
Graphics Interchange
A proprietary image format that is highly compressed and requires an LZW
Format (GIF)
license from Unisys. Allows high-quality, high-resolution graphics to be
displayed on a variety of graphics hardware and is intended as an exchange
and display mechanism for graphics images.
ERDAS 7.5 GIS
Single-band thematic images produced by the ERDAS 7.5 image processing
software.
ESRI GRID
A proprietary ESRI format that supports 32-bit integer and 32-bit floating
point raster grids. Grids are useful for representing geographic phenomena
that vary continuously over space and for performing spatial modeling and
analysis of flows, trends, and surfaces such as hydrology.
ESRI GRID Stack
Used to reference multiple ESRI GRIDs as a multiband raster dataset. A stack
is stored in a directory structure similar to a grid or coverage.
ESRI GRID Stack file
Used to reference multiple ESRI GRIDs as a multiband raster dataset. A stack
file is a simple text file that stores the path and name of each ESRI GRID
contained within it on a separate line.
ERDAS IMAGINE
Produced using the IMAGINE image processing software created by ERDAS.
IMAGINE files can store both continuous and discrete single-band and
multiband data.
Intergraph Raster
Files:
CIT—Binary data;
COT—Grayscale data
Intergraph's proprietary format for 16-bit imagery (CIT) and unsigned 8-bit
imagery (COT).
Joint Photographic
Experts Group (JPEG)
File Interchange
Format (JFIF)
A standard compression technique for storing full color and grayscale images.
Support for JPEG compression is provided through the JFIF file format.
JPEG 2000
A compression technique especially for maintaining the quality of large
imagery. Allows for a high-compression ratio and fast access to large
amounts of data at any scale.
ERDAS 7.5 LAN
Single- or multiband continuous images produced by the ERDAS 7.5 image
processing software.
Multiresolution
Seamless Image
Database (MrSID)
A compression technique especially for maintaining the quality of large
images. Allows for a high-compression ratio and fast access to large amounts
of data at any scale.
ArcSDE Rasters
Raster data stored within an ArcSDE database.
Tag Image File
Format (TIFF)
(GeoTIFF tags are
supported.)
Widespread use in the desktop publishing world. It serves as an interface to
several scanners and graphic arts packages. TIFF supports black-and-white,
grayscale, pseudo color, and true color images, all of which can be stored in a
compressed or decompressed format.
ERDAS RAW
Provides a method for reading and displaying files that are not otherwise
supported by another format but are formatted in such a way that the
arrangement of the data may be described by a relatively small number of
parameters. By creating an ASCII description file that describes the layout of
the raster data, it can be displayed without translation into a proprietary
format. The format is defined in the ERDAS IMAGINE software.
Portable Network
Graphics (PNG)
Provides a portable, legally unencumbered, well-compressed, well-specified
standard for lossless bitmapped raster files. It is meant as a replacement for
.gif files and supports a large range of bit depths, from monochrome to 64-bit
color. Its features include indexed-color images of up to 256 colors and
effective 100 percent lossless images of up to 16 bits per pixel.
National Image
Transfer Format
(NITF)
Developed by NIMA as a standardized format for images and supporting
data. It has become the standard for digital imagery and imagery-related
products for the United States intelligence community and other departments
and agencies of the U.S. government and is now being adopted as a standard
by civilian organizations (ISO/ANSI) and governments outside the United
States (for example, NATO).
Annexe D : Formats de données supportés par GDAL.
Tiré de GDAL Raster Formats, http://www.gdal.org/formats_list.html, le 31-03-2006.
Long Format Name
Code
Creation Georeferencing Maximum file size
Arc/Info ASCII Grid
AAIGrid
Yes
Yes
2GB
Arc/Info Binary Grid (.adf)
AIG
No
Yes
--
AIRSAR Polarimetric
AIRSAR
No
No
--
Microsoft Windows Device
Independent Bitmap (.bmp)
BMP
Yes
Yes
4GiB
BSB Nautical Chart Format (.kap) BSB
No
Yes
--
VTP Binary Terrain Format (.bt)
BT
Yes
Yes
--
CEOS (Spot for instance)
CEOS
No
No
--
First Generation USGS DOQ
(.doq)
DOQ1
No
Yes
--
DODS / OPeNDAP
DODS
No
Yes
--
New Labelled USGS DOQ (.doq)
DOQ2
No
Yes
--
Military Elevation Data (.dt0, .dt1) DTED
No
Yes
--
ERMapper Compressed Wavelets
(.ecw)
ECW
Yes
Yes
ESRI .hdr Labelled
EHdr
Yes
Yes
No limits
ENVI .hdr Labelled Raster
ENVI
Yes
Yes
No limits
Envisat Image Product (.n1)
Envisat
No
No
--
EOSAT FAST Format
FAST
No
Yes
--
FITS (.fits)
FITS
Yes
No
Graphics Interchange Format (.gif) GIF
Yes
No
Arc/Info Binary Grid (.adf)
GIO
Yes
Yes
GMT Compatible netCDF
GMT
No
Yes
2GB
GRASS Rasters
GRASS
No
Yes
--
TIFF / GeoTIFF (.tif)
GTiff
Yes
Yes
4GiB
Hierarchical Data Format Release 4
HDF4
(HDF4)
Yes
Yes
2GiB
Hierarchical Data Format Release 5
HDF5
(HDF5)
Yes
Yes
2GiB
Erdas Imagine (.img)
HFA
Yes
Yes
No limits
Vexcel MFF2
HKV
Yes
Yes
No limits
Idrisi Raster
RST
Yes
Yes
No limits
2GB
Image Display and Analysis
(WinDisp)
IDA
Yes
Yes
2GB
ILWIS Raster Map (.mpr,.mpl)
ILWIS
Yes
Yes
--
Japanese DEM (.mem)
JDEM
No
Yes
--
JPEG JFIF (.jpg)
JPEG
Yes
Yes
4GiB (max
dimentions
65500x65500)
JPEG2000 (.jp2, .j2k)
JPEG2000
Yes
Yes
2GiB
JPEG2000 (.jp2, .j2k)
JP2KAK
Yes
Yes
No limits
JPEG2000 (.jp2, .j2k)
JP2ECW
Yes
Yes
500MB
JPEG2000 (.jp2, .j2k)
JP2MrSID
Yes
Yes
NOAA Polar Orbiter Level 1b Data
L1B
Set (AVHRR)
No
Yes
--
Erdas 7.x .LAN and .GIS
LAN
No
Yes
2GB
Daylon Leveller Heightfield
Leveller
Yes
No
In Memory Raster
MEM
Yes
Yes
2GiB
Vexcel MFF
MFF
Yes
Yes
No limits
Multi-resolution Seamless Image
Database
MrSID
No
Yes
--
Meteosat Second Generation
MSG
No
Yes
NDF
NLAPS Data
No
Format
Yes
No limits
NITF
NITF
Yes
Yes
4GB
NetCDF
netCDF
No
Yes
2GB
OGDI Bridge
OGDI
No
Yes
--
PCI .aux Labelled
PAux
Yes
No
No limits
PCI Geomatics Database File
PCIDSK
Yes
Yes
No limits
Portable Network Graphics (.png)
PNG
Yes
No
PCRaster (.map)
PCRaster
Yes
Yes
Netpbm (.ppm,.pgm)
PNM
Yes
No
No limits
Swedish Grid RIK (.rik)
RIK
No
Yes
4GB
RadarSat2 XML (product.xml)
RS2
No
Yes
4GB
USGS SDTS DEM (*CATD.DDF) SDTS
No
Yes
--
Raster Matrix Format (*.rsw, .mtw) RMF
Yes
Yes
4GB
SAR CEOS
SAR_CEOS
No
Yes
--
SGI Image Format
SGI
No
Yes
--
USGS ASCII DEM (.dem)
USGSDEM
No
Yes
X11 Pixmap (.xpm)
XPM
Yes
No
--
Annexe E - Formats supportés par FME 2006
(extrait du site Web de Safe Sotware (www.safe.com), le 02/02/06
LEGEND
•
formats supported
-
formats currently not supported
*
requires installation of the application software
+
custom mapping files
*
beta version
**
contact us for availability
E
D
I
T
I
O
N
B
A
S
E
P
R
O
F
E
S
S
I
O
N
A
L
I
N
E
T
S & E
R
R
I
G
R
A
P
H
O
R
A
C
L
E
S
M
A
L
L
W
O
R
L
D
&
D
B
2
S
E
R
V
E
R
S
E
R
V
E
R
L
I
N
U
X
W
I
N
D
O
W
S
FORMAT
R
W
R
W
R
W
R
W
R
W
R
W
R
W
Access Database
(nonspatial) (Windows
only)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
Adobe Illustrator (EPS)
-
-
-
•
-
•
-
•
-
•
-
•
-
•
ADRG Reader (Extra cost
plug-in req'd)
-
-
*
-
*
-
*
-
*
-
*
-
*
-
Aircom ENTERPRISE
(Extra cost plug-in
req'd)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
APIC (Extra cost plug-in
req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
APT
-
-
•
-
•
-
•
-
•
-
•
-
•
-
ARGIS GINA (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
ASCII Tabular
+
+
+
+
+
+
+
+
+
+
+
+
+
+
ASRP Reader (Extra cost
plug-in req'd)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
Autodesk GIS Design
Server (VISION) native
-
-
+
+
+
+
+
+
+
+
+
+
+
+
Autodesk AutoCAD 2004
•
•
•
•
•
•
•
•
•
•
-
-
•
•
Autodesk AutoCAD DWF
•
•
•
•
•
•
•
•
•
•
-
-
•
•
Autodesk AutoCAD
DWG/DXF
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Autodesk GIS Design
Server (VISION) GINA
-
-
•
•
•
•
•
•
•
•
-
-
•
•
E
D
I
T
I
O
N
B
A
S
E
P
R
O
F
E
S
S
I
O
N
A
L
I
N
E
T
S & E
R
R
I
G
R
A
P
H
O
R
A
C
L
E
S
M
A
L
L
W
O
R
L
D
&
D
B
2
S
E
R
V
E
R
S
E
R
V
E
R
L
I
N
U
X
W
I
N
D
O
W
S
FORMAT
R
W
R
W
R
W
R
W
R
W
R
W
R
W
Autodesk Map Object
Reader
-
-
*
-
*
-
*
-
*
-
-
-
*
-
Autodesk MapGuide SDF
(binary) (Windows only)
-
-
*
*
*
*
*
*
*
*
-
-
*
*
Autodesk MapGuide SDL
(Windows only)
•
•
•
•
•
•
•
•
•
•
-
-
•
•
AutoKa Transfer File (FF)
(Extra cost plug-in
req'd)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
BC Electronic
Submission Framework
(ESF) ABR
-
-
•
•
•
•
•
•
•
•
•
•
•
•
BC Electronic
(ESF) FTA GML
-
-
•
•
•
•
•
•
•
•
•
•
•
•
BC Electronic
(ESF) RESULTS GML
-
-
•
•
•
•
•
•
•
•
•
•
•
•
BC MOEP
•
+
•
+
•
+
•
+
•
+
•
+
•
+
BGrund (Extra cost plugin req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
Bitmap Reader/Writer
-
-
•
•
•
•
•
•
•
•
•
•
•
•
C60 Format (AEDSICAD) (Extra cost plugin req'd)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
CADRG Reader (Extra
cost plug-in req'd)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
Card (Extra cost plug-in
req'd)
-
-
-
•
-
•
-
•
-
•
-
-
-
•
CCOGIF Reader (Extra
cost plug-in req'd)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
CCOGIF Writer (Extra
cost plug-in req'd)
-
-
-
+
-
+
-
+
-
+
-
+
-
+
CDED DEM
-
-
•
•
•
•
•
•
•
•
•
•
•
•
CGDEF
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CITS/QLF
-
-
•
•
•
•
•
•
•
•
•
•
•
•
ColorRAW
-
-
•
•
•
•
•
•
•
•
-
-
•
•
CSV (Comma-Separated
Value)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Cubestore MDF
-
-
-
+
-
+
-
+
-
+
-
+
-
+
Danish DSFL
•
-
•
-
•
-
•
-
•
-
•
-
•
-
Danish DSFL XML (XDK)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
Danish UFO
-
-
•
•
•
•
•
•
•
•
•
•
•
•
E
D
I
T
I
O
N
B
A
S
E
P
R
O
F
E
S
S
I
O
N
A
L
I
N
E
T
S & E
R
R
I
G
R
A
P
H
O
R
A
C
L
E
S
M
A
L
L
W
O
R
L
D
&
D
B
2
S
E
R
V
E
R
S
E
R
V
E
R
L
I
N
U
X
W
I
N
D
O
W
S
FORMAT
R
W
R
W
R
W
R
W
R
W
R
W
R
W
dBase III (DBF)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
DES
-
-
•
-
•
-
•
-
•
-
•
-
•
-
Design Files (DGN)
Version 7
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Design Files (DGN)
Version 8
-
-
•
•
•
•
•
•
•
•
-
-
•
•
DFAD (Extra cost plug-in
req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
DFD (MultiGen
Paradigm) (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
DFK (Extra cost plug-in
req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
DMDF (Digital Map Data
Format)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
DTED DEM
-
-
•
•
•
•
•
•
•
•
•
•
•
•
ECW Reader/Writer
-
-
•
•
•
•
•
•
-
-
-
-
•
•
EDBS (Extra cost plug-in
req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
EDIGéO
-
-
•
-
•
-
•
-
•
-
-
-
•
-
ENVI .hdr
-
-
-
-
•
•
•
•
•
•
-
-
•
•
EPS (Encapsulated
PostScript)
-
-
-
•
-
•
-
•
-
•
-
•
-
•
ERDAS IMAGINE Reader
-
-
•
-
•
-
•
-
•
-
•
-
•
-
ESRI .hdr
-
-
•
•
•
•
•
•
•
•
-
-
•
•
ESRI ArcGIS 9.x Map
(.mxd)
-
-
-
-
*
-
*
-
*
-
-
-
*
-
ESRI ArcGIS Binary Grid
(ArcGrid:AIG)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
ESRI ArcInfo Coverage
-
-
-
-
•
•
•
•
•
•
•
•
•
•
ESRI ArcInfo Export
(E00)
•
-
•
•
•
•
•
•
•
•
•
•
•
•
ESRI ArcInfo Generate
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ESRI ArcSDE 9.0/8.x/3.x
-
-
•
-
•
•
•
•
•
•
•
•
•
•
ESRI Ascii Grid
-
-
•
•
•
•
•
•
•
•
•
•
•
•
ESRI Enterprise
GeoDatabase (SDE)
-
-
-
-
*
*
*
*
*
*
-
-
*
*
ESRI Geodatabase
(XML)
-
-
-
-
*
-
*
-
*
-
-
-
*
-
ESRI PC ArcInfo
-
-
-
-
•
-
•
-
•
-
•
-
•
-
ESRI Personal
-
-
*
-
*
*
*
*
*
*
-
-
*
*
E
D
I
T
I
O
N
B
A
S
E
FORMAT
P
R
O
F
E
S
S
I
O
N
A
L
I
N
E
T
S & E
R
R
I
G
R
A
P
H
O
R
A
C
L
E
S
M
A
L
L
W
O
R
L
D
&
D
B
2
S
E
R
V
E
R
S
E
R
V
E
R
L
I
N
U
X
W
I
N
D
O
W
S
R
W
R
W
R
W
R
W
R
W
R
W
R
W
ESRI Shape
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Facet XDR
•
•
•
•
•
•
•
•
•
•
•
•
•
•
FalconView Reader
-
-
*
-
*
-
*
-
*
-
*
-
*
-
Fastgate (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
FME Feature Store (FFS)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
GATE/ADA (Extra cost
plug-in req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
GDF (Extra cost plug-in
req'd)
-
-
•
+
•
+
•
+
•
+
•
+
•
+
GDMS
•
-
•
-
•
-
•
-
•
-
•
-
•
-
GDS (Extra cost plug-in
req'd)
•
-
•
-
•
-
•
-
•
-
•
-
•
-
GE Energy Smallworld
-
-
-
-
-
-
-
-
*
*
-
-
-
-
GE Smallworld
-
-
-
-
**
**
-
-
*
*
-
-
-
-
GenaMap (Extra cost
plug-in req'd)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
GEODESYS StruMap
-
-
•
•
•
•
•
•
•
•
•
•
•
•
GEOgraf (grafbat-ASCII)
(Extra cost plug-in
req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
Geographix CDF
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Geogrid OVL/ASC (PDF
Manual - in German)
(Extra cost plug-in
req'd)
•
•
•
•
•
•
•
•
•
•
-
-
•
•
GEOnet Names Server
(GNS)
•
-
•
-
•
-
•
-
•
-
•
-
•
-
GeoTask
-
-
•
•
•
•
•
•
•
•
-
-
•
•
GeoTIFF
-
-
•
•
•
•
•
•
•
•
-
-
•
•
GICAD (Extra cost plugin req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
GML (OGC Geography
Markup Language)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
Google Earth KML
-
-
•
•
•
•
•
•
•
•
-
-
•
•
GPX
-
-
•
-
•
-
•
-
•
-
•
-
•
-
GRIPS Reader (Extra
cost plug-in req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
GTI GTViewer
-
-
•
•
•
•
•
•
•
•
-
-
•
•
GeoDatabase (Access)
8.3/9.0 (Windows only)
E
D
I
T
I
O
N
B
A
S
E
P
R
O
F
E
S
S
I
O
N
A
L
I
N
E
T
S & E
R
R
I
G
R
A
P
H
O
R
A
C
L
E
S
M
A
L
L
W
O
R
L
D
&
D
B
2
S
E
R
V
E
R
S
E
R
V
E
R
L
I
N
U
X
W
I
N
D
O
W
S
FORMAT
R
W
R
W
R
W
R
W
R
W
R
W
R
W
GTI/RDB (Extra cost
plug-in req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
IBM DB2 Spatial
-
-
•
-
•
-
•
•
•
•
•
•
•
•
IBM DB2 Tables (nonspatial)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
IBM IFF (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
IDRISI
•
•
•
•
•
•
•
•
•
•
-
-
•
•
Incremental Update
Format (IUF)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
Intergraph FRAMME
-
-
+
+
+
+
+
+
+
+
+
+
+
+
Intergraph FRAMME SEF
(Standard Exchange
Format) Writer (Extra
cost plug-in req'd)
-
-
-
+
-
+
-
+
-
+
-
+
-
+
Intergraph G/Technology
(Extra cost plug-in
req'd)
-
-
+
+
+
+
+
+
+
+
-
-
+
+
Intergraph GeoMedia
Access Warehouse
(Windows only)
-
-
•
*
•
*
•
*
•
*
-
-
•
*
Intergraph GeoMedia
SQL Server Warehouse
-
-
•
-
•
•
•
•
•
•
•
•
•
•
Intergraph MGE
-
-
•
•
•
•
•
•
•
•
-
-
•
•
INTERLIS (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
ISO 8211
-
-
•
-
•
-
•
-
•
-
•
-
•
-
JPEG
-
-
•
•
•
•
•
•
•
•
-
-
•
•
JPEG 2000
Reader/Writer
-
-
•
•
•
•
•
•
-
-
-
-
•
•
KLT Atlas ASCII (Extra
cost plug-in req'd)
-
-
•
•
•
•
•
•
•
•
•
-
•
•
Landmark ZGF (Zycor
Graphics File)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
Landonline (LandXML)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
Laser-Scan IFF
-
-
•
•
•
•
•
•
•
•
•
•
•
•
LaserScan Gothic (Extra
cost plug-in req'd)
-
-
•
•
•
•
•
•
•
•
•
-
•
•
Latitude DMF (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
Leica GSI (Extra cost
plug-in req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
Leica IDEX
•
•
•
•
•
•
•
•
•
•
-
-
•
•
E
D
I
T
I
O
N
B
A
S
E
P
R
O
F
E
S
S
I
O
N
A
L
I
N
E
T
S & E
R
R
I
G
R
A
P
H
O
R
A
C
L
E
S
M
A
L
L
W
O
R
L
D
&
D
B
2
S
E
R
V
E
R
S
E
R
V
E
R
L
I
N
U
X
W
I
N
D
O
W
S
FORMAT
R
W
R
W
R
W
R
W
R
W
R
W
R
W
MapGIS (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
MapGIS ASCII (Extra
cost plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
MapInfo MID/MIF
•
•
•
•
•
•
•
•
•
•
•
•
•
•
MapInfo SpatialWare on
SQL Server (Extra cost
plug-in req'd)
-
-
**
**
**
**
**
**
**
**
-
-
** **
MapInfo TAB
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Mercator MCF
-
-
•
•
•
•
•
•
•
•
•
•
•
•
Microsoft Excel (.xls)
(Windows only)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
Microsoft SQL Server
Database (Attributes
Only)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
MicroStation
Geographics V7/V8
-
-
•
•
•
•
•
•
•
•
-
-
•
•
MrSID Reader
-
-
•
-
•
-
•
-
•
-
•
-
•
-
MySQL Database
(Attributes Only)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
MySQL Spatial Database
-
-
•
•
•
•
•
•
•
•
-
-
•
•
MZK (PDF Manual - in
German) (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
Nen1878 (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
NetCDF Reader
-
-
*
-
*
-
*
-
*
-
*
-
*
-
NITF Reader
-
-
*
-
*
-
*
-
*
-
*
-
*
-
NTF
-
-
•
-
•
-
•
-
•
-
•
-
•
-
NTX Caris (Note: Does
not include the ability to
handle NTX Soundings)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
NTX Soundings (Note:
This is not a special
reader/writer but rather
a license for it enables
more functionality in the
NTX reader/writer that
FME has.) (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
Numeric Raw
-
-
•
•
•
•
•
•
•
•
-
-
•
•
ODBC 2.x Database
(Attributes Only)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
E
D
I
T
I
O
N
B
A
S
E
P
R
O
F
E
S
S
I
O
N
A
L
I
N
E
T
S & E
R
R
I
G
R
A
P
H
O
R
A
C
L
E
S
M
A
L
L
W
O
R
L
D
&
D
B
2
S
E
R
V
E
R
S
E
R
V
E
R
L
I
N
U
X
W
I
N
D
O
W
S
FORMAT
R
W
R
W
R
W
R
W
R
W
R
W
R
W
ODBC 3.x Database
(Attributes Only)
(Windows only)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
OGDI
-
-
•
-
•
-
•
-
•
-
•
-
•
-
ONORM (PDF manual in German) (Extra cost
plug-in req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
Oracle 10g/9i/8i Spatial
Object
-
-
•
-
•
-
•
•
•
•
•
•
•
•
Oracle 10g/9i/8i Tables
(nonspatial)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
Oracle Spatial Relational
-
-
•
•
•
•
•
•
•
•
•
•
•
•
Oracle SQL Loader ASCII
-
•
-
•
-
•
-
•
-
•
-
•
-
•
OS MasterMap (DNF)
(GML-2)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
PenMetrics GRD
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PHOCUS PHODAT
•
+
•
+
•
+
•
+
•
+
•
+
•
+
PLANET (Extra cost plugin req'd)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
PostGIS Database
-
-
•
•
•
•
•
•
•
•
•
•
•
•
PostgreSQL Database
-
-
•
•
•
•
•
•
•
•
•
•
•
•
Raster Image (PNG)
-
•
-
•
-
•
-
•
-
•
-
•
-
•
REGIS
-
-
•
•
•
•
•
•
•
•
•
•
•
•
rmDATA MXF (PDF
Manual - in German)
(Extra cost plug-in
req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
S-57
-
-
•
-
•
-
•
-
•
-
•
-
•
-
SAIF
•
+
•
+
•
+
•
+
•
+
•
+
•
+
SDTS
•
-
•
-
•
-
•
-
•
-
•
-
•
-
SEG Y (Extra cost plugin req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
SEG-P1
*
-
*
-
*
-
*
-
*
-
*
-
*
-
Shockwave Flash
-
•
-
•
-
•
-
•
-
•
-
-
-
•
SLF
-
-
•
-
•
-
•
-
•
-
•
-
•
-
Smallworld (Spatial Biz)
(Extra cost plug-in
req'd)
-
-
-
-
-
-
•
•
•
•
-
-
•
•
SOTF
-
-
+
-
+
-
+
-
+
-
+
-
+
-
SPANS (Extra cost plugin req'd)
•
•
•
•
•
•
•
•
•
•
-
-
•
•
E
D
I
T
I
O
N
B
A
S
E
P
R
O
F
E
S
S
I
O
N
A
L
I
N
E
T
S & E
R
R
I
G
R
A
P
H
O
R
A
C
L
E
S
M
A
L
L
W
O
R
L
D
&
D
B
2
S
E
R
V
E
R
S
E
R
V
E
R
L
I
N
U
X
W
I
N
D
O
W
S
FORMAT
R
W
R
W
R
W
R
W
R
W
R
W
R
W
SQD (Extra cost plug-in
req'd)
-
-
•
•
•
•
•
•
•
•
-
-
•
•
STAR INFORMATIC (CX)
(Extra cost plug-in
req'd)
-
-
*
*
*
*
*
*
*
*
-
-
*
*
SuperMap (Extra cost
plug-in req'd)
•
•
•
•
•
•
•
•
•
•
-
-
•
•
SVG (Scalable Vector
Graphics)
-
-
-
•
-
•
-
•
-
•
-
•
-
•
Swedish KF85
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Swedish MASIK
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Text File
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Text Line
•
•
•
•
•
•
•
•
•
•
•
•
•
•
TIGER/Line
•
+
•
+
•
+
•
+
•
+
•
+
•
+
TOBIN TDRBM II Data
Distribution Writer
-
-
-
*
-
*
-
*
-
*
-
*
-
*
TOP10GML
-
-
•
-
•
-
•
-
•
-
•
-
•
-
USGS DEM (Digital
Elevation Model)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
USGS DLG
•
-
•
-
•
-
•
-
•
-
•
-
•
-
VALIS/ASC (PDF Manual
- in German) (Extra cost
plug-in req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
Vertical Mapper Grid
(NGrid)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
VML
-
•
-
•
-
•
-
•
-
•
-
•
-
•
VPF Reader
-
-
•
-
•
-
•
-
•
-
•
-
•
-
VPF Writer (Extra cost
plug-in req'd)
-
-
-
+
-
+
-
+
-
+
-
+
-
+
VRML
-
•
-
•
-
•
-
•
-
•
-
•
-
•
Web Feature Service
(WFS)
-
-
•
-
•
-
•
-
•
-
•
-
•
-
WLDGE (Extra cost plugin req'd)
-
-
•
-
•
-
•
-
•
-
-
-
•
-
XML
-
-
•
•
•
•
•
•
•
•
•
•
•
•
XPM Reader/Writer
-
-
*
*
*
*
*
*
*
*
*
*
*
*
Z-MAP (ASCII)
-
-
•
•
•
•
•
•
•
•
•
•
•
•
Annexe F – Formats supportés par Spatialdirect
(extrait du site Web de Safe Sotware (www.safe.com), le 02/02/06
Format
Source Download Upload
Data
Format
Format
Access Database (nonspatial)
•
-
-
AutoCAD DWF
-
•
-
AutoCAD DWG (R12)
-
•
•
AutoCAD DWG (R14)
-
•
•
AutoCAD DWG (R2000)
-
•
•
AutoCAD DWG (R2004)
-
•
-
AutoCAD DXF (R12)
-
•
•
AutoCAD DXF (R14)
-
•
•
AutoCAD DXF (R2000)
-
•
•
AutoCAD DXF (R2004)
-
•
-
Autodesk MapGuide SDF (binary)
•
-
-
Caris NTX
-
•
-
CubeWerx MDF
-
•
-
EPS (Encapsulated PS)
-
•
-
ESRI Arc/Info Coverage
•
•
•
ESRI Arc/Info E00
-
•
•
ESRI Arc/Info Generate
-
•
•
ESRI ArcSDE 9.0/8.x/3.x
•
-
-
ESRI Personal Geodatabase (Access)
•
•
•
ESRI Enterprise GeoDatabase (SDE)
•
-
-
ESRI Shape
•
•
•
FME Feature Store File (FSS)
•
•
•
Geographix CDF
-
•
•
GeoTask
•
-
-
GIF Image
-
•
-
GML 2 (Safe Schema)
-
-
•
IBM DB2 Spatial
•
-
-
IBM DB2 Tables (non-spatial)
•
-
-
IEPS (Illustrator EPS)
-
•
-
Intergraph GeoMedia Access Warehouse
•
•
•
Intergraph GeoMedia SQL Server
Warehouse
•
-
-
Landmark Z-MAP
-
•
-
MapGuide SDL
-
•
•
MapInfo MID/MIF
•
•
•
MapInfo SpatialWare on SQL Server
(extra cost plugin req'd')
•
-
-
MapInfo TAB
•
•
•
Microstation Design V7
-
•
-
Microstation Design V8
-
•
-
MySQL
•
-
-
OGC GML (ESRI Profile)
-
•
-
OGC GML (Fixed Schema)
-
•
-
OGC GML (FME Profile)
-
•
-
OGC WFS
•
•
-
OGDI
•
-
-
Oracle 10g/9i/8i Spatial Object
•
-
-
Oracle 10g/9i/8i Tables (nonspatial)
•
-
-
Oracle Spatial Relational
•
-
-
PenMetrics GRD
-
•
•
PNG (Downloadable)
-
•
-
PostGIS Database
•
-
-
Scalable Vector Graphics (SVG)
-
•
-
SeisWorks
-
•
-
VML
-
•
-
VRML
-
•
-
Zycor (merged)
-
•
-
Zycor (multi)
-
•
-
Annexe G – Synthèse des opérateurs de
généralisation cartographique présenté par Martel
[1999]