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

IV.C.6 - Règles topologiques

Les données enregistrées dans la table d'actualité ne devront présenter ni trou, ni superposition dans l'espace pour un temps de validité, ni présenter de trou ni de superposition dans le temps pour un même espace.

Les données d'occupation des sols, en général, ne doivent pas se superposer, ni dans le temps, ni dans l'espace. La couverture doit être continue, les données ne doivent pas présenter de trou, afin de s'assurer qu'il n'y a pas des données manquantes dans le temps. Les limites de la zone géographique représentée par ces données sont alors une exception à cette règle de continuité topologique.

Afin de contrôler ces deux règles, la solution la plus simple consiste à utiliser les tables extraites de la table des actualités. Si la topologie de chacune des extractions est correcte, alors la topologie de la table des actualités est valide.

IV.D - Test des traitements : méthodologie de la création du fichier « test_rgfor65.gdb »

La méthodologie employée par ce test consista à créer la structure du fichier de géodatabase selon le modèle logique décrit dans la partie IV.C, à charger les données du RGFor datées de 2006, et enfin à utiliser les ortho-photographies de 2006 et de 2010, la couche des changements de CLC et des scénarios d'évolutions forestières pour effectuer des mises à jour³⁵.

IV.D.1 - Contenu du dossier « test_histoRGFOR_OCS »

Nous avons commencé par créer un dossier « test_histoRGFOR_OCS »³⁶ contenant les données d'occupation des sols d'origine (dossiers « CLC », « RGFOR »), des données supplémentaires téléchargées sur le site de l'IGN³⁷ (dossier « GEOFLA »), des ortho-photographies (dossier « ORTHO »), et deux fichiers de géodatabase : « test_rgfor65.gdb » et « test_clc40.gdb ».

Le fichier de géodatabase « test_clc40.gdb » contient les données d'occupation des sols de CLC de 2000 et 2009, pour le département des Landes, extraites des données CLC de la France entière à l'aide des données de découpages administratifs du fichier « GEOFLA ». Ce département a été choisi pour ses étendues forestières importantes et parce qu'il a subi de nombreux changements sur la période considérée.

105

Figure 32 : Contenu du fichier de géodatabase affiché dans ArcCatalog (Source : travail personnel)

Nous allons maintenant détailler la création du fichier de géodatabase « test_rgfor65.gdb », dont le contenu est illustré par la Figure 32, car c'est ce fichier qui a fait l'objet du test.

³⁵ Voir le site de ressource d'ESRI pour la description du fonctionnement des outils que nous avons utilisé : http://help.ArcGis.com/fr/ArcGisdesktop/10.0/help/index.html#/na/00r90000001n000000/ Consulté en août 2013.

³⁶ Dossier chargée par la suite sur le disque ETRAVE de l'intranet de l'IGN.

³⁷ Voir : http://professionnels.ign.fr/geofla#tab-3 Consulté en août 2013.

106

Après avoir créé le fichier, nous avons défini ses domaines :

- « Booleen », champ texte, valeur pré-codée (« 0 » pour « vrai », « 1 » pour « faux »).

- « Nome », champ texte, valeur pré-codée (code nomenclature du RGFor).

