Introduction à la Géomatique (partie 2/4)

## Objectifs et prérequis **Objectifs** À l’issue de ce chapitre, l’élève sera capable de : 1. Réaliser l’analyse des besoins fonctionnels et non fonctionnels d’une base de données spatiale (BDS) destinée à un projet de géomatique au Cameroun. 2. Passer du modèle conceptuel (entité‑association) au modèle logique relationnel en appliquant les règles de normalisation et les bonnes pratiques de modélisation. 3. Concevoir le schéma physique d’une BDS (choix du SGBD, types de champs, indexation, partitionnement) en tenant compte des contraintes de stockage et de performance. 4. Intégrer des données hétérogènes (vecteur, raster, attributs) provenant de sources diverses (cadastre, imagerie satellitaire, relevés terrain) en respectant les systèmes de référence de coordonnées et les normes de qualité. 5. Rédiger le langage de définition de données (DDL) correspondant et exécuter les premières requêtes de contrôle (SELECT, INSERT, UPDATE) sur un SGBD spatial (PostgreSQL/PostGIS ou Spatialite). 6. Identifier les erreurs fréquentes de conception et d’intégration et appliquer les règles de sécurité et d’hygiène liées à la manipulation des données géospatiales. **Prérequis** - Notions de systèmes d’information géographique (SIG) : couches, attributs, systèmes de référence de coordonnées (SRC). - Bases des bases de données relationnelles : tables, clés primaires/étrangères, jointures, normalisation (1NF, 2NF, 3NF). - Connaissances élémentaires en informatique : systèmes d’exploitation Windows/Linux, utilisation d’un éditeur de texte, notions de ligne de commande. - Maîtrise du vocabulaire technique de base du géomatique (géoréférencement, projection, échelle, résolution). --- ## Introduction contextualisée La géomatique occupe une place centrale dans le développement territorial du Cameroun : suivi du couvert forestier, gestion du cadastre urbain, planification des infrastructures routières, surveillance des ressources en eau, etc. Les projets nationaux (Programme d’Investissement Forestier, Plan National d’Aménagement du Territoire, Programme de Gestion Intégrée des Bassins Versants) s’appuient de plus en plus sur des bases de données spatiales robustes, capables d’accueillir des volumes de données croissants provenant de capteurs terrestres, de drones et de satellites d’observation (Landsat, Sentinel‑2). Dans ce contexte, la capacité à concevoir une BDS de l’analyse des besoins jusqu’à la mise en production constitue une compétence clé pour les techniciens supérieurs en géomatique. Ce chapitre présente, de façon progressive, les étapes de la conception (analyse, modélisation conceptuelle, logique et physique), les activités d’intégration des données hétérogènes et la modélisation entité‑association, en s’appuyant sur des exemples concrets issus de la pratique camerounaise (gestion du parc forestier de la région du Sud, suivi de l’urbanisation de Yaoundé, suivi des points de prélèvement d’eau dans le bassin du Sanaga). --- ## I. Conception des BDS : de l’analyse à la base de données ### A. Analyse des besoins fonctionnels et non fonctionnels 1. **Recueil des besoins** - Entretiens avec les utilisateurs finaux (agents forestiers, géomètres, planificateurs urbains). - Élaboration d’un cahier des charges fonctionnel (CF) listant les opérations attendues : requêtes spatiales (intersection, proximité), mises à jour périodiques, génération de cartes thématiques, export vers des formats standards (GeoJSON, Shapefile). - Identification des contraintes non fonctionnelles : volume de données attendu (ex. 5 000 parcelles forestières, 200 000 points de prélèvement), temps de réponse maximal (<2 s pour une requête d’intersection), exigences de sauvegarde et de récupération après sinistre, conformité aux normes nationales (Arrêté n° 001/MINEPAT du 12 janvier 2020 sur la gestion des données géographiques). 2. **Modélisation des besoins** - Diagrammes de cas d’utilisation (UML) pour visualiser les acteurs et les scénarios. - Matrice de traçabilité reliant chaque besoin fonctionnel à un ou plusieurs éléments du futur modèle de données. ### B. Étapes de la conception : de l’analyse au schéma logique | Étape | Objectif principal | Livrable typique | |-------|-------------------|------------------| | 1. Analyse des besoins | Définir ce que le système doit faire | Cahier des charges fonctionnel | | 2. Modélisation conceptuelle | représenter les entités du réel et leurs associations | Modèle Entité‑Association (MEA) | | 3. Modélisation logique | traduire le MEA en schéma relationnel normalisé | Modèle logique (tables, clés, contraintes) | | 4. Modélisation physique | choisir le SGBD, définir les types de stockage, indexation | Schéma physique (DDL, paramètres de stockage) | | 5. Implémentation & tests | créer la base, charger des jeux de données, vérifier les performances | Base de données opérationnelle, jeux de tests | ### C. Normes et standards applicables - **ISO 19100 série** (géomatique – cadre conceptuel) : définit les notions d’objet géographique, de typologie, de métadonnées. - **OGC Simple Features Specification** (SFS) : géométrie vectorielle (points, lignes, polygones) et opérations spatiales de base. - **ISO 19115** : métadonnées géographiques (obligatoire pour tout jeu de données soumis au MINEDUB). - **SQL/MM Spatial** : extension du SQL pour gérer les types géométriques dans les SGBD relationnels. ### D. Exemple chiffré : dimensionnement d’une BDS pour la gestion du parc forestier régional Supposons un projet de suivi du parc forestier de la région du Sud comprenant : - **5 000 parcelles forestières** (polygones). - Chaque parcelle possède 12 attributs (code parcelle, essence dominante, âge moyen, volume de bois, altitude moyenne, pente, exposition, date de dernier inventaire, source des données, précision, responsable, remarque). - **200 000 points d’observation** (faune, flore, points de prélèvement de sol) avec 8 attributs chacun. - **Imagerie raster** : 10 scènes Sentinel‑2 (10 m de résolution) couvrant 5 000 km², chaque scène occupe ~1,2 Go (compressé). **Estimation du stockage vectoriel** : - Polygone moyen : 150 sommets → 150 × 2 × 8 octets (double précision) ≈ 2,4 Ko par géométrie. - 5 000 polygones → 2,4 Ko × 5000 ≈ 12 Mo. - Attributs : moyenne 50 octets par enregistrement → 5 000 × 12 × 50 ≈ 3 Mo. - Points : 200 000 × (2 × 8 + 8 × 50) ≈ 200 000 × (16 + 400) ≈ 83 Mo. - Total vectoriel ≈ **98 Mo**. **Estimation du stockage raster** : 10 × 1,2 Go = **12 Go**. **Total prévisionnel** : **≈ 12,1 Go** + marge de 30 % pour index et sauvegardes → **≈ 16 Go**. Ce dimensionnement justifie le choix d’un SGBD serveur (PostgreSQL/PostGIS) plutôt qu’une base embarquée (Spatialite) pour garantir des performances d’écriture/lecture adéquates. ### E. Procédure pas à pas : de l’analyse au DDL 1. **Recueil des besoins** → rédaction du CF. 2. **Modélisation conceptuelle** → dessin du MEA (voir section III). 3. **Transformation logique** : - Chaque entité devient une table. - Chaque attribut devient un champ ; le type dépend de la nature (texte, entier, réel, date, géométrie). - Les associations deviennent des clés étrangères ou des tables d’association (pour les relations N:N). 4. **Normalisation** : vérifier 1NF (atomicité), 2NF (dépendance fonctionnelle complète), 3NF (absence de dépendance transitive). 5. **Choix du SGBD** : PostgreSQL 15 + extension PostGIS 3.3. 6. **Écriture du DDL** (exemple simplifié) : ```sql CREATE SCHEMA parc_forestier; CREATE TABLE parc_forestier.parcelle ( id_parcelle SERIAL PRIMARY KEY, code VARCHAR(15) NOT NULL UNIQUE, essence VARCHAR(30), age_moyen INTEGER, volume_bois REAL, altitude_moy REAL, pente REAL, exposition VARCHAR(10), date_invent DATE, source VARCHAR(50), precision_m REAL, responsable VARCHAR(100), remarque TEXT, geom GEOMETRY(Polygon, 4326) ); CREATE INDEX idx_parcelle_geom ON parc_forestier.parcelle USING GIST (geom); CREATE TABLE parc_forestier.observation ( id_obs SERIAL PRIMARY KEY, id_parcelle INTEGER REFERENCES parc_forestier.parcelle(id_parcelle), espece VARCHAR(40), date_obs DATE, hauteur REAL, remarque TEXT, geom GEOMETRY(Point, 4326) ); CREATE INDEX idx_observation_geom ON parc_forestier.observation USING GIST (geom); ``` 7. **Chargement des données** : utilisation de `shp2pgsql` pour les shapefiles, `raster2pgsql` pour les rasters, ou `ogr2ogr` (GDAL) pour les formats variés. 8. **Tests de requêtes** : ```sql -- Nombre de parcelles contenant une essence donnée SELECT COUNT(*) FROM parc_forestier.parcelle WHERE essence = 'Ayous' AND ST_Intersects(geom, (SELECT geom FROM parc_forestier.observation WHERE espece = 'Panthera pardus' LIMIT 1)); ``` > **> À retenir** : La phase d’analyse des besoins doit produire un cahier des charges fonctionnel signé par les utilisateurs avant toute modélisation. > **> À retenir** : Le choix du SGBD doit être guidé par le volume prévisionnel, les exigences de performance et la conformité aux normes OGC/ISO. > **> À retenir** : Chaque entité du MEA se traduit par une table ; chaque association 1:N devient une clé étrangère, tandis qu’une association N:N nécessite une table d’association avec deux clés étrangères. --- ## II. Activités d’intégration ### A. Intégration des données hétérogènes Les projets géomatiques au Cameroun doivent souvent combiner : - **Données vecteur** : limites administratives (shapefile MINATD), réseaux routiers (OpenStreetMap), parcelles cadastrales (DGCC). - **Données raster** : images satellitaires (Landsat 8, Sentinel‑2), modèles numériques de terrain (MNT) dérivés de SRTM ou ASTER. - **Données attributaires** : tableaux Excel ou CSV provenant d’enquêtes socio‑économiques, de relevés de terrain (GPS). L’intégration repose sur trois piliers : 1. **Homogénéisation des systèmes de référence de coordonnées (SRC)** : toutes les couches doivent être reprojetées dans un même SRC, généralement le **UTM zone 32N (WGS 84)** pour la partie occidentale du Cameroun et le **UTM zone 33N** pour la partie orientale. 2. **Nettoyage et validation** : suppression des doublons, correction des géométries invalides (auto‑intersections, fermetures manquantes), harmonisation des codages d’attributs (ex. unification des codes d’essence forestière selon la nomenclature FAO). 3. **Enrichissement** : jointure spatiale (ex. attribution de la moyenne d’altitude d’un MNT à chaque parcelle) ou attributaire (ex. ajout du code région à partir d’une table de correspondance). ### B. Transformations de coordonnées, reprojection et géoréférencement - **Reprojection** : opération mathématique qui convertit les coordonnées d’un SRC à un autre en utilisant des paramètres de datum, de projection et d’échelle. Exemple : passer du **WGS 84 (lat/long)** au **UTM 32N** avec les formules de transverse Mercator. - **Géoréférencement** : assignation de coordonnées réelles à une image raster non référencée (ex. photographie aérienne ancienne) à l’aide de points de contrôle connus (GCP). La méthode des moindres carrés est généralement employée pour calculer les paramètres de transformation affine ou polynomiale. > **> À retenir** : Toute donnée raster importée doit être accompagnée de son fichier de métadonnées (.xml ou .tif avec tags GeoTIFF) indiquant le SRC, la résolution et la date d’acquisition. ### C. Qualité des données : exactitude, complétude, cohérence | Critère | Définition | Méthode de contrôle | |---------|------------|---------------------| | Exactitude (positionnelle) | Écart entre la position mesurée et la vraie position | Comparaison avec des points GNSS de précision sub‑métrique (ex. Trimble R10) ; calcul du RMSE. | | Complétude | Proportion d’objets attendus réellement présents | Comptage des entités dans le jeu de données vs. référentiel (ex. nombre de villages attendus selon le RGPH). | | Cohérence logique | Respect des règles métier (ex. une parcelle ne peut appartenir à deux communes) | Requêtes SQL de vérification (ex. `SELECT id FROM parcelle GROUP BY id HAVING COUNT(DISTINCT commune) > 1`). | | Cohérence topologique | Adjacence et connectivité correctes (pas de overlaps non autorisés) | Outils de validation topologique (QGIS → Vector ► Geometry Tools ► Check Validity). | ### D. Outils couramment utilisés dans l’atelier camerounais | Fonction | Logiciel / Outil | Licence | |----------|------------------|---------| | SIG desktop | QGIS 3.34 LTS | Open Source (GPL) | | SIG desktop commercial | ArcGIS Pro 3.2 | Propriétaire (ESRI) | | SGBD spatial | PostgreSQL 15 + PostGIS 3.3 | Open Source | | ETL / intégration | FME Desktop 2023 | Licence commerciale (version académique disponible) | | Traitement raster | GDAL/OGR 3.8 | Open Source | | Gestion de projets | Redmine ou GitLab | Open Source | | Visualisation web | Leaflet + GeoServer | Open Source | ### E. Exemple d’atelier : intégration de données cadastrales et d’imagerie satellitaire pour le suivi de l’urbanisation à Yaoundé **Contexte** : La Communauté Urbaine de Yaoundé (CUY) souhaite détecter l’expansion informelle des quartiers périphériques entre 2018 et 2023. **Étapes** : 1. **Acquisition des données** - Cadastral 2018 : shapefile fourni par la DGCC (Système de référence : WGS 84 / UTM 32N). - Images Sentinel‑2 : niveaux L2A (10 m) pour les périodes janvier 2018 et décembre 2023, téléchargées via Copernicus Open Access Hub. 2. **Prétraitement raster** - Réprojection des images en UTM 32N (GDAL `gdalwarp -t_srs EPSG:32632`). - Calcul de l’indice de végétation normalisé (NDVI) : `NDVI = (NIR - RED) / (NIR + RED)`. 3. **Vectorisation des zones bâties** - Seuil NDVI < 0,2 → création d’un masque binaire (raster). - Conversion du masque en polygones (`gdal_polygonize.py`). - Filtrage des polygones < 30 m² (élimination du bruit). 4. **Jointure spatiale avec le cadastral** - Requête PostGIS : ```sql UPDATE cadastral.parcelle p SET construit_2023 = CASE WHEN ST_Intersects(p.geom, b.geom) THEN TRUE ELSE FALSE END FROM urbain.bati_2023 b; ``` 5. **Analyse de l’évolution** - Calcul du pourcentage de parcelles nouvellement bâties : `(SUM(construit_2023) / COUNT(*)) * 100`. - Résultat observé : 22 % de hausse du bâti entre 2018 et 2023, concentré dans les arrondissements de Ngoa‑Ekelle et Mfoundi. > **> À retenir** : Lors de la vectorisation d’un raster, il est essentiel de choisir un seuil adapté au contexte (ex. NDVI < 0,2 pour détecter le bâti en zone tropicale) et de valider le résultat sur un échantillon de terrain. > **> À retenir** : La jointure spatiale doit être effectuée sur des géométries indexées (index GIST) afin de garantir des temps de réponse acceptables même sur plusieurs centaines de milliers d’enregistrements. --- ## III. Modélisation conceptuelle : Modèle entité‑association ### A. Notions de base - **Entité** : objet du monde réel doté d’une identité propre et caractérisé par un ensemble d’attributs (ex. *Parcelle*, *Ouvrage hydraulique*, *Point de prélèvement*). - **Association** : lien entre deux ou plusieurs entités qui représente une relation d’affaires (ex. *Parcelle* **est traversée par** *Canal*, *Point de prélèvement* **est situé dans** *Bassin*). - **Attribut** : propriété décrivant une entité ou une association (ex. *surface* pour *Parcelle*, *débit maximal* pour *Canal*). - **Identificateur (clé primaire)** : attribut ou combinaison d’attributs qui identifie de façon unique chaque instance d’une entité. - **Cardinalité** : nombre d’instances d’une entité pouvant être associées à une instance d’une autre entité (ex. 1 : N, N : N, 1 : 1). ### B. Notations usuelles | Notation | Représentation | Usage fréquent au Cameroun | |----------|----------------|----------------------------| | **Merise** | Boîtes pour les entités, losanges pour les associations, traits avec cardinalités (ex. 1,1 – 0,N) | Enseignement technique (BTS, DUT) | | **UML Class Diagram** | Boîtes avec compartiments (nom, attributs, méthodes), traits avec multiplicités (ex. 1..*, 0..1) | Projets informatiques, conformité aux standards OGC | | **Chen (ER)** | Entités en rectangles, attributs en ovales, losanges pour les relations | Moins utilisé en formation technique actuelle | ### C. Passage du modèle conceptuel au modèle logique 1. **Transformation des entités** → chaque entité devient une relation (table). 2. **Transformation des attributs** → chaque attribut devient un champ de la table ; le type est choisi selon la nature (texte, nombre, date, géométrie). 3. **Transformation des associations** : - **1 : N** → la clé primaire de l’entité du côté « 1 » devient une clé étrangère dans la table du côté « N ». - **N : N** → création d’une table d’association contenant les clés primaires des deux entités comme clés étrangères composites ; éventuellement des attributs propres à l’association. - **1 : 1** → possibilité de fusionner les deux tables ou d’ajouter une clé étrangère unique dans l’une des tables. 4. **Application des règles d’intégrité** : contraintes NOT NULL, UNIQUE, CHECK, FOREIGN KEY. 5. **Normalisation** : vérifier que le schéma logique respecte au moins la 3NF afin d’éviter les redondances et les anomalies de mise à jour. ### D. Exemple concret : modèle pour la gestion des ressources en eau du bassin du Sanaga **Entités identifiées** | Entité | Attributs principaux | Identificateur | |--------|----------------------|----------------| | Bassin | nom_bassin, superficie_km2, altitude_moyenne | id_bassin (SERIAL) | | Cours_eau | nom_cours, longueur_km, débit_moyen_m3s | id_cours (SERIAL) | | Ouvrage | type (barrage, prise, déversoir), cote_nivelée_m, année_construction | id_ouvrage (SERIAL) | | Point_prelevement | date_heure, débit_instantané_m3s, qualité (turbidité, pH) | id_pt (SERIAL) | | Utilisateur | nom, type (agricole, industriel, domestique), volume_alloué_m3/j | id_user (SERIAL) | **Associations** | Association | Cardinalité | Description | |-------------|-------------|-------------| | Bassin **contient** Cours_eau | 1 : N | Un bassin comporte plusieurs cours d’eau. | | Cours_eau **traversé par** Ouvrage | N : N | Un cours d’eau peut être traversé par plusieurs ouvrages et un ouvrage peut traverser plusieurs cours d’eau (ex. dérivation). | | Ouvrage **alimente** Point_prelevement | 1 : N | Un ouvrage peut alimenter plusieurs points de prélèvement. | | Point_prelevement **utilisé par** Utilisateur | N : N | Un point peut servir plusieurs utilisateurs et un utilisateur peut prélever à plusieurs points. | **Passage au logique (extrait DDL)** ```sql CREATE SCHEMA ressources_eau; CREATE TABLE ressources_eau.bassin ( id_bassin SERIAL PRIMARY KEY, nom_bassin VARCHAR(60) NOT NULL, superficie_km2 REAL, altitude_moyenne REAL ); CREATE TABLE ressources_eau.cours_eau ( id_cours SERIAL PRIMARY KEY, nom_cours VARCHAR(60) NOT NULL, longueur_km REAL, debit_moyen_m3s REAL, id_bassin INTEGER NOT NULL REFERENCES ressources_eau.bassin(id_bassin) ); CREATE TABLE ressources_eau.ouvrage ( id_ouvrage SERIAL PRIMARY KEY, type VARCHAR(30) NOT NULL, cote_nivellee_m REAL, annee_const INTEGER, -- table d'association N:N avec cours_eau sera créée ci-dessous ); -- Table d'association cours_eau <-> ouvrage CREATE TABLE ressources_eau.cours_eau_ouvrage ( id_cours INTEGER NOT NULL REFERENCES ressources_eau.cours_eau(id_cours), id_ouvrage INTEGER NOT NULL REFERENCES ressources_eau.ouvrage(id_ouvrage), PRIMARY KEY (id_cours, id_ouvrage) ); CREATE TABLE ressources_eau.point_prelevement ( id_pt SERIAL PRIMARY KEY, date_heure TIMESTAMP NOT NULL, debit_instantane_m3s REAL, turbidite NTU, pH REAL, id_ouvrage INTEGER NOT NULL REFERENCES ressources_eau.ouvrage(id_ouvrage) ); CREATE TABLE ressources_eau.utilisateur ( id_user SERIAL PRIMARY KEY, nom VARCHAR(100) NOT NULL, type VARCHAR(20) NOT NULL, volume_alloue_m3_j REAL ); -- Table d'association point_prelevement <-> utilisateur CREATE TABLE ressources_eau.point_prelevement_utilisateur ( id_pt INTEGER NOT NULL REFERENCES ressources_eau.point_prelevement(id_pt), id_user INTEGER NOT NULL REFERENCES ressources_eau.utilisateur(id_user), PRIMARY KEY (id_pt, id_user) ); ``` > **> À retenir** : Dans un modèle entité‑association, chaque association 1:N se traduit par une clé étrangère placée dans la table du côté « N ». > **> À retenir** : Les associations N:N nécessitent toujours une table d’association dont la clé primaire est la combinaison des deux clés étrangères. ### E. Tableau récapitulatif des cardinalités et de leur traduction logique | Cardinalité conceptuelle | Exemple (entité A – entité B) | Traduction logique (tables) | |--------------------------|------------------------------|-----------------------------| | 1 : 1 | Un **Chef de projet** dirige exactement un **Projet** | Clé étrangère unique dans l’une des deux tables (ou fusion). | | 1 : N | Un **Bassin** contient plusieurs **Cours d’eau** | Clé étrangère du bassin dans la table cours_eau. | | N : 1 | Plusieurs **Points de prélèvement** sont alimentés par un même **Ouvrage** | Même cas que 1 : N (clé étrangère du côté N). | | N : N | Un **Ouvrage** traverse plusieurs **Cours d’eau** et un cours d’eau peut être traversé par plusieurs ouvrages | Table d’association avec deux clés étrangères (PK composée). | | 0 : 1 (optionnel) | Un **Utilisateur** peut avoir zéro ou un **Contrat** spécial | Clé étrangère nullable dans la table Utilisateur. | | 0 : N | Un **Projet** peut avoir zéro ou plusieurs **Rapports** | Clé étrangère du projet dans la table Rapport (NULL autorisé). | > **> À retenir** : La présence d’un zéro dans la cardinalité indique que la relation est optionnelle ; la clé étrangère correspondante doit être déclarée `NULL` autorisée. --- ## Synthèse du chapitre - **Analyse des besoins** : recueil fonctionnel & non fonctionnel, rédaction du cahier des charges, matrice de traçabilité. - **Modélisation conceptuelle** : représentation entité‑association (Merise/UML), identification des entités, attributs, associations, cardinalités. - **Modélisation logique** : passage au schéma relationnel (tables, clés primaires/étrangères, normalisation 1NF‑3NF). - **Modélisation physique** : choix du SGBD (PostgreSQL/PostGIS), définition des types de champs, indexation spatiale (GIST), dimensionnement du stockage. - **Intégration des données** : homogénéisation des SRC, nettoyage, validation qualité (exactitude, complétude, cohérence), utilisation d’outils (QGIS, GDAL/OGR, FME, PostGIS). - **Exemples pratiques** : dimensionnement d’une BDS forestière (≈ 16 Go), intégration cadastrale + imagerie pour suivi de l’urbanisation à Yaoundé, modèle de gestion des ressources en eau du bassin du Sanaga. - **Bonnes pratiques** : utilisation systématique des métadonnées ISO 19115, sauvegarde régulière, contrôle de version des scripts SQL, formation des utilisateurs aux requêtes spatiales de base. --- ## Glossaire | Terme | Définition | |-------|------------| | **Entité** | Objet du monde réel doté d’une identité propre, caractérisé par un ensemble d’attributs. | | **Association** | Lien entre deux ou plusieurs entités représentant une relation d’affaires. | | **Attribut** | Propriété décrivant une entité ou une association (ex. nom, quantité, date). | | **Identificateur (clé primaire)** | Attribut ou combinaison d’attributs qui identifie de façon unique chaque instance d’une entité. | | **Cardinalité** | Nombre d’instances d’une entité pouvant être associées à une instance d’une autre entité (ex. 1 : N, N : N). | | **Modèle conceptuel** | Représentation abstrait des données (entités, associations) indépendante de toute implémentation technique. | | **Modèle logique** | Schéma relationnel dérivé du modèle conceptuel, incluant tables, clés, contraintes et normalisation. | | **Modèle physique** | Définition détaillée du stockage (types de champs, index, partitionnement) dans un SGBD donné. | | **SRC (Système de Référence de Coordonnées)** | Cadre qui définit comment les coordonnées géoréférencées se rapportent à la Terre (ex. WGS 84 / UTM 32N). | | **PostGIS** | Extension spatiale de PostgreSQL permettant le stockage, l’indexation et l’interrogation de données géométriques. | | **GIST** | Méthode d’indexation PostgreSQL adaptée aux données géométriques et aux recherches de proximité. | | **ETL** | Processus d’Extraction, Transformation, Chargement utilisé pour intégrer des données hétérogènes dans une base cible. | | **GeoTIFF** | Format raster incluant des métadonnées géographiques (projection, datum, résolution) directement dans le fichier TIFF. | | **NDVI** | Indice de Végétation Normalisé, calculé comme (NIR‑RED)/(NIR+RED), utilisé pour distinguer végétation et surfaces bâties. | | **RMSE** | Root Mean Square Error, mesure de l’exactitude positionnelle d’un jeu de données géospatiales. | | **Schema** | Namespace logique dans une base de données regroupant un ensemble d’objets (tables, vues, fonctions). | | **Contrainte d’intégrité** | Règle déclarée dans le SGBD (NOT NULL, UNIQUE, CHECK, FOREIGN KEY) garantissant la cohérence des données. | --- ## Exercices d'application corrigés ### Exercice 1 – Conception d’une BDS pour le suivi des infrastructures routières régionales **Énoncé** Le Ministère des Travaux Publics du Cameroun souhaite mettre en place une base de données spatiale pour gérer le réseau routier national (routes nationales, régionales et départementales). Chaque tronçon routier possède : un identifiant unique, une catégorie (Nationale, Régionale, Départementale), une longueur (en km), un type de revêtement (Bitume, Gravillon, Terre), l’année de dernière réhabilitation, et la géométrie (linéaire). Les tronçons sont regroupés par **section d’entretien** (une section regroupe plusieurs tronçons contigus appartenant à la même catégorie et gérée par une même unité d’entretien). Chaque unité d’entretien possède un code, un nom, une localisation (point GPS) et un responsable. 1. Dessinez le modèle conceptuel (entité‑association) correspondant. 2. Transformez-le en modèle logique (liste des tables avec leurs attributs, types et clés). 3. Écrivez le DDL PostgreSQL/PostGIS pour créer les tables, y compris les index spatiaux nécessaires. **Corrigé** **1. Modèle conceptuel** - Entité **Tronçon** : attributs `{id_tronçon, catégorie, longueur_km, revêtement, année_rehab, geom}` - Entité **Section** : attributs `{id_section, nom_section}` - Entité **Unité_Entretien** : attributs `{code_unité, nom_unité, localisation_geom, responsable}` Associations : - **Tronçon** **appartient à** **Section** (1 : N) - **Section** **gérée par** **Unité_Entretien** (1 : N) **2. Modèle logique** | Table | Attributs (type) | Clé primaire | Clés étrangères | |-------|------------------|--------------|-----------------| | tronçon | id_tronçon SERIAL, catégorie VARCHAR(20), longueur_km REAL, revêtement VARCHAR(15), année_rehab INTEGER, geom GEOMETRY(Linestring, 4326) | id_tronçon | id_section → section(id_section) | | section | id_section SERIAL, nom_section VARCHAR(50) | id_section | id_unité → unité_entretien(id_unité) | | unité_entretien | id_unité SERIAL, code_unité VARCHAR(10) UNIQUE, nom_unité VARCHAR(50), localisation_geom GEOMETRY(Point, 4326), responsable VARCHAR(100) | id_unité | – | **3. DDL** ```sql CREATE SCHEMA voirie; CREATE TABLE voirie.unite_entretien ( id_unite SERIAL PRIMARY KEY, code_unite VARCHAR(10) NOT NULL UNIQUE, nom_unite VARCHAR(50) NOT NULL, localisation GEOMETRY(Point, 4326) NOT NULL, responsable VARCHAR(100) NOT NULL ); CREATE TABLE voirie.section ( id_section SERIAL PRIMARY KEY, nom_section VARCHAR(50) NOT NULL, id_unite INTEGER NOT NULL REFERENCES voirie.unite_entretien(id_unite) ); CREATE TABLE voirie.troncon ( id_troncon SERIAL PRIMARY KEY, categorie VARCHAR(20) NOT NULL, longueur_km REAL NOT NULL, revêtement VARCHAR(15) NOT NULL, annee_rehab INTEGER, geom GEOMETRY(Linestring, 4326) NOT NULL, id_section INTEGER NOT NULL REFERENCES voirie.section(id_section) ); -- Index spatiaux CREATE INDEX idx_troncon_geom ON voirie.troncon USING GIST (geom); CREATE INDEX idx_unite_loc ON voirie.unite_entretien USING GIST (localisation); ``` > **Vérification** : Un tronçon appartient à exactement une section (`id_section` NOT NULL). Une section est gérée par une seule unité d’entretien (`id_unite` NOT NULL). Les index GIST permettent des recherches d’intersection ou de proximité rapides sur les linéaires routiers et les points d’unité d’entretien. --- ### Exercice 2 – Intégration de données de couverture forestière et d’altitude **Énoncé** Vous disposez de deux jeux de données : - Un shapefile `foret_2022.shp` contenant les polygones de couverture forestière (attribut `code_foret`, `essence_dominante`, `annee_inventaire`). Le shapefile est en projection **WGS 84 (EPSG:4326)**. - Un MNT raster `mnt_srtm_30m.tif` couvrant la même zone, en projection **UTM 32N (EPSG:32632)**, résolution 30 m, valeurs d’altitude en mètres. Vous devez produire une nouvelle couche vectorielle `foret_avec_altitude.shp` où chaque polygone forestier possède un nouvel attribut `altitude_moyenne` représentant la moyenne d’altitude du MNT à l’intérieur du polygone. 1. Décrivez les étapes de retraitement nécessaires (reprojection, nettoyage, calcul de la moyenne zonal). 2. Indiquez les commandes GDAL/OGR (ou équivalent QGIS) à exécuter, en supposant que vous travaillez sous Linux avec les outils GDAL 3.8 installés. 3. Donnez le résultat attendu sous forme de tableau d’exemple (trois polygones avec leurs attributs). **Corrigé** **1. Étapes de retraitement** a. **Reprojection du shapefile** : convertir `foret_2022.shp` de EPSG:4326 vers EPSG:32632 afin que les deux jeux partagent le même SRC. b. **Vérification et nettoyage des géométries** : supprimer les polygones vides ou auto‑intersectants (`ogrinfo -sql "SELECT * FROM foret_2022 WHERE ST_IsEmpty(geom) = 0"`). c. **Calcul de la moyenne zonal** : utiliser `gdal_rasterize` pour rasteriser les polygones sur une grille identique au MNT, puis `gdal_calc.py` ou `gdaldem` pour extraire la statistique moyenne ; toutefois la méthode la plus directe est `gdal_stats` avec l’option `-z` ou l’utilisation de `rasterstats` (Python). En ligne de commande pure GDAL, on peut procéder ainsi : - Rasteriser le shapefile en un masque binaire où chaque polygone obtient un valeur d’ID unique (`gdal_rasterize -a id_foret -l foret_2022_reproj -of GTiD foret_id.tif mnt_srtm_30m.tif`). - Utiliser `gdal_calc.py` avec une expression qui, pour chaque pixel, multiplie la valeur d’altitude par le masque d’ID et accumule les sommes et les comptages par ID (nécessite un script Python). - Pour simplifier, on recommande l’utilisation de `rasterstats` (package Python) ou la fonction **Zonal Statistics** de QGIS. Dans le cadre de cet exercice, nous présenterons la solution QGIS (mais équivalente en ligne de commande avec `rasterstats`). **2. Commandes (QGIS Processing via console)** ```bash # 1. Reprojection du shapefile ogr2ogr -t_srs EPSG:32632 foret_2022_reproj.shp foret_2022.shp # 2. Nettoyage (suppression des géométries nulles) ogr2ogr -sql "SELECT * FROM foret_2022_reproj WHERE ST_IsEmpty(geom) = 0" foret_2022_clean.shp foret_2022_reproj.shp # 3. Calcul de la moyenne zonal avec l'outil rasterstats (Python) # On suppose que le package rasterstats est installé. python3 - <<EOF import rasterstats import geopandas as p import rasterio as rio # Charger les données foret = p.read_file('foret_2022_clean.shp') with rio.open('mnt_srtm_30m.tif') as src: mnt = src.read(1) affine = src.transform # Calcul statistique zonal stats = rasterstats.zonal_stats(foret.geometry, mnt, affine=affine, stats=['mean'], nodata=src.nodata) # Ajouter les résultats au GeoDataFrame for i, s in enumerate(stats): foret.loc[i, 'altitude_moyenne'] = s['mean'] # Sauvegarder foret.to_file('foret_avec_altitude.shp') EOF ``` **3. Résultat attendu (exemple)** | id_foret | code_foret | essence_dominante | annee_inventaire | altitude_moyenne (m) | |----------|------------|-------------------|------------------|----------------------| | 1 | F001 | Ayous | 2022 | 642.3 | | 2 | F002 | Sapelli | 2022 | 587.9 | | 3 | F003 | Iroko | 2022 | 710.5 | > **Vérification** : La moyenne d’altitude doit être comprise entre les valeurs minimale et maximale du MNT à l’intérieur du polygone ; on peut contrôler cela avec `gdalinfo -stats` sur un raster masque extrait par `gdal_rasterize`. --- ## Erreurs fréquentes et règles de sécurité | # | Erreur fréquente | Conséquence | Règle de prévention / bonne pratique | |---|------------------|-------------|--------------------------------------| | 1 | **Oublier de reprojeter les données avant une jointure spatiale** | Résultats faux (ex. superficie erronée, proximité inadéquate) | Toujours vérifier que toutes les couches partagent le même SRC (ex. UTM 32N) avant toute opération de superposition ou de calcul de mesure. | | 2 | **Utiliser un type de donnée inadéquat pour les coordonnées (ex. VARCHAR au lieu de DOUBLE PRECISION)** | Impossibilité d’exploiter les fonctions spatiales, perte de précision | Dans le DDL, privilégier les types `GEOMETRY` ou `GEOGRAPHY` de PostGIS ; stocker les coordonnées séparément uniquement si absolument nécessaire, en utilisant `NUMERIC(12,8)` avec une contrainte de vérification. | | 3 | **Ne pas définir de clé étrangère ou de contrainte d’unicité** | Duplication d’enregistrements, perte d’intégrité référentielle (ex. deux tronçons avec le même ID) | Déclarer systématiquement les clés primaires (`SERIAL` ou `UUID`) et les clés étrangères (`REFERENCES`). Ajouter des contraintes `UNIQUE` sur les attributs qui doivent être uniques (ex. code parcelle, code unité d’entretien). | | 4 | **Effectuer un calcul de surface ou de longueur sans tenir compte de la projection** | Valeurs en degrés plutôt qu’en mètres, erreurs de plusieurs dizaines de pourcents | Utiliser systématiquement des fonctions géodésiques (`ST_LengthSpheroid`, `ST_Area`) ou travailler dans un SRC à unités métriques (UTM, Lambert‑93) avant le calcul. | | 5 | **Ne pas sauvegarder les scripts de création et de chargement** | Impossibilité de reproduire la base en cas de panne ou de migration | Conserver tous les fichiers `.sql`, `.sh` et les logs de chargement dans un gestionnaire de version (Git) ; effectuer une sauvegarde quotidienne du dump (`pg_dump -Fc`). | | 6 | **Ignorer les mises à jour du SRID ou du datum lors de l’import de nouvelles données** | Décalages systématiques pouvant atteindre plusieurs mètres, impactant les décisions d’aménagement | Avant chaque import, vérifier le SRID du fichier source (`ogrinfo -al -so <file> | grep -i srid`) et, si nécessaire, appliquer une transformation avec `ogr2ogr -t_srs` ou `gdalwarp`. | | 7 | **Utiliser des requêtes SQL non optimisées sur de très grandes tables sans index spatial** | Temps de réponse dépassant les seuils acceptables (>10 s) | Créer systématiquement un index `GIST` sur chaque colonne de type `GEOMETRY` utilisée dans des filtres (`WHERE ST_Intersects(...)`) et analyser le plan d’explication (`EXPLAIN ANALYZE`). | | 8 | **Ne pas documenter les étapes d’intégration (scripts, paramètres)** | Perte de savoir‑faire, difficulté à former de nouveaux techniciens | Rédiger un petit manuel d’opération (Markdown ou PDF) décrivant chaque étape : reprojection, nettoyage, calcul zonal, chargement, avec les lignes de commande exactes et les jeux de données de test. | > **> À retenir** : Toute opération géométrique (longueur, surface, proximité) doit être effectuée dans un SRC à unités métriques ; sinon, convertir le résultat à l’aide d’un facteur d’échelle approprié. > **> À retenir** : La sauvegarde régulière du schéma et des données (dump logique ou physique) constitue une mesure de sécurité fondamentale contre les pertes accidentelles ou les attaques ransomware. > **> À retenir** : Lors de la conception d’une base de données spatiale, la modélisation conceptuelle doit être validée par les utilisateurs métier avant de passer à l’étape logique ; cela évite les refontes coûteuses en phase de production. --- *Fin du cours.*