I.C - Modèle de mise à jour et
d'historisation
Le principe de la mise à jour de la BDUni repose sur le
fonctionnement de GCVS. La mise à jour est réalisée
principalement grâce au mécanisme de réconciliation. Les
collecteurs de données modifient
53 Source : Date, 2004
xxxvii
leur base client et font remonter ces modifications à
la base serveur. Les informations fournies par les deux bases sont ainsi «
réconciliées ». Durant cette réconciliation,
l'historisation intervient par une copie des objets de la table actuelle, dans
notre cas « zone_de_vegetation », vers la table d'historique, «
zone_de_vegetation_h », à chaque réconciliation pour les
objets modifiés ou détruits touchant la zone de
réconciliation. Grâce à la conservation de l'identifiant
« cleabs » pour chaque version d'un objet, et au chaînage des
numéros de réconciliation, il est possible de suivre les
différentes versions successives des données et, a fortiori,
de la base.
I.C.1 - Mécanismes de mise à jour
I.C.1.a - La création utilisateur par zone de
réconciliation
Figure 3 : exemple d'une mise à jour du
réseau routier à l'aide d'une zone de
réconciliation54.
L'opérateur réalise d'abord la mise à
jour sur sa base client en effectuant les modifications manuellement. Puis, il
délimite une « zone de réconciliation » qui intersecte
le ou les objets modifiés. Enfin, il fait remonter les modifications
à la base serveur, à travers GCVS. Ces outils (tracé,
réconciliation, etc.) se présentent sous la forme d'un module
ajouté au logiciel GeoConcept.
L'intérêt de la zone de réconciliation est
de mettre à jour la base de données serveur par ensemble
cohérent de modifications. Par exemple, la transformation d'un carrefour
en rond-point implique de nombreuses modifications. Créer une zone de
réconciliation sur le rond-point permet d'englober ces modifications
indiquant l'unique changement réel. L'ensemble des objets ayant subi la
modification sont liés par un même « numrecmodif ». La
figure 3 montre un exemple fictif d'une mise à jour de ce type. Les
tronçons du départ ont été scindés en deux,
ce qui résulte en leur modification et la création de deux
nouveaux tronçons. Le rond-point a été créé.
Afin de répercuter ces modifications de façon cohérentes,
la mise à jour est effectuée en traçant une zone de
réconciliation englobant toutes ces modifications.
I.C.1.b - La montée en base
Second mécanisme de mise à jour, la
montée en base est simplement un transfert de l'ensemble des
données du poste client vers le serveur. C'est ce procédé
qui est employé actuellement dans la chaîne de production du
RGFor. L'opérateur travaille sur des données en cours de
production. Elles ne sont pas encore présentes dans la BDUni. Une fois
que l'opérateur a terminé de travailler sur les
54 Source : ortho-photographie IGN, département des
Hautes-Pyrénées.
xxxviii
données, celles-ci sont enregistrées dans la
base serveur. L'opérateur n'a pas besoin de sélectionner les
données qu'il envoie sur le serveur, elles sont enregistrées sans
distinction (Figure 4).
Ce mécanisme possède l'avantage, par rapport au
précédent, de permettre le transfert sur le serveur d'un gros
volume d'informations. Il se prête ainsi aux exigences d'une base de
végétation étant réalisée d'un bloc,
à l'échelle de tout un département, contrairement à
la zone de réconciliation qui se prête plutôt à la
mise à jour en continu des opérateurs de la MAJEC.
Figure 4 : schéma de la montée en base de
la couche végétation55.
Toutefois, la montée en base se fait pour l'état
zéro des données, c'est-à-dire sur une base serveur
vierge. Elle est utilisée pour la création de la base de
données. S'il était utilisé pour la modification des
données, ce mécanisme correspondrait à une mise à
jour par écrasement des données précédentes. En
effet, les données sont « montées > en base et non
réconciliée avec les données déjà
présentes sur le serveur. La montée en base n'utilise donc pas
GCVS.
| 