- « Nomeve », champ texte, valeur pré-codée (trois premières lettres en majuscule de chaque

type d'événement).

- « PVA », champ date, jour/mois/année³⁸.

- « User », champ texte, valeur pré-codée (initiale de l'opérateur, plus un chiffre).

Puis, nous avons créé le jeu de données « test65 » et défini la projection du jeu de classe d'entité « test65 » en « RGF_1993_Lambert_93 ». Nous avons ensuite créé des tables dans la géodatabase et des classes d'entités dans le jeu de données (voir Figure 32).

Enfin, nous avons créé un catalogue de raster dans les dossiers d'ortho-photographies contenant les PVA des Hautes-Pyrénées datées de 2006 et de 2009³⁹. Puis nous avons créé un projet ArcGis appelé

« test_rgfor65.mxd » qui nous a servi aux traitements sur les données. Les chemins d'accès aux fichiers ont été paramétrés en chemins relatifs. Nous allons maintenant préciser les traitements nécessaires aux créations de ces tables et classes d'entités.

IV.D.2 - Table des actualités : classe d'entités « RGFOR65_test », classe d'entités « AVANT2010 » et « APRES2010 »

Nom	Data type	Length	Domain
OBJECTID	Objectid
CLEABS	Text	24
ENTITE_ID	Text	24
PARTIE	Text	3
NOMEN	Text	10	Nome
NUMREC*	Text	24
NUMREC_MOD*	Text	24
DATE_T_CREA	Date
DATE_V_CREA	Date		PVA
DATE_V_FROM	Date		PVA
DATE_V_TO	Date		PVA
SHAPE	Geometry
SHAPE_Lenght	Geometry
SHAPE_Area	Geometry
DATE_V_CREA_test	Date
ENTITE_IDtest	Text	24
PARTIE_test	Text	3

Nous avons créé la classe d'entités « RGFOR65_test », défini son type (polygone). Après avoir créé cette structure, nous y avons chargé les géométries et les nomenclatures des données de la BD Forêt : « BOSQUET65_DP », « FORET65_DP », « LHF65_DP » et « VERGER65_65 », datés de 2009.

³⁸ Le fichier « voronoi » est la source des dates de PVA. Cette date est une approximation de plusieurs dates d'observation.

³⁹ En cas de problème d'affichage du catalogue raster, supprimer son contenu et charger le à nouveau.

107

Notre modèle nécessitant une couverture continue de l'espace, nous avons ensuite dû ajouter des données dîtes « hors RGFOR ». Pour ce faire, nous avons utilisé les découpages administratifs contenus dans le dossier « GEOFLA » à l'échelle du département, sélectionné le département des Hautes-Pyrénées, effectué une zone tampon de 500 m pour les données de la BD Forêt dépassant les limites du département, et supprimé les intersections. Puis, nous avons sélectionné les découpages communaux des Hautes-Pyrénées, sauf pour les enclaves, effacé cette sélection dans notre couche de résultat précédente, et additionné ce résultat à la sélection des découpages communaux.

Nous avons divisé manuellement le polygone issu de la zone tampon en plusieurs parties. Enfin, nous avons effacé la couche « RGFOR65_test » dans notre couche de résultat afin d'obtenir l'ensemble des polygones hors du RGFor que nous avons ensuite transformé en parties uniques, puis chargé dans la classe d'entité « RGFOR65_test ». Les divisions des polygones hors du RGFor ne correspondent donc pas à une réalité de l'occupation des sols. Elles sont néanmoins nécessaires afin d'éviter les bugs d'ArcGis dus aux polygones de trop grandes tailles.

Enfin, nous avons complété les colonnes vides de la table : « CLEABS » et « ENTITE_ID » à l'aide d'une table jointe contenant des codes d'entités et de clés obtenus à l'aide d'un programme codé en python⁴⁰ ; complété « DATE_V_CREA » et « DATE_V_FROM » avec la date de PVA de 2010 ; « NUMREC » avec le premier numéro de réconciliation ajouté à la table « reconciliations » et « DATE_T_CREA » avec la valeur de la colonne « DATE_REC » de la table « reconciliations ».

Les colonnes « DATE_V_CREA_test », « ENTITE_IDtest » et « PARTIE_test » seront calculées par le programme « indentite.py » (voir Annexes VI) une fois des mises à jour effectuées sur cette base afin de pouvoir contrôler d'abord les résultats du programme. C'est ce programme qui crée les classes d'entités « AVANT2010 » et « APRES2010 » en sélectionnant les objets de la table des actualités valides jusqu'à la date de la mise à jour, et depuis la date de la mise à jour. Enfin, autre différence avec notre modèle logique, la colonne « OBJECTID » a été définie comme identifiant de la classe d'entité et non pas « CLEABS » afin de disposer de plus de souplesse dans le renseignement de cette colonne.