\section{IMPLEMENTATION AND EXPERIMENTS}%Hakima

The whole system has been originally developed in the COGIT laboratory where it has been implemented. This system is in operational practice and has been connected to the framework OXYGENE \cite{oxygene} of this laboratory. 
OXYGENE, mainly developed in Java, allows to model and to use geographical information within an oriented object scheme. Data Bases are managed with Oracle which has been completed with a spacial data extension. The mapping between Oracle and Object representation is made by JDO (Java Data Object) and OJB 

\begin{figure*}[htbp]
\begin{center}
\includegraphics[scale=0.5]{Architecture-en.eps}
\caption{EVOLA architecture}
\label{evola}
\end{center}
\end{figure*}

\begin{figure*}[htbp]
\begin{center}
{\includegraphics[scale=0.6]{bdtopoAngers.eps}}
\caption{Extract of BDTopo96 concerning Angers town}
\label{bdtopoAngers}
\end{center}
\end{figure*}


\subsection{Evola Architecture}
The system called EVOLA \cite{hkdphd} has been developped in the laboratory COGIT of IGN-France (Institut G\'eographique National). EVOLA is a tool which allows automatic updating of geographical data bases. 

The EVOLA general achitecture is summarized in figure \ref{evola}. In this figure, 4 parts are mentioned and describe the work needed to use it and the processes involved. 
\begin{itemize}
\item The need of reorganizing the GDB to make it agree with the model described previously, allowing the updating is mentionned by the part $(A)$. 
\item The part $(B)$ (resp. $(C)$) mentions that we need to model the updating informations (resp. the constraints representations) as previously described to adapt them to the system.
\item The part $(D)$ corresponds to the updating processus which is composed of a 3-modules kernel: {\it the reasoning-based engine, the integration module,
the scheduler}. 
\end{itemize}


We can see in Figure \ref{evola} how the different components do interact during the updating integration processus. First of all, the system receives an external set of updating operations from an external application. These evolutions may be expressed in the application format or in EVOLA format. If the first case, the set of evolution is passed to the {\it Adapter}. This last one converts it in the EVOLA format, corresponding to a set of specific canonical operations (creation, supression, descriptive modification and identity). Then the {\it sheduler} computes the best order to execute in the right sequence the whole set of these canonical operations. When the {\it Integration Module} receives the set of evolutions, it has to execute the different updating operations included in this set. This execution must be free from conflicts, otherwise the Integration Module has to detect them and to take decisions as regards these conflicts. To detect the conflicts, it uses the {\it Reasoning module} which, basing itself on the {\it constraints database} and the algorithms of consistence preservation, decides of the manner of modifications integration on the data of the database. At the end of each sequence of operations, a report of the various treatments of the operations is saved in the {\it Journal}. This report specifies for each operation, if it was carried out successfully or not. In case of failure of the operation, the journal specifies the kind of conflit generated by this operation and the constraints which was violated.\\ 


\subsection{Experiments and validation}

A methodology for the validation of this process has been developed and has proved that the mechanisms are efficient, even if some rejection can be avoided with a better scheduling. 
An experiment has been developed on the IGN GDB concerning the French town zone of Angers (see figure \ref{bdtopoAngers}). 

Using some matching technique  between two of these GDB from 1994 and 1996 (respectively called BDTopo94 and BDTopo96), we have built a set of updating informations. 

We define 2 indicators to validate the automatic updating process respecting the consistency maintenance:


\begin{itemize}
\item The {\it precision indicator} defined as the rate of correct updating decision number over the total realized decision number;
\item The {\it similarity indicator} which compares the updating results from BDTopo94 with the true situation in BDTopo96. This indicator is the rate of the number of matched objets in this comparison over the total number of matched objects and unmatched objects.  
\end{itemize}

From a specific experiment based on 30 canonical operations, we have obtained a precision indicator equal to 0.948 and a similarity indicator equal to 0.962 \cite{hkdphd} which is sufficient to validate the whole processus. 


