International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
GeoTab
idet
-IDGeo: NUMBER
-world:mdsys.sdo qeometry |
| Sioa?
Solid Surface |
= pue rer |
| | Material
| dn 4 eth i trae)
SolidGeometryTab I-— SurfaceGeometryTab —— ze E
A ——————————1] V
-IDSclidGeometry. NUMBER SolidAggregateNestedTab -IDSurfaceGeometry. NUMBER SurfaceAggregateNestedTab | |
i
CE ] |
——— Y y
| | Lee Texture RGB
ec roue — | SurfaceGeomoatryRet
SolidGeometryRef i
lo: iN -Bitmap:BLOB -red: NUMBER
| T EdgeListNestedTab -Transformation:VARRAY -green: NUMBER
i -blue:
FaceLisiNestedTab | -SortVar:NUMBER Pan
nl tap
ja f |
SolidRef / || i
FaceRef | i |
FecelistNested Tab | !
| | E ice
\ / y | Y EdaeListNestedTab EgdeRef
: VertexTab
SolidTab FaceTab RingTab / =
EdgeTab
-IDVertex: NUMBER
-IDSolid: NUMBER -IDFace: NUMBER ExtenorPe! . | IDRing:NUMBER = NN
-Orientation. VARRAY FREER EEE NUNFER EncRef y NUMBER
ncRe sy
mE -z: NUMBER
Figure 4. Object-relational database schema for the 3-D city model
and between a ring and its edges are realized, using the nested
tables RingListNestedTab and EdgeListNestedTab.
Based on the topological primitives, aggregates can be build
recursively. This enables the representation of arbitrarily nested
building structures. An example is one university campus,
which consist of several complex buildings. One complex
building consists of parts, and these parts again are a
composition of a main part, chimneys and balconies, and so on.
An aggregate is represented by a row in the So/idGeometry
table in Figure 4. The relations to the parts of the aggregate are
defined by the nested table SolidAggregateNestedTab, which
references several rows in the SolidGeometry table. Since these
rows in the SolidGeometry table may have parts on their own, a
nesting of arbitrary depth may be achieved. Finally, the
SolidGeometry rows, which have no parts, are related to a Solid
defining the geometry and topology of the So/idGeometry row.
Faces may be aggregated to SurfaceGeometries analogously. In
particular, this is necessary to map textures on surfaces, which
is very important for the visualization of 3-D city models.
Attaching textures to aggregated SurfaceGeometries provides
more flexibility than relating it to a face, since often textures
correspond to whole walls covering more than a face of a single
building. Textures are represented by a row in the Material
table, which may alternatively be just a color value when no
texture is available.
On the top level of the database schema in Figure 4, the GeoTab
table represents the geometry of objects by a value of Oracle
Spatial’s SDO_GEOMETRY type, which was already
discussed in section 2. A row in the GeoTab table may be
rclated to a SolidGeometry ot to a SurfaceGeometry, but not to
both. In both cases, the SDO GEOMETRY value is a collection
of polygons. It must form a closed solid. if it is related to a
SolidGeometry. The database, however, provides no standard
mechanisms to check this property.
Using a collection of polygons to represent a solid is only an
approximation. This is due to the fact, that Oracle Spatial does
not offer geometry types for solids. The semantics of a solid is
different to the semantics of a collection of polygons forming a
closed solid. For example, the question whether a point is
completely inside a solid may be answered by a solid model,
but not by a polygon approximation of a solid. In such a
polygon model, the notions of ‘inside’ and ‘outside’ are not
defined.
Note that a solid may not be approximated by a multi-polygon.
According to the ‘Simple Feature Specification’ (Open GIS
Consortium, 1999), two polygons being part of one multi
polygon may touch only in a finite number of points. In a solid
boundary, two polygons meet in a common edge and thus touch
in an infinite number of points.
The database schema for the 3-D city model is accompanied by
a set of integrity constraints, which express relevant properties
of the model explicitly, and which are important for many
applications using the model. One constraint, for example,
states that two solids must be disjoint and may touch at least at
their boundaries. In this case, the area where both solids touch
must be a face, which is contained in the boundary of both
solids. More details about integrity constraints may be found in
(Kolbe & Gróger, 2003).
4. QUERYING 3-D CITY MODELS
Based on the analysis of the 3-D query capabilities in the
second section, now it is discussed how the 3-D city model
presented in the last section may be queried.
4.1 3-D Queries
As discussed in the second section, Oracle Spatial's operators
apart from SDO FILTER are not applicable to 3-D data, while
functions neglect the z-coordinate and treat them as zero,
respectively. To obtain a efficient two-tier query model, the
SDO FILTER operator, which is suitable for 3-D bounding
boxes, may be combined with 2-D functions, enabling a few
standard applications for 3D city models. This combination is
achieved by a nested SQL command; SQL is the standard query
language for relational databases (Ullman, 1988).
An example for a nested query is given in Figure 5. It selects
the identifiers of those objects, which are related to solids
having the relation “inside” (see Figure 2) to the bounding
rectangle or window given by the two coordinate pairs
(3446733.79, 5549996.27) and (3445133.79, 5539196.27). In
the nested select-from-where-statement, which is included in
the from-part of the outer query, the SDO FILTER operator is
applied. It selects all geometries interacting with the 3-D
Intern
bounc
tree n
from-
the x
illustr
vi
Figure
To sun
no exa
exact 1
coordir
These «
for ma
relatior
particu
not sup
states tl
queries
the resi
dimens:
4.2 Pe
Due to
operato
Figure
The da
depictec
building
than a
Athlon
RAM. T
