e amount
and links
requiring
pose the
] objects.
rules
correct or
compute
nted it in
)rocess is
gehalten.
gung von
ibestünde
wohl die
1t-Objekt
1 wir als
:eal- Welt
en.
rmittlung
Matching-
in Oracle
raphische
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
1. INTRODUCTION
1.1 Motivation
For many cartographic datamodels there are multiple databases
each representing part of earths surface in a specified
resolution. For example for the german ATKIS-model there
exist independently mapped datasets for the resolutions
1:25.000, 1:250.000 and 1:1.000.000. The necessity to update
these datasets causes an extensive amount of work, because
every single dataset has to be adjusted manually.
One way to reduce this is to automate part of the work, that is to
update only one resolution, the finest, and then propagate the
changes to all other resolutions. A prerequisite for this
procedure is, that the access from one object to all
corresponding representations of the same real world object is
possible. A concept for such a data structure is the multi-
resolution database.
Because cartographic objects often lack an explicit (and to the
represented real-world object related) identifier, a main issue in
the process of setting up a multi-resolution database is to
identify objects which represent the same real-world object.
This paper describes an architecture for a multi-resolution
database, that is based on the paradigm for federated databases,
and on a framework for the computation of object matchings.
1.2 Related Work
In (Walter, 1997) the buffer growing algorithm which we use
for parts of the geometric matching is described. That paper
also makes a suggestion for a sclection process based on
relational quality of the set of chosen matchings and develops
an algorithm to find the “best” set of matchings.
(Sester et al., 1999) gives an overview of different approaches
for finding links between representations of real world objects.
(Kleiner et al., 2001) develops a system for the storage of
geographic objects in object-relational databases, which we use
for the component databases to be integrated in the multi-
resolution database.
(Conrad, 1997) gives an overview of the paradigm of federated
databases and methods to generate it. In particular different
methods for conflict resolution during integration of database
schemas are described.
2. STRUCTURE OF THE MULTI-RESOLUTION
DATABASE
2.1 Architecture and system structure
To maintain the cartographic quality of the different datasets, it
is useful to keep the original databases and separate the needed
integration from them. A reference architecture for such
purposes is the federated database (see Conrad, 1997). This
architecture guarantees a maximum of autonomy for the so-
called component databases, i. c. the databases to be integrated,
while enabling an integrated access to them for global
applications.
173
Global Global
Application Application
I T
Ÿ Y
Federation Layer
Federation service |
4 4 t
Integration
database
Local 3 Local
Application T»pes J _ pBMS | Application
i | DB n |
Federated Database System
m
Figure 1: Architecture of a federated database system
The principle structure of such an architecture is shown in
figure 1: The (unchanged) component databases still support
their local applications. They are integrated via a federation
layer, which offers the global access to them. The federation
layer maintains the links between correponding objects and
holds the meta data for the access and for processes, for
example for matching and generalization. Therefore the
database for the federation layer consists of the mentioned parts
as shown in figure 2.
Linkstructure Process Meta Data
1
: Semantic
: Classification 1
I
nn
Registration
Figure 2: The integration database
2.2 Link structure
Real world objects often are represented as combinations of
more than one database object. For example street sections
between crossings can be broken into multiple segments with
respect to some attribute, say name of the street or their width.
If these criteria are different in the datasets to be integrated,
because of ditferent datamodels or differing tresholds for data
capture or any other reason, the real world object may be
represented in sets of database objects, which cannot be
matched one by one. In figure 5 such a situation is shown. The
street section is represented by three objects in database A and
two objects in database B and there is no correspondence
between a pair of objects from database A and database B.
Therefore a structure for storing matchings has to deal with
matchings of cardinality many-to-many as well as cardinalities
one-to-one and one-to-many. Figure 3 shows a schema that
