WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Recherche d'un processus d'historisation de base de données d'occupation des sols appliqué au référentiel géographique forestier de l'IGN

( Télécharger le fichier original )
par Romain Louvet
Université Paris Diderot - Paris 7 - M1 Géographie et Sciences des territoires 2013
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

IV.E - Exemples de requêtes, capacités de la base

Les objectifs de départ quant à l'intégration du temps dans la base de données étaient de répondre à des enjeux techniques, et surtout thématiques de suivi de l'évolution de l'occupation des sols. Les enjeux techniques que nous avions identifiés sont la gestion des doublons, le suivi de la qualité des données, la livraison de mise à jour différentielle, et assurer la cohérence topologique.

La base créée est capable d'intégrer une mise à jour sans doublon au sein d'une même table, ce qui accélère les traitements. La table principale, « RGFOR65_test » contient au total 133792 lignes ou objets. Divisée en deux tables, la somme de 133738 lignes pour « ext2006 » et de 133711 lignes pour « ext2010 » donne pour résultat 267449 lignes. Une requête sur la table principale nécessite donc grossièrement deux fois moins de temps de calcul que sur des jeux de données complets à chaque date de mise à jour.

L'historisation des versions d'objets et le renseignement de la table des réconciliations permettent le suivi de la qualité des données (voir la seconde réconciliation effectuée du jeu de données test qui est une correction). En cas d'erreur, il est possible de revenir à la version précédente de l'objet.

En joignant la date de réconciliation au numéro de réconciliation et en sélectionnant les dates supérieures à la dernière mise à jour, il est possible de ne livrer aux utilisateurs que les dernières versions des données à ajouter à leur base personnelle.

Enfin, les topologies associées aux extractions permettent de s'assurer que l'ensemble de la table des actualités est cohérent topologiquement, et qu'il n'y a pas de trou ou de superposition dû à un intervalle temporel mal défini.

Concernant l'analyse thématique, les principales questions auxquelles la base devait pouvoir répondre en termes de suivi de l'occupation des sols concernaient la localisation et le calcul des évolutions de surface, des évolutions des surfaces en fonction des types d'événement, et le suivi d'une entité.

En effectuant une requête de sélection par attribut sur la table des évolutions, on peut quantifier la quantité de surface totale en m2 ayant évolué entre 2006 et 2010. La requête pour la base test est « "EVO_SURFACE" = '0' », et les résultats statistiques de la sélection sont :

- 942382 m2 d'évolution de surface

- 274425 m2 maximum

- 2 m2 minimum

- 10133 m2 en moyenne

- 31611 m2 d'écart-type

Dans le cas d'une base complète, il serait nécessaire de faire la jointure avec la table des événements pour avoir la date de l'événement, puis de formuler la requête « matrice_eve.EVO_SURFACE = '0' AND evenements.DATE_EVE = date '2010-08-01 00:00:00' ». Par ailleurs, en plus de quantifier ces changements, la sélection nous permet de visualiser leurs emplacements dans un SIG.

111

De même, il est possible d'obtenir des statistiques par type d'évolutions qualifiée en transition d'occupation des sols par type d'événements (voir Annexe VII) et de les localiser.

Enfin, il est possible de connaître l'histoire d'une entité par simple requête dans la base. Par exemple, si nous souhaitons suivre une entité de haie dont l'identifiant est « RGFOR0650000000000044234 ». Il faut effectuer une sélection par attribut dans la couche des actualités : "ENTITE_ID" ='RGFOR0650000000000044234'. Le résultat donne trois lignes sélectionnées : l'entité a évolué en 2010 et existe à partir de cette date pour deux objets distincts (les attributs « PARTIE » sont différents). Ensuite, avec une requête dans la table des réconciliations, « "ENTITE_AV" ='RGFOR0650000000000044234' OR"ENTITE_AP" ='RGFOR0650000000000044234' », nous constatons que cette entité est liée à « RGFOR0650000000000101503 », de nomenclature « Hors RGFor », dans son évolution et que son type d'événement est une division. Nous pouvons alors formuler une analyse du suivi de l'occupation du sol telle que le réseau de trame verte s'est ici morcelé. Étendu à l'ensemble des données, ce type d'analyse pourrait servir à l'étude de l'évolution du paysage, utile potentiellement au SCOT et à l'élaboration de la trame verte et bleue.

112

V - Conclusion

La demande de l'IGN était d'étudier les différents processus d'historisation possible afin de proposer une méthode de mise à jour des données du RGFor permettant d'intégrer la dimension temporelle. Il était demandé d'étudier particulièrement le processus de la BDUni, interne à l'IGN, dans le but d'évaluer si celui-ci était compatible avec les besoins des utilisateurs de données d'occupation des sols.

Ce travail nous a amené à nous interroger sur la modélisation des bases de données géographiques permettant de répondre à la problématique de l'observation d'un territoire au cours du temps. Nous avons étudié les spécificités des données du RGFor ainsi que les besoins de ses utilisateurs. Puis, nous avons effectué un travail de recherche sur la modélisation du temps dans les bases de données. Cette recherche nous a, par la suite, aidés à décrire les modèles utilisés par des bases existantes, dont la BDUni, et à évaluer leurs capacités.

Cette étude a permis de réaliser une synthèse sur l'intégration du temps dans les SIG en général, et plus spécifiquement dans les bases de données, puis de montrer les limites des modèles existants. Le temps a été défini comme une notion ayant de multiples aspects, dont les plus importants sont la distinction entre le temps absolu et le temps relatif, ainsi qu'entre le temps de transaction et le temps de validité.

Nous avons montré que le processus d'historisation de la BDUni était un modèle avancé mais qu'il ne correspondait pas aux besoins spécifiques des données d'occupation des sols. Nous avons donc proposé un modèle fondé sur la BDUni et reprenant le principe du modèle orienté-objet avec modélisation des événements.

Ces propositions ont fait l'objet d'un test sous la forme d'un fichier de géodatabase créé à l'aide de la version 10.0 d'ArcGis. Ce test nous a servi à valider notre modèle logique de base de données et à démontrer les capacités de requête de la base. Il conviendrait toutefois de poursuivre les tests selon plusieurs pistes de réflexion :

- en améliorant notamment le traitement des polygones hors du RGFor ;

- en questionnant les critères d'identité et en terminant le programme de reconnaissance des événements ;

- en automatisant la répercussion d'une mise à jour de la table des actualités sur l'ensemble
des tables à l'aide des attributs de « CLEABS » et « NUMREC » ;

- en indexant la table des actualités afin d'accélérer les traitements et les requêtes et pallier le
défaut de l'allongement de la table à chaque mise à jour ;

- en poursuivant les tests avec d'autres données, comme le jeu de données CLC, ou d'autres outils, comme le versionnement d'ArcSDE.

Enfin, il serait intéressant de confronter ce modèle à ses utilisateurs futurs pour en évaluer tous les potentiels d'utilisation et définir les fonctionnalités temporelles du produit final qui leur sera proposé à partir de la base de production de l'IGN.

113

114

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il faut répondre au mal par la rectitude, au bien par le bien."   Confucius