IV.D.7 - Table des évolutions : classe
d'entités « matrice_eve »
Pour produire les données de la classe d'entités
« matrice_eve », nous avons réalisé l'intersection de
la classe d'entités « AVANT2010 » avec « APRES2010 »
(dans cet ordre), puis transformé les parties multiples en parties
uniques, et enfin chargé le résultat dans la table. Nous avons
chargé le contenu des colonnes de la classe d'entités «
AVANT2010 » dans les colonnes « *_AV » et celles de «
APRES2010 » dans les colonnes « *_AP ». Nous avons ensuite
éliminé les polygones reliquats, ou slivers, issus de
décalage a priori non significatif, en sélectionnant les
lignes de la table pour lesquelles la colonne « SHAPE_Area »
était inférieure à 2 m2, puis nous avons
supprimé le contenu de la sélection. Une autre solution
consisterait à utiliser l'outil d'agrégation ou l'outil de
généralisation « éliminer ».
109
Nom
|
Data type
|
Length
|
Domain
|
OBJECTID
|
Objectid
|
|
|
ENTITE_AV
|
Text
|
24
|
|
PARTIE_AV
|
Text
|
3
|
|
CLEABS_AV
|
Text
|
24
|
|
NOMEN_AV
|
Text
|
10
|
Nome
|
ENTITE_AP
|
Text
|
24
|
|
PARTIE_AP
|
Text
|
3
|
|
CLEABS_AP
|
Text
|
24
|
|
NOMEN_AP
|
Text
|
10
|
Nome
|
TRANSITION
|
Text
|
23
|
|
EVO_SURFACE
|
Text
|
1
|
Booleen
|
NUM_EVE*
|
Text
|
24
|
|
SHAPE
|
Geometry
|
|
|
SHAPE_Lenght
|
Geometry
|
|
|
SHAPE_Area
|
Geometry
|
|
|
EVE
|
Text
|
3
|
Nomeve
|
EVE_test
|
Text
|
3
|
Nomeve
|
La colonne « EVO_SURFACE » sert à distinguer
les lignes utiles au calcul de la matrice de transition. Si « NOMEN_AV
» est égal à « NOMEN_AP », la valeur de la colonne
est « Faux », sinon « Vrai ». Ceux marqués «
Faux » sont utiles à l'attribution des types
d'événements mais ne constituent pas une évolution de
l'occupation des sols.
Les colonnes « EVETEST » et « NUMEVE »
sont remplies par le programme « evenements_test.py » (voir Annexe
VI). La colonne « EVE » peut être remplie manuellement afin de
comparer les résultats avec ceux du programme. Nous avons validé
le test du programme pour les événements de type inchangé,
intégration, fusion et remplacement et effectué une saisie
manuelle au minimum une fois par type d'événement.
IV.D.8 - Relations
Nom
|
Type
|
Cardinalité
|
Notification
|
Origine
|
Destination
|
Clé
primaire
|
Clé étrangère
|
eve
|
Simple
|
1M
|
Aucune
|
evenements
|
matrice_eve
|
NUMEVE
|
NUMEVE
|
histo
|
Simple
|
1M
|
Aucune
|
RGFOR65_test
|
RGFOR65H_test
|
CLEABS
|
CLEABS
|
rec_actu
|
Simple
|
1M
|
Aucune
|
reconciliations
|
RGFOR65_test
|
NUMREC
|
NUMREC
|
rec_h
|
Simple
|
1M
|
Aucune
|
reconciliations
|
RGFOR65H_test
|
NUMREC
|
NUMREC
|
rec_h_mod
|
Simple
|
1M
|
Aucune
|
reconciliations
|
RGFOR65H_test
|
NUMREC
|
NUMREC_MOD
|
Nous avons créé des relations simples, elles
permettent d'effectuer des jointures automatiquement entre les tables
reliées. Nous n'avons pas utilisé de relation composite avec
transmission du message pour éviter les erreurs de manipulation pendant
le test. Par ailleurs, nous n'avons pas non plus utilisé ce genre de
relation entre la table des actualités et les extractions afin
d'automatiser la transmission des corrections car la transmission ne prend en
compte que les modifications attributaires, pas les modifications
géométriques, et également parce qu'en cas de suppression
de la ligne dans la table d'origine, la relation est marquée « Null
» mais la ligne n'est pas supprimée dans la table de
destination.
110
|