d. This
| to the
tabases.
located
cording
between
ndigkeit
schnelle
mitteln,
roBe am
mierung
indering
present
, which
Ig inter-
sm used
of com-
times in
isualiza-
ail. The
current
le detail
ontrast,
pace on
lications
he most
ugh sev-
none is
. There-
Illy, thus
j| at all.
levels of
w, these
; and do
tric rep-
improve-
tore the
we. (2),
ery simi-
dditional
informations such as the view angle. For example, the im-
postor for the front view of a building might consist of only
one rectangle. Although this idea might produce higher qual-
ity pictures, building an impostor model is even harder than
building LOD models.
[FS 93, Fun 93] describe the Sodahall walkthrough system:
This system allows real time movement through a complex
building. The visualization is based on the LOD concept. To
choose the appropriate level of detail, time constraints are
used. If the scene gets more complex during a walk through,
the level of detail is reduced accordingly. Thus, a nearly con-
stant frame rate (independent of the complexity of the visible
scene) can be achieved. The entire model (350 Mbytes) is
stored in a database system especially developed for the So-
dahall system. This approach guarantees maximum speed
but lacks multi user access, standard queries etc. — features
that are indispensable for a GIS.
[KLR 95] describe a system called Virtual GIS, which uni-
fies a textured DTM (digital terrain model) with simple GIS
data (buildings). The system uses the LOD idea extensively
to minimize the amount of DTM data actually drawn and
achieves "real-time visualization’ (defined in the paper with a
guaranteed rate of 10 to 15 pictures per second). The system
is however limited to simple terrain models with a constant
triangle size.
3 3D DATABASE DESIGN
3.1 Relational versus object oriented databases
Currently, most GISs are implemented either using relational
databases (RDBs) or using non standardized application-
specific databases [Sin 93]. The main reason for this
fact is that nearly no commercial object oriented databases
(OODBs) were available until about five years ago.
The disadvantages of RDBs become obvious with a close look
to the nature of GIS data: Broadly, GIS data means arbitrary
data types including numeric and short string data, large un-
structured data such as textures, complex structured data
such as the 3D geometry of buildings and finally compound
objects that are comprised of such data.
RDBs lack the mechanism to deal with this kind of data:
Their tabular approach does not allow a suitable modeling
of complex hierarchical objects. Although most RDBs sup-
port binary large objects (BLOBs) to store graphical data
(e.g. textures), these cannot be queried in the same way as
other data types. Besides, most RDBs suffer from a severe
performance loss if many BLOBs are used.
In contrast, OODBs allows building complex hierarchical data
models easily. (Most commercial OODBs offer native support
for C++ and allow to store any kind of objects that can
be created with C++.) OODBs are optimized to deal with
binary data efficiently and offer much better performance in
this respect. All benefits of RDBs — an easy to use query
language, data distribution, networking, versioning — are still
available (although sometimes in a modified form; e.g. most
OODBs do not support SQL but improved dialects that offer
3 better handling of object). Thus, OODBs should be an
obvious choice for any new database system for a GIS.
3.2 Amounts of data to be expected
In September 1994 a city block with 28 buildings in Vienna
Was modeled in a pilot effort ([GMB 95], figure 1). It took
199
about 180 Mbytes to store this scenery with uncompressed
photo textures at a pixel size of 4 * 4cm?. More than 99
percent of this data was needed to store photo textures. First
experiments proved that it would be possible to compress
textures to about 3 percent of their original size without a
significant loss of quality.
Figure 1: One house of the Vienna pilot project
Since Vienna has 220000 buildings, this data set can be con-
sidered to represent P of the entire city. Extrapolating
these numbers, using image compression, considering some
overhead for indexing in the database etc. it should be possi-
ble to store a 3D GIS model of Vienna in 100 to 200 Gbytes.
This first approximation does not consider objects other than
buildings (e.g. plants, trees etc.). The interior courtyards
of buildings were neglected, too. Another important feature
that was dropped in this approximation would be versioning
(allowing to view the data at any stage/time since the start
of the database). Therefore, it seems a realistic assumption
to expect at least 500 Gbytes of data.
3.3 Visualization
During the past ten years a lot of effort has been invested
in improving the drawing speed of complex scenes, regarding
hardware (z-buffering, texturing etc.) as well as software (e.g.
LOD concept). These techniques do not solve the problems
that appear when dealing with really big models, though: at
the point where the entire scene can not be held in RAM any
longer, it is not the rendering the scene which turns out to
be the bottleneck, but rather retrieving the 3D data from a
database.
To allow interactive working with a big 3D GIS model, it
is crucial to minimize the amount of data transferred from
the database to the visualization software. It will be a main
function of the database to act as an intelligent filter, re-
ducing hundreds of Gbytes of available data to a flow of a
few Megabytes per second, that can actually be drawn in
realtime. (The exact amount of data that can be handled
depends primary on the rendering hardware. One important
key number is the number of textured triangles that can be
drawn per second.)
3.4 R-trees, bounding boxes and the LOD concept
R-trees have been established as one of the most important
data structures for indexing spatial data. Lots of 2D GIS ap-
plications rely on R-trees or on one of their variants. R-trees
consist of overlapping rectangles that embrace geometrical
objects (e.g. all houses of a district). R-trees can easily be
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B2. Vienna 1996
