stanbul 2004
according 10
One specific
tries, which
geometries,
indow-query,
; not consider
by a minimal
depending on
ind boxes are
ate reference
xes, however,
le, the two
he bounding
:cognizes that
:3DO FILTER
ing boxes as
imal bounding
“igure a), both
ch other, while
ich each other,
lect geometries
geometries, Or
ip to the well-
lerring, 1990).
alled ‘two-tier
the morc exact
ors apart from
more than two
er.
filter step and a
t they ignore the
tions to select
del, to compute
ntroids, buffers,
intersection of a
distinguished by
iplements the 4
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
intersection model. Note that the z-coordinate is ignored by the
function. If, for example, one geometry A is above a geometry
B and both are disjoint, then the operator SDO GEOM.
RELATE recognizes erroneously that A and B are not disjoint.
A (=m A A - B =
Packs |
3i E pA
i
A Contains B A Covers B A Touch B
B Inside A B Coveredby A B Touch A
TT" A PT i
0 BT
I !
= nin Bi
A OverlapBdylIntersect B
B OverlapBdylIntersect A
A OverlapBdyDisjoint B
B OverlapBdyDisjoint A
Pen ) i
| 1
A. B! A EH
i 1 De
15 e coal LE i
A Equal B
B Equal A
A Disjoint B
B Disjoint A
Topological relations differentiated by the function
SDO_GEOM.RELATE, which implements the 4-
intersection model (Oracle, 2002b).
Although functions do not use the R-tree index, both concepts
may be combined in a 3-D query. The operator SDO FILTER
is employed first to pre-select a superset of the desired
geometries in an efficient way, using the R-tree index and
bounding boxes. This set is further refined by a 2-D function
afterwards. In this way, a two-tier query model may be realized.
An example of such a query will be given in section 4.1.
2.2 Object-relational properties
The database Oracle offers an object-relational extension of the
relational data model, closing the gap between the object-
oriented conceptual model, which often is formulated using the
Unified Modeling Language UML (Booch et al., 1997), and the
database. Object-relational features in Oracle are object types
and object views, which specify attributes and methods. They
are implemented using one or more object tables, being similar
to relational tables. Object methods, which can be used to
manipulate the data, are stored with the table definition. The
concept of inheritance allows the specification of super- and
subtypes, which will be mapped on relational tables by the
database management system. An object table may have
references to other object types, allowing navigational access
and replacing the relational concept of foreign keys.
In the relational data model, the columns of tables are restricted
to contain simple data types. In contrast, the columns object
tables may be whole objects or whole tables, which are called
nested tables. Nested tables provide a convenient means to
represent m:n-relations between object tables. In relational
tables, the representation of these relations requires an
additional table, too. But a nested table is embedded into an
object table, simplifying the handling of the relation. An
example for a nested table embedded in an object table is
depicted in Figure 3. The first row of the object table has
relations to three objects, which are identified by A11, A12 and
A13.
The efficiency of nested tables may be improved by using
indices. The database arranges the order of the rows according
to the order of the corresponding rows in the superior object
table.
DATA1 | DATA2 | DATA3 | DATA4 | NT DATA
1 x
: Storage Table Uu
STED TAB
Siorage for [A
nested --
table À
Storage for
nastad —
table B
Storage for
nested
table C
Storage for
nested — :
table D fi
Storage for
nested ----
table E
Figure 3: Example for a nested table, embedded in an object
8 F
table. Each row of this object table corresponds to
several rows in the nested table, representing a m:n-
relation The figure is taken from (Oracle, 2002a).
3. REPRESENTING 3-D CITY MODELS
This section describes how the multi-functional 3-D city model
presented in (Kolbe & Gröger, 2003) was implemented in
Oracle 9i Spatial and which difficulties occurred due to some
deficiencies of this database. First, the geometry data types of
Oracle Spatial do not provide explicit topological relations
between geometric components, which are crucial for
representing 3-D city models. Thus topology had to be modeled
using standard object-relational, non-spatial tables. To get
benefit from the efficient spatial index structure, the spatial data
types are used in addition, obtaining a double representation of
spatial properties, which is redundant to a certain degree. In the
following, the topological level of the database schema is
discussed first, the aggregation level afterwards, and finally the
representation of the geometry using the Spatial extension of
Oracle. The complete database scheme is depicted in Figure 4.
At the bottom of Figure 4, the primitives vertex, edge, face and
solid as well as their topological relations are represented,
according to the well-known Boundary Representation (Foley
et al., 1995; Herring, 2001). Each primitive is stored in a single
table. Rings are employed to differentiate outer boundaries
from inner boundaries of faces, i.e. holes. The various m:n-
relations betwcen the topological primitives are implemented
by the object-relational concept of nested tables. For example, a
solid is bounded by several faces. Thus one column of the solid
table is a nested table called FaceListNestedTab, cach row of
which contains a reference to a bounding face of the solid. In a
similar way, the relations between a face and its interior rings
