International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B2. Istanbul 2004
2.1 Federated Database
The MRDB approach we have developed is based on the
architecture of a federated database system (FDBS) (Conrad,
1997; Sheth, 1990). Starting point for a FDBS are several
existing databases which should work together to provide a
global service, but keep their own local autonomy. A FDBS can
be classified by three main characteristics: Distribution,
Heterogeneity, and Autonomy. Distribution means that the data
1s stored on different database systems (DBS), which can run on
a single computer system or in a distributed computing
environment. Heterogeneity, because the DBS can use different
database management systems (DBMS) and finally Autonomy,
because the different DBS can be designed independently from
each other and it is possible that each DBS runs independently
from the Federation Layer (no changes of local application
programs are necessary). Figure 1 shows the general
architecture of a federated database system.
Global Application ... Global Application
N e
f | Federation Layer | \
TT ud
ee
— U = 1;
:;| Local = ; Local
: | Application i | Application |
: e 9
: > |
j y p
:| Local p 4 Local :
{| Application | Application
Figure 1. General architecture of a federated database system.
2.2 System architecture
Figure 2 shows the complete system architecture of the MRDB.
The Federation Layer of the FDBS is lower green block in
Figure 2. Every component DBS in WIPKA stores one specific
representation layer (BaseDLM, DLMS50, DLM250, or
DLM1000). The Federation Layer integrates the component
DBS’s to an MRDB and provides the user interface to the
MRDB. Therefore the Federation Layer contains a working
database to store all needed meta data. These meta data
includes the registration of the component databases and the
links between them. The working database stores also all
information for the object identification and propagation of
updates through the component databases.
Access to the Working database and the link information is
provided by a PL/SQL interface which can be used by an
database connector (e.g., ADO, ODBC, JDBC). Access to the
spatial data can be done directly using oracle interfaces or by
ArcSDE from Esri for ArcGIS. ArcSDE is a generic database
interface which can be used to connect ArcGIS to the most
commercial database systems. The most functionality of this
interface layer is implemented as stored procedures directly on
the Oracle database system which is an problem for ArcSDE if
the called stored procedure has a return value. That is the case if
one is querying the linked objects to a given object id.
Therefore one has to use in VBA (Visual Basic for
Applications) the ADO (Active Data Object from Microsoft)
interface to call such kind of stored procedures. VBA is the
main macro programming interface of ArcGIS.
Based on this interface to the working database all MRDB
applications are implemented like matching procedures,
generalisation tools, and graphical user interfaces.
| GUIs | d
|
| Matching Visualisation
Visualisation
Register eri
(ArcMap) Generalisation
DB
| (GisVisual)
LADO =) ArcSDE
| Stored Procedures / SQL
Work ing -DBS (Oracle9i7 Spatial)
| Links |
| BasisDLM || DLMSO || DLM2SO || DLM1000 |
ADE |
| Metadata |
Figure 2. System architecture of the MRDB.
3. GENERATION
In general there are three possibilities to generate data for an
MRDB: manual linking, linking by matching, and linking by
generalisation.
3.1 Manual linking
Manual linking means that the MRDB system provides
interactive tools for selection and linking / unlinking of data
object s with different representations from different data sets.
The manual linking will always be the case if two or morc
existing data sets have to be integrated into an MRDB and if no
automatic method is available or successful.
3.2 Linking by matching
The integration of several existing large data sets into an
MRDB completely by hand would be to inefficient, therefore
one has to use automatic matching tools to create links between
the data sets. In our system we will provide different kind of
matching tools. There will be basic semantic filters, geometric
filters, topological filters. and relational matching procedures.
A semantic filter is a kind of simple matching routine, because
he is comparing only the attribute values of objects, e.g. object
types like residential area, industrial area, motorway, or
highway. A geometric filter compares only the geometry (shape
and position) of the objects and a topological filter compares
the topological relations between simple and aggregated
objects. The relational matching procedures are combination of
all the basic filters to complex matching routines which are
taking into account all information available for an object. For
now a relational matching procedure for line objects was
implemented and a simple geometric matching routine for arca
objects. The relational matching routine is using semantic filters
to create a first selection of possible matching candidates to
reduce the search space. The simple area matching procedure is
based on the size of the intersection area of two possible
candidates. The shape of both objects is not used for the
moment. We have tested this matching routine by linking
I
Interna
buildin
BaseDl
Figure
33 Li
The thi
of obje
represe
comple
or in t|
mediun
automa
from a
ATKIS
which :
types :
There&
general
subject
implem
howeve
arbitrar
steps:
WwW h3 —
The fii
ATKIS
landsca
ATKIS
certain
handles
after th
DLMS5(
object «
have tc
establis
these ai
can be
shown
definiti
is giver
replace
4a).
