in 3D
gs
qae x
ls are
ons)
m (a big
Iding will
ding and
as more
from the
speaking,
1b-tree of
al, spatial
. Search-
e R-tree.
few small
id objects
-tree only
xes), e.g.
D R-trees
box does
-trees ap-
d or cone
e needed
htforward
mplex ge-
any query
result in
t of them
| for visu-
the query
llel boxes.
5 in a con-
siderably higher volume, as the boxes need to fully embrace
the pyramid of vision. On the plus side, queries for objects
within the resulting boxes can be done much faster — all you
need is simple bounding box tests. Besides, it is possible to
process queries for different boxes in different ways (figure
3): The first query would only consider the box nearest to
the point of view. With the resulting objects a first visual-
ization can already be done. In the meantime, objects for
boxes far away from the point of view can be queried. As
these objects distribute less information (foreshortening), the
query can be stopped at a higher level in the R-tree. (This is
equivalent to a lower level of detail.) Thus, perspective query
does not mean simply retrieving all objects within a pyramid
of vision; the LOD concept is also involved — otherwise its
implementation on database level would not make sense.
/
pyramid of vision
(2D projection)
query for objects far away from
the viewpoint, low LOD
query for objects in some distance
form the viewpoint, medium LOD
viewpoint query for objects near the
viewpoint, high LOD
Figure 3: Successive queries for objects within the
pyramid of vision; the figure shows a 2D projection of
the 3D pyramid and its bounding boxes :
3.7 Handling textures
As was mentioned above, in a first pilot project, uncom-
pressed photo textures consumed more than 99 percent of
the models memory. Simply compressing this textures with
JPEG or another algorithm results in considerably smaller
memory demands. To avoid a tradeoff in speed, the textures
used most recently should be cached uncompressed by the
database. A simple LRU (least recently used) algorithm to-
gether with a variable cache size limit might be used to decide
which bitmaps may stay uncompressed in the cache.
To support LOD, textures will be stored as multi resolution
bitmaps (bitmap pyramids). As the cache size is always a
limiting factor, it is neccesary to cache bitmaps in a low LOD
if memory restrictions do not allow to cache them in higher
quality. This would allow a fast visualization at low quality.
If higher quality is needed, compressed bitmaps need to be
reloaded and decompressed again.
4 IMPLEMENTATION ISSUES
41 The CyberCity project
The above described database will be one cornerstone of the
CyberCity project. In this project the Institute for Computer
Graphics in Graz is developing techniques to store, manipu-
late and visualize three dimensional data of urban environ-
ments. Important research tasks apart from the database are
(semi-) automatic 3D object reconstruction from available
2D GIS data and aerial images, texture extraction from aerial
images and facade photographs [GPL 95], object refinement
201
(geometric modeling) from facade photographs, development
of a line camera to do facade photographs more efficiently
[MD 96] etc.
4.2 Software and data format standards
Of course it is tempting to restart software development from
scratch: This would result in an optimal performance and
in software modules fitting together. However, this would
also mean spending years of manpower to write code that
has already been written in a similar form, defining another
data format incompatible to all previous ones. To avoid these
drawbacks, CyberCity will rely as much as possible on existing
standards:
e Graphical data as well as GIS data will be stored using
a commercial object oriented database system (possibly
ObjectStore or O»).
e The database will be able to import and export Open
Inventor files. Therefore, any program supporting Open
Inventor can be used for modeling or for visualization.
Although the development of the database has a GIS applica-
tion in mind, the database might also turn out to be a good
starting point for a more general VRML database.
4.3 Current work
At the moment, the OODBs ObjectStore and O» are being
used for experiments in perspective querying. A test program
to benchmark bounding box queries in an LOD-R-tree already
exists (figure 4). No final decision has been made yet about
which database system to use, though.
SceneViewer (Examiner)
Figure 4: A test database consisting of 3000 empty
bounding boxes organized in a r-tree was queried for
cubes in the front octant. The result was visualized
using Open Inventor.
At the same time, software is being developed to build a low-
detail model of Vienna (figure 5). The model is based on a
manual analysis of aerial photographs of Vienna. For each
building or building complex, a polygon defining the eaves
and one base point is available. Out of this data, a converter
builds 3D objects for each building and digital terrain model
(DTM). Incorrect objects (e.g. duplicate points, intersecting
polygons etc.) are either corrected or skipped. A test dataset
consisting of more than 10000 buildings will be used to test
the first implementation of the database.
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B2. Vienna 1996
