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
|