III.C.4 - Avantages et inconvénients du
modèle
Comprendre le processus de mise à jour et la prise en
compte de la dimension temporelle dans la BDUni en étudiant une
méthodologie interne à l'IGN est particulièrement
intéressant pour tenter de répondre à la
problématique de l'historisation dans le cadre du RGFor. Reprendre le
modèle de la BDUni pour le RGFor représente en effet pour l'IGN
la solution a priori la plus simple, celle qui demanderait le moins de
développement et qui pourrait être la plus avantageuse en termes
de coûts et d'investissements.
III.C.4.a - Capacités
L'historisation dans la BDUni correspond à un
modèle avancé. Tant que la donnée n'est pas
modifiée, elle n'est enregistrée qu'une seule fois. Ce qui permet
de limiter la quantité d'information à stocker. Les
données possèdent une date de création, modification,
suppression. L'accès à des états temporels est ainsi plus
rapide (que dans un modèle de journalisation par exemple). Les
données sont stockées dans deux tables, ce qui permet
d'accéder plus rapidement à l'état courant des
données.
Le versionnement et l'horodatage des versions ont permis
à l'IGN de développer des outils :
- Extraction de différentiel pour la livraison de la mise
à jour (Bonneau, 2008).
- Visualisation d'un état de la base à une date
donnée.
- Prototypes de visualisation cartographique32.
31 Orthophotographies de l'IGN, registres des actes
communaux, courriers, appels, déplacement sur le terrain, l'Internet
(images Google Earth et Bing, les Pages Jaunes, les sites des mairies,...),
etc.
32 Évolutions BDUni - cartographie des évolutions,
sur
http://rks1009w117.ign.fr/map-evolution/
87
La base permet de contenir un lien entre les différents
états d'un objet. Elle permet de suivre le changement en
établissant un historique fondé sur la présence d'un
identifiant et d'un identifiant successeur. Pour la BDUni, ce modèle est
implémenté grâce à :
- La conservation de la « cleabs », permettant de
fonder l'identité fixe de l'objet informatique.
- La liste chaînée des « numrec » et
« numrecmodif » établissant le lien entre les objets.
III.C.4.b - Inconvénients
III.C.4.b.1 - Manque de typologie des
événements et d'automatisation du processus
La limite importante de ce modèle tient au fait qu'il
demande une réflexion sur l'interprétation de la modification ou
de la suppression de l'objet géographique. Or, bien que des consignes de
saisies existent dans ce sens (IGN, 2012-B), un réel manque de
définitions plus claires et qui ne soient plus simplement
attachées aux objets informatiques mais aussi aux objets réels,
géographiques, qu'ils représentent, demeure. En outre, le
processus comprend peu de contrôles ou de méthodes automatiques.
Or l'analyse du changement peut être complexe, surtout à
décomposer : une même zone de changement ou de
réconciliation peut avoir plusieurs causes et peut avoir des
conséquences sur plusieurs classes d'objets ou plusieurs objets dans la
même classe.
Figure 26 : Cas d'une mise à jour illustrant deux
résultats différents en fonction de la saisie (Source : travail
personnel)
La Figure 26 est un exemple concret d'une mise à jour
et des questions qu'elle peut soulever. Au moment du contrôle, une
incohérence est détectée : les objets « i » et
« j » se superposent. Ces deux objets représentent un phare,
« i » sa tour et « j » sa partie plus basse. Il s'agit
d'une erreur de digitalisation qui ne devrait pas avoir pu être
réconciliée auparavant. Considérons que l'opérateur
avait classé cette incohérence en erreur légitime. Nous
souhaitons corriger cette erreur, tout en conservant les identifiants « i
» et « j » d'origine. Or, en fonction de la méthode de
saisie, avec un outil de découpage (a) ou manuellement (b), le
résultat n'est pas le même. Dans un cas l'identifiant est perdu,
dans l'autre il est conservé. Si une zone de réconciliation est
dessinée uniquement pour cette modification, un lien direct existera
entre l'objet prédécesseur et ses successeurs. Mais si on
réalise plusieurs corrections en même temps, on peut estimer
qu'elles constituent un ensemble cohérent et les réconcilier en
même temps, perdant de ce fait le lien spécifique entre
prédécesseur et successeur. Enfin, au moment de nommer la
réconciliation à l'aide de la colonne « nom »,
plusieurs options sont encore possibles, ne facilitant pas le suivi : erreur,
correction d'erreur, superposition, incohérence, aberration, etc.
L'identification de la réconciliation par un texte libre est une
difficulté pour le suivi des évolutions en l'absence d'une
typologie des événements qui permettrait d'optimiser leur analyse
par la requête.
88
Cet exemple nous permet d'aborder un dernier point : celui du
découpage des objets. Si un objet est découpé, un ou
plusieurs nouveaux objets sont alors créés. Or un seul objet
conserve l'identifiant permettant la filiation, cette information est perdue
pour le ou les autres objets. De même, un objet qui serait détruit
puis recréé (comme cela pourrait être le cas d'un
bâtiment détruit puis reconstruit à l'identique) ne
possède plus l'identifiant de départ. L'identifiant
utilisé dans la BDUni référence des objets informatiques,
non des entités géographiques. L'analyse du suivi du changement
s'en trouve donc limitée.
La mise à jour par réconciliation
effectuée par la MAJEC permet théoriquement le suivi des objets
pour l'analyse des changements, mais elle dépend fortement de
l'appréciation de ce changement par l'opérateur, de
l'interprétation des consignes de saisie, de sa maîtrise des
outils et des contraintes temporelles de production des données.
III.C.4.b.2 - Une prise en compte incomplète de la
dimension temporelle
La prise en compte de la dimension temporelle dans la BDUni
est celle du temps informatique. C'est une base de données
rollback uniquement. Elle correspond aux besoins actuels des utilisateurs
de la base : une information à jour, le plus rapidement possible. Les
tables d'historiques servent à pouvoir revenir sur une mise à
jour dans le cas d'une erreur. L'historisation des données n'est pas
liée au suivi du terrain, mais au suivi de la donnée. Le
modèle d'historisation qui a été mis en place pour la
BDUni répond en premier lieu aux attentes de production.
Le suivi des évolutions est quant à lui un
autre besoin. Il demande l'enregistrement du temps de validité, comme
c'est le cas pour la BdOCS et le MOS. Le temps de validité peut
être retrouvé dans la BDUni, soit en considérant que le
temps de transaction est suffisamment proche du temps de validité
puisque la mise à jour est effectuée en continu, soit en
retrouvant la référence à la source de l'information
possédant une date de validité dans les
métadonnées.
La production en continu des thèmes tels que les
réseaux routiers et les bâtiments a pour avantage que le temps de
validité et le temps de transaction est en effet proche dans 99% des
cas. Néanmoins, il reste toujours un problème :
l'impossibilité de corriger à posteriori les données sans
compromettre leur temporalité (Heres, 2000, p. 46). Or, les
données peuvent être corrigées plusieurs années
après leur création au moment de la restitution. La restitution
est une étape dans la chaine de production de l'IGN qui consiste
à reprendre les ortho-photographies de références pour
corriger le positionnement et les estimations de hauteurs des objets
topographiques. L'information temporelle est donc très souvent
faussée.
III.D - Normes concernant les données
d'occupation des sols et l'intégration du temps
| 
