Table des matières
télécharger 70.41 Kb.
|
  
13/04/2012  Table des matières1Phase 1 : Portrait de la situation actuelle des ressources minières en Estrie 4 Généralités à développer 4 iciiiii 4 1.1Acquisition des données géospatiales 4 1.2Acquisition des données conventionnelles 4 1.3Conversion en shapefiles 4 1.4Analyse et correction des données – volet attributs (sous-schéma 1.1) 4 1.4.1Évaluation des attributs des couches 4 1.4.2Évaluation des attributs des couches 5 1.5Sélection des attributs et validation avec le partenaire 5 1.6Analyse et correction des données – volet entités (sous-schéma 1.2) 5 1.6.1Comparaison des fichiers et vérification des redondances 5 1.6.2Création d'un tableau synthèse 5 1.6.3Vérification des entités contenues dans le tableau synthèse 5 1.6.4Choix des entités et suppression des entités redondantes 5 1.7Évaluation de la précision et correction (sous-schéma 1.3) 6 1.8Uniformisation des attributs (sous-schéma 1.4) 6 1.8.1Création d’un attribut unique 6 1.8.2Uniformisation des attributs 7 1.8.3Rassemblement des données similaires 7 2Phase 2 : Évaluation du potentiel minier en Estrie 7 2.1Acquisition des données 8 2.2Géoréférencement des cartes 8 2.3Création des Shapefiles 8 2.4Numérisation et saisie des données 9 2.5Estimation des volumes d’agrégats disponibles (sous-schéma 2.1) 9 2.5.1Acquisition du MNS 9 2.5.2Extraction du MNT à partir du MNS 9 2.5.3Transformation du MNT en Réseau de triangles irréguliers (TIN : triangulated irregular network) 9 2.5.4Calcul de la superficie en tenant compte du relief 9 2.5.5Jointure entre la couche de type Multipatch et la couche originale 10 2.5.6Calcul du volume d’agrégats disponibles 10 2.5.7Séparation des shapefiles selon le matériau 10 3Phase 3 : Création de la base de données (BD) 10 3.1Conception du modèle conceptuel de données (MCD) 11 3.2Conception du modèle logique de données (MLD) 12 3.3Validation auprès de la CRÉ 13 3.4Création du modèle physique 13 3.5Intégration d'un échantillon représentatif des données 13 3.6Phase de tests de la base de données (sous-schéma 3.1) 13 3.6.1Définition des objectifs des tests 13 3.6.2Préparation des requêtes de tests 13 3.6.3 Réalisation des tests 14 3.6.4Création d'un tableau de résultats 14 3.7Correction des problèmes identifiés 14 3.8Intégration de l'ensemble des données 14 4Bibliographie 15 Dans le but d’obtenir un portrait de la situation actuelle des sablières, gravières et carrières de l’Estrie qui permettra, à terme, une utilisation plus rationnelle de ces ressources, le Groupe d’Analyse Minière de l’Estrie (GAME) a développé une méthodologie. Celle-ci réunira d’une part toutes les informations disponibles et d’autre part, déterminera le potentiel en matériaux granulaires. Le tout sera intégré dans une Base de Données à Référence Spatiale (BDRS). Ce document décrit donc de façon détaillée l’approche mise en place par le GAME afin de réaliser le mandat qui lui a été confié. 1Phase 1 : Portrait de la situation actuelle des ressources minières en EstrieGénéralités à développericiiiii1.1Acquisition des données géospatialesPour être en mesure d’élaborer la base de données, il nous faut acquérir les différentes données géospatiales concernant les sablières, gravières et carrières situées sur le territoire de l’Estrie. Celles-ci proviennent du Ministère des Ressources Naturelles et de la Faune (MRNF), du Ministère du Développement Durable, de l’Environnement et des Parcs (MDDEP) ainsi que des Municipalités Régionales de Comté (MRC). Des données auxiliaires qui seront utilisées lors d'étapes ultérieures seront aussi acquises, comme une mosaïque d'orthophotos qui proviendra de la cartothèque. 1.2Acquisition des données conventionnellesAfin d'obtenir un maximum d'informations sur la situation actuelle des ressources minières en Estrie, nous ne négligerons aucune donnée potentiellement utile. Ainsi, nous ferons l’acquisition des données non géospatiales, soit les données sous forme de documents de texte ou de chiffrier électronique. Les informations recueillies lors des suivis environnementaux réalisés par le MDDEP en est un exemple. 1.3Conversion en shapefilesLes données qui ne sont pas de type géospatial seront converties en shapefiles afin de pouvoir les visualiser et les intégrer à la BDRS par la suite. Pour les données sous forme de chiffriers électroniques, leur conversion se fera faite avec ArcGIS, avec la fonction Display XY Data. 1.4Analyse et correction des données – volet attributs (sous-schéma 1.1)Tout d’abord, le sous-schéma 1.1 présente notre méthode pour analyser les attributs des couches. Nous croyons qu’il est effectivement important d’importer dans la BDRS finale des données qui possèdent les attributs les plus importants. 1.4.1Évaluation des attributs des couchesCette partie de sous-schéma concerne les attributs descriptifs des couches. Elle consistera premièrement à rechercher la signification de chaque attribut présent pour chaque couche. Nous nous servirons des métadonnées et de la littérature fournies pour effectuer cette tâche. Un tableau synthèse sera créé dans le logiciel Excel. Les informations contenues dans ce document seront la signification des champs, ainsi que l’état (rempli ou non) de chacun d’eux. De cette manière, nous serons en mesure de sélectionner les meilleurs attributs à garder. 1.4.2Évaluation des attributs des couches1.5Sélection des attributs et validation avec le partenaireÀ partir du tableau synthèse développé à l’étape d’analyse et de correction des données, les attributs jugés les plus pertinents seront sélectionnés. Suite à cette sélection, une validation sera faite auprès du partenaire du projet. Cette étape est primordiale si l'on veut obtenir les résultats qui rencontreront les attentes du partenaire de manière optimale. Des modifications seront effectuées en accord avec les recommandations du partenaire, s’il y a lieu. 1.6Analyse et correction des données – volet entités (sous-schéma 1.2)Les étapes suivantes sont suivies afin d’apporter des correctifs nécessaires dans les données à incorporer. Pour ce faire, les shapefiles disponibles seront confrontés lorsqu’il y a superposition, afin de déterminer quelles sont les entités et les informations à garder. 1.6.1Comparaison des fichiers et vérification des redondancesCette étape consiste à comparer visuellement les différents shapefiles fournis et créés sur les carrières, gravières et sablières. Ceci est fait afin de vérifier si des couches se superposent et de déterminer s’il existe entre les différentes couches, des doublons par rapport aux entités. 1.6.2Création d'un tableau synthèseLorsque des entités de différentes couches se superposent, les informations de ces entités seront reportées dans un tableau Excel. On y retrouvera les noms des couches ainsi que l’ensemble des informations attributaires de chaque entité. 1.6.3Vérification des entités contenues dans le tableau synthèseCette étape consiste à examiner les attributs des entités ciblés dans le tableau synthèse. Celle-ci sera donc très importante puisqu’il faudra déterminer laquelle des couches contient le plus d’informations pertinentes pour l’entité en question. 1.6.4Choix des entités et suppression des entités redondantesLorsque la vérification sera terminée, il suffira de garder l’entité qui donne le plus d'informations et de fait, celle qui contient le moins d'informations sera supprimée de sa table. Finalement, ces modifications seront enregistrées afin d’avoir de nouvelles couches avec des entités non-redondantes. 1.7Évaluation de la précision et correction (sous-schéma 1.3)Les étapes qui sont présentées dans cette partie permettront d’améliorer la précision des données. Pour analyser la précision des données, nous superposerons la couche à la mosaïque d’orthophotographies présentée précédemment. 1.7.1 Analyse de la précision des entités En s’aidant de la mosaïque, nous calculerons une distance entre chaque élément ponctuel et le centre de la mine. La grande précision des orthophotographies utilisées permettra de calculer des distances. Un nouveau champ sera ajouté dans la table d’attributs pour y insérer les distances mesurées, afin de pouvoir ensuite calculer une moyenne et un écart-type pour la couche entière. 1.7.2 Correction des entités imprécises Suite à cela, les éléments ponctuels qui sont à une distance de plus de deux écarts-types seront repositionnés au centre véritable de la mine. Ces différentes étapes seront à refaire pour chaque couche géospatiale. 1.8Uniformisation des attributs (sous-schéma 1.4)Les étapes présentées dans ce sous-schéma permettront d’uniformiser les données, plus particulièrement leurs attributs. Il s’agit de la dernière étape de modification des données avant l’importation dans la BDRS finale. À ce niveau-ci, les attributs qui seront uniformisés sont ceux qui ont été approuvés par le partenaire du projet. 1.8.1Création d’un attribut uniquePremièrement, il faudra s’assurer que chaque couche géospatiale ait un attribut permettant d’avoir un numéro unique pour chaque élément de la couche. Pour certaines données que nous possédons, cet attribut est déjà présent, tandis que pour d’autres il n’y est pas et il faudra le créer. Parmi celles dont l’attribut est déjà présent, une modification sera peut-être à effectuer pour que l’attribut soit conforme aux autres couches. Cette étape est primordiale afin que les jointures entre les couches s’effectuent correctement. À noter que l’attribut unique présenté ici ne correspond pas nécessairement à la clé primaire. 1.8.2Uniformisation des attributsLes champs seront uniformisés afin qu’ils soient similaires lors de l’intégration dans la BDRS. Les modifications se feront principalement sur le nom des champs, le format, la grandeur et la précision. Tout d’abord, les attributs qui contiennent des informations similaires dans les différentes couches porteront les mêmes noms. Nous utiliserons aussi un nom court qui sera le plus explicite et représentatif possible. Ensuite, il sera important d’uniformiser le format, la grandeur et la précision des champs. Pour le format, on parle par exemple des formats de texte, d’entiers courts, d’entiers longs, etc. La grandeur est plutôt relative au nombre de caractères maximal pour un attribut de type texte, alors que la précision s’avère être le nombre de chiffres possible après la virgule dans le cas d’un nombre. À la suite de discussions entre les membres de l’équipe et par expérience de projets antérieurs, les choix suivants ont été faits :
1.8.3Rassemblement des données similairesFinalement, toutes les couches qui portent sur le même thème seront rassemblées en une seule. Cette étape est nécessaire, car nous avons reçu des données de plusieurs sources différentes. 2Phase 2 : Évaluation du potentiel minier en EstrieCette phase consiste en l’atteinte du deuxième objectif du mandat, qui est d’intégrer à la BD des données relatives au potentiel minier de l’Estrie. Comparativement à la phase 1, les données sont surfaciques et non ponctuelles. 2.1Acquisition des donnéesLes données concernant le potentiel minier proviennent d’une étude effectuée à la fin des années 80 par M. André Brazeau, du Bureau de l’exploration géologique du Québec (MRNF). Ces données sont en format PDF et elles devront être géoréférencées, numérisées et saisies, afin d’être intégrables à la BDRS. De plus, la couche du réseau routier national (RRN), disponible sur le portail géospatial de Ressources Naturelles Canada, sera acquise pour le géoréférencement. 2.2Géoréférencement des cartesLes cartes en format PDF doivent tout d’abord être converties en format BMP à l’aide de GIMP 2.6, logiciel gratuit. Le format BMP a été préféré au JPG pour son rendu de meilleure qualité. Le géoréférencement sera effectué à l’aide de l’outil Georeferencing d’ArcGIS. Les points de contrôles utilisés proviendront de la couche du RRN, puisque ce sont des points précis et facilement repérables. Pour chaque carte, un total de 8 points de contrôles uniformément distribués sur le territoire couvert par la carte sera utilisé, le tout dans le but d’avoir une Erreur Quadratique Résiduelle Moyenne (RMSE) inférieure à 1 m. 2.3Création des ShapefilesUn shapefile gabarit contenant les attributs suivants (Tableau X) sera créé. Par la suite, une couche par carte sera créée à partir de ce gabarit.
2.4Numérisation et saisie des donnéesLes dépôts présents sur chaque carte seront numérisés et les informations associées à chacun des dépôts seront saisies dans les tables attributaires. L’outil d’édition d’ArcGIS sera utilisé. 2.5Estimation des volumes d’agrégats disponibles (sous-schéma 2.1)La méthode présentée ici utilise comme données entrantes les fichiers vectoriels (shapefiles) numérisées à l’étape 2.4, en plus du Modèle Numérique de Surface (MNS). Elle permet d’estimer les volumes d’agrégats minimaux et maximaux disponibles pour chacun des sites. 2.5.1Acquisition du MNSLe MNS provient de la cartothèque de l’Université de Sherbrooke. Le modèle couvre entièrement la région de l’Estrie et ce, avec une résolution spatiale et altimétrique de 2 mètres. 2.5.2Extraction du MNT à partir du MNSComme le MNS inclut la végétation et les constructions anthropiques, une transformation devra être faite afin d’obtenir un Modèle numérique de terrain (MNT) qui lui, représente l’élévation du sol. À continuer 2.5.3Transformation du MNT en Réseau de triangles irréguliers (TIN : triangulated irregular network)À l’aide de l’outil Raster to TIN contenu dans l’extension 3D Analyst du logiciel ArcGIS, une transformation du MNT en TIN sera effectuée. Dans ce logiciel, la méthode de triangulation supportée est la triangulation de Delaunay. La particularité de cette méthode est qu’elle maximise la création de triangles avec des angles intérieurs minimaux, ce qui empêche le plus possible la création de longs triangles minces. Les TIN sont typiquement utilisés pour la modélisation de haute précision dans des applications d’ingénierie. Ils sont utiles puisqu’ils permettent les calculs d’aires planimétriques, de surfaces et de volumes (Centre de ressource ArcGIS, 2010). Cette étape est nécessaire afin d’être en mesure d’effectuer la prochaine étape. 2.5.4Calcul de la superficie en tenant compte du reliefLes polygones originaux sont en deux dimensions, ce qui sous-estime la superficie réelle. Pour tenir compte du relief, nous devons les transformer en format Multipatch. Une entité multipatch est un objet SIG qui stocke un ensemble de faces pour représenter la limite d'un objet 3D sous la forme d'une ligne unique dans une base de données (Centre de ressource ArcGIS, 2010). Pour effectuer cette opération, l’outil Interpolate Polygon to Multipatch contenu dans l’extension 3D Analyst est utilisé. La surface d’entrée est le TIN créé à l’étape 2.5.3, la couche vectorielle d’entrée est la couche shapefile numérisée à l’étape 2.4, alors que le champ créé (Surface Area Field) sera nommé Superficie_3D. Le résultat de cette opération est une couche Multipatch contenant tous les champs de la couche originale, en plus d’un champ avec la superficie de chaque polygone en 3 dimensions. Par défaut, la superficie est calculée en km². Pour permettre un calcul de volume en m³ à l’étape 2.5.6, nous modifions l’unité de superficie pour le m² (Calculate geometry sur le champ en question). 2.5.5Jointure entre la couche de type Multipatch et la couche originaleEn utilisant l’outil Join and relates du menu contextuel associé à la couche shapefile originale, on effectue une jointure avec la couche de type Multipatch. Le champ utilisé pour la jointure sera celui contenant l’identifiant unique qui se trouve dans les deux couches. À partir de ce moment, la couche de type Multipatch ne sera plus utilisée. 2.5.6Calcul du volume d’agrégats disponiblesÀ cette étape, nous calculerons les volumes d’agrégats disponibles pour chaque site et les intégrerons dans les champs Volume_min et Volume_max de la couche shapefile originale. Pour y parvenir, nous devons activer le mode édition sur cette couche. On ouvre ensuite la table attributaire, on sélectionne la colonne désirée (Volume_min ou Volume_max) et dans le menu contextuel de celle-ci, on utilise la fonction Field Calculator. Cette fonction permet de calculer les valeurs qui seront contenues dans ces colonnes. Par exemple, pour le champ Volume_min, la formule utilisée est : Superficie_3D * Epaisseur_min. 2.5.7Séparation des shapefiles selon le matériauTous les shapefiles représentant le même type de matériau seront réunis dans une même couche. Il y aura donc deux couches : Sabliere_Estrie et Graviere_Estrie. À la suite de cette étape, la couche de potentiel est prête à être intégrée à la BD finale. 3Phase 3 : Création de la base de données (BD)La BD que le GAME implantera sera de type orienté-objet et sera réalisée conformément aux normes de représentation ULM (Unified Modeling Language ou langage de modélisation unifié). Cela permettra de représenter la structure de la BD, via les différents niveaux de modélisation qui seront développés, de manière claire et précise. Les différents niveaux sont : conceptuel, logique et physique. Le Système de Gestion de Base de Données (SGBD) utilisé sera de type relationnel-objet spatial. Cela permettra, au niveau logique, le stockage d’informations géographiques et de données de télédétection, de même que l’utilisation d’opérateurs et de fonctions spatiales dans le langage SQL. Il sera ainsi possible de retrouver une information sur la base de caractéristiques géométriques telles que les coordonnées ou la dimension. Cela permettra aussi d’utiliser l’indexation spatiale, ce qui augmente la vitesse d’exécution des requêtes. De plus, ce type de SGBD possède une capacité de stockage plus importante au niveau physique. Ces capacités s’ajoutent aux fonctionnalités de base (créer, manipuler, qui inclut : ajouter, modifier, supprimer et interroger) permises par les SGBD conventionnels. Le GAME a choisi d’utiliser PostGIS comme SGBD, qui est en fait le SGBD relationnel-objet PostgreSQL, auquel est ajouté des capacités de gestion de données géospatiales. Le logiciel d’administration, qui permettra la gestion et la manipulation de PostGIS, sélectionné par le GAME est PgAdmin III. Finalement, l’interface logicielle utilisée pour la visualisation des données stockées sur PostGIS sera Quantum GIS. Plusieurs raisons ont motivé ces choix. Premièrement, PostgreSQL, et indirectement PostGIS, possèdent une solide réputation quant à la fiabilité, l’intégrité et l’exactitude des données, en plus que leur mise en œuvre soit conforme aux normes ANSI-SQL. Cette réputation leur a d’ailleurs valu d’être primés par les utilisateurs et de gagner la reconnaissance de l’industrie. Deuxièmement, en plus de contenir des outils d’interfaces utilisateur, un support topologique et des interfaces de programmation d’application, PostGIS permet la validation de données, la transformation de coordonnées, et plus encore. Toutes ces caractéristiques permettront certainement d’obtenir de meilleurs résultats en moins de temps. Troisièmement, PostGIS, pgAdmin III et Quantum GIS constituent un système de base de données libre (open source), c’est-à-dire gratuit. En effet, comme les licences associées aux SGBD propriétaires peuvent être hors de portée des utilisateurs aux moyens financiers limités, comme les municipalités de petite taille, ces choix permettront donc l’accès à tous. 3.1Conception du modèle conceptuel de données (MCD)Le MCD est la formalisation, sous la forme d’un schéma, de la structure et de la signification des informations décrivant les objets et des associations les liant, tout en faisant abstraction des solutions et contraintes techniques informatiques liées à l'implantation d’une BD. Cette formalisation utilise des concepts qui sont près de la perception qu'ont les usagers des données et dans un langage descriptif le plus simple et le plus logique possible. Ainsi, ce modèle est composé d'entités, de classes d’entités, d'attributs, d’identifiants, d’associations et de cardinalités. Les entités représentent les objets du monde réel tel qu'une sablière et lorsque rangées en catégories, forment des classes d‘entités. Les attributs ou propriétés sont des informations descriptives des entités, comme coordonnées qui contiendrait les coordonnées géographiques où se situe l’entité correspondante. Comme chaque entité doit être unique, elle doit être identifiable par un attribut unique : c’est l’identifiant (ou la clé primaire). Les associations représentent les relations entre deux ou plusieurs entités des différentes classes d’entités, comme la relation contient entre une MRC et une sablière. Les associations sont caractérisées par leurs cardinalités et leurs dimensions. Les cardinalités correspondent au minimum et au maximum d’entités possibles reliées à une classe d’entité par l’association. La dimension correspond au nombre d’entités impliquées dans l’association; elle peut être réflexive (entité reliée à elle-même), binaire (entre 2 entités), ternaire (entre 3 entités) ou N-aire (entre n entités). Parmi les nombreux formalismes existants pour les MCD, le GAME a choisi le modèle entité-association étendu (Enhanced Entity-Relationship (EER) Model), pour ces capacités à représenter de manière plus précise les propriétés et les contraintes associées aux données géospatiales (Elmasri & Navathe, 2006). 3.2Conception du modèle logique de données (MLD)Cette étape consiste à passer du MCD à un schéma relationnel de données. Le MLD est le niveau logique du MCD, il est aussi appelé le modèle relationnel de données et est le modèle qui sera intégré dans le SGBD. Ce processus s’effectue en 9 étapes distinctes, afin d’alléger le texte, celles-ci ne seront pas décrites. Elles peuvent toutefois être consultées aux pages 224 à 235 de l’ouvrage Fundamentals of Database Systems (Elmasri & Navathe, 2006). Dans ce modèle, l’unique type d’objet présent est la table. Le MLD est régis par quatre règles d’intégrité qui sont : l’unicité des clés, la contrainte de référence, la contrainte d’entité et la contrainte de domaine. L’unicité des clés vise à éliminer la redondance de tuples au sein d’une relation. La contrainte de référence se base sur le fait que les associations sont référencées dans les relations ou bien créées dans de nouvelles relations. Il existe donc des relations référançantes et des relations référencées. Une clé supplémentaire est alors ajoutée dans la relation référançante; il s’agit de la clé étrangère. L’insertion d’un tuple dans une relation référançante impose que les valeurs des clés étrangères existent. Finalement, elle voit à ce que la suppression d’une relation référencée soit refusée si elle intervient dans une relation référançante. La contrainte d’entité rend impossible d’attribuer la valeur NULL à l’attribut identifié comme clé primaire. Les clés étrangères peuvent toutefois avoir NULL comme valeur de façon temporaire. La contrainte de domaine vérifie la validité des valeurs introduites lors des insertions ou des mises à jour (Germain, 2011). 3.3Validation auprès de la CRÉUne fois l’architecture de la base de données réalisée, elle sera soumise à la CRÉ afin de confirmer que la structure établie soit conforme aux attentes et besoins des utilisateurs potentiels. 3.4Création du modèle physiqueCette étape correspond à l’implantation des tables dans la BD PostGIS et s’effectuera à l’aide du logiciel d’administration pgAdminIII. La première étape est d’installer PostGreSQL puisque celui-ci est préalable à l’installation de PostGIS. À partir du MLD, les différentes tables, les attributs, le type de données accepté (char, integer, etc.) pour chacun des attributs ainsi que les clés primaires et étrangères seront créés. 3.5Intégration d'un échantillon représentatif des donnéesÀ cette étape, seule une partie des données sera intégrée à PostGIS afin d’être en mesure d’effectuer des tests visant à vérifier la robustesse de l’architecture mise en place à l’étape précédente. Les données sélectionnées devront couvrir l’ensemble des possibilités d’interactions entre les différentes tables. Cette étape est primordiale afin de ne pas investir inutilement du temps alors que le MLD devra être modifié. Les données géospatiales en format shapefiles seront intégrées à PostGIS par l’intermédiaire de Quantum GIS. Pour ce faire, l’outil SPIT sera utilisé, il faut dans un premier temps se connecter à PostGreSQL puis identifier les attributs contenant la géométrie et la clé primaire. 3.6Phase de tests de la base de données (sous-schéma 3.1)3.6.1Définition des objectifs des testsLors de cette étape, nous allons définir l’ensemble des fonctionnalités à tester dans la base de données. Il faudra donc identifier les problèmes qui pourraient survenir lors de l’utilisation de celle-ci. On parle ici des problèmes avec les différentes clés primaires, les liens entre les tables ainsi que le fonctionnement de l’indexation des données. 3.6.2Préparation des requêtes de testsPour chacun des objectifs définis, il faudra écrire des requêtes afin de vérifier l’ensemble des problèmes potentiels. Les requêtes devront donc tester chacune des tables présentes dans la BD. 3.6.3 Réalisation des testsCette étape consiste à effectuer l’ensemble des requêtes définies à l’étape précédente. Le résultat de chacune des requêtes devra être pris en note. Nous avons également prévu qu’en cas où il y aurait un problème avec une requête, il est possible de revenir à l’étape précédente afin de modifier celle-ci. 3.6.4Création d'un tableau de résultatsLors de cette dernière étape, nous allons créer un tableau Excel permettant de résumer l’ensemble des résultats obtenus lors des tests. Celui-ci nous permettra d’identifier les différents problèmes rencontrés ainsi que les modifications requises à la base de données. 3.7Correction des problèmes identifiésLes problèmes identifiés lors de la phase de tests seront analysés afin d’en connaître la provenance et être en mesure d’évaluer les différentes options disponibles pour y remédier. Les modifications nécessaires seront apportées au MLD en fonction des options les plus efficaces et les plus rapides. 3.8Intégration de l'ensemble des donnéesUne fois le modèle physique opérationnel et stable, la totalité des données sera intégrée à PostGIS en procédant de la même manière que lors de l’intégration partielle des données. Au terme de cette étape, la base de données sera prête à être livrée à la CRÉ et notre mandat sera rempli. 4BibliographieElmasri, R., & Navathe, S. B. (2006). Fundamentals of Database Systems. Boston, Addison Wesley. Germain, M. (2011, avril 5). GMQ 302 Conception et exploitation de bases de données à référence spatiale. Cours n°1 – bases de données : rappel des concepts fondamentaux. Sherbrooke. http://www.esri.com/library/whitepapers/pdfs/multipatch-geometry-type.pdf http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00q90000004v000000 http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/What_is_a_TIN_surface/006000000001000000/ http://www.esri.com/library/whitepapers/pdfs/multipatch-geometry-type.pdf Conception du modèle logique de données (MLD)
|
similaire:
 | | ||
| | ||
 | | ||
| | ||
| |