International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B3. Istanbul 2004 
and Wang, 1999; Molenaar, 1992). In the topological 
model for geometric elements, are used as the elementary 
data types of geometrical part, and the relationships 
between geometric elements and object types are 
determined by five rules. FDS is a complete vector 
structure and shows powerful specifications for the 
presentation of topology, position and shape. The 
topology representation is benetical for topology queries 
among the geometric elements of an object, but to 
generate a FDS description of 3D objects is difficult, 
because FDS requires topological definitions between 
point and arc, arc and edge, edge and surface, edge and 
edge, etc., (Gruen and Wang, 1999). To overcome this 
situation, a modified facet model based on B-Rep, V3D 
has been proposed in (Gruen and Wang, 1999). This data 
model can be generated easily and is designed to adapt 
images as well. 
Our visualization and query tool for 3D city models, 
presented in this paper depends on the V3D model. This 
model can easily be represented by relational database 
approaches by using relational tables. In the next chapter, 
we give description of geometric and topological 
modelling structure of objects in our tool which is still 
under development. 
2. IMPLEMENTATION OF DATA STRUCTURE IN 
OUR 3D VISUALIZATION TOOL 
In our tool, as being primitive geometric objects we use point, 
line, surface and body objects (houseObject / solid object) as 
defined in V3D model. A body object is decomposed into 
surface objects (facets), a surface object is decomposed into line 
(edge) objects and line object is decomposed into point (vertex) 
objects hierarchically. And these are all defined as object 
classes. We define a house object as follows: 
struct houseObject 
int houseld; 
int wallRed,wallGreen,wallBlue; 
int roofRed,roofGreen,roofBlue; 
float labelX; 
float labelY ; 
float labelZ; 
Points* housePoints; 
CellArray *wallCells; 
CellArray *roofCells; 
PolyData *houseWalls; 
PolyData *houseRoofs; 
PolyDataMapper *houseWallMapper; 
PolyDataMapper *houseRoofMapper; 
Actor *houseWallActor; 
Actor *houseRoofActor; 
struct houseObject* nextHouse; 
struct houseObject* prevHouse; 
i 
j^ 
As seen in the structure definition, one house object contains all 
of the geometrical and topological information implicitly as a 
whole. In the structure, “Points” variable represents all of the 
vertex points of a house with point ids and point coordinates. 
“CellArray” variable represent all of the cells (faces) of the 
house with cell ids. PolyData uses points and cells and forms 
the houseObject in a polygonal model which is obtained with 
the integration of the points and cells. As being optional it is 
560 
provided to construct the cell links with the member function of 
the class PolyData. Thus, PolyData object will represent the 
links of the cells (i.e. linking topology of the cells) too. 
PolyDataMapper is used to prepare the PolyData for rendering 
purposes. Actor is used to manage rendering operations of the 
mapper such as rotation, scaling, coloring etc. Finally, actors 
are rendered in the rendering window on the screen. At this 
point, geometry and topolgy of the house object with its 
geometric primitives haven't been stored explicitly in a 
database yet. But however, at this point, it is possible to render 
house object and query some geometric properties of the 
houseObject's geometric primitives. For example, coordinates 
and id number of a picked/selected point with mouse from the 
render window, can be shown on the screen. As the same way, a 
picked cell’s id and its point ids can be listed too, and so etc. 
For the explicit storage of the topological relations between 
edges, faces, etc., user should ask the software to “build 
topology”. This will be explained in detail in the following 
sections. 
“houseld” member variable is the id code of a house object. 
This id number is used to link an object attribute table with 
thematic information related to house object, (e.g. surface area, 
volume of house, etc.). “labelX, labelY, labelZ” variables 
define the center of gravity of the bounding box of the 
houseObject. This label coordinate values are used for picking 
(selection) operations on the screen and finding related 
record(s) in the related attribute table(s). When one picks one or 
more house objects on the screen, bounding box(es) of the 
picked object(s) is/are returned with min and max coordinate 
values of the corner points. And label coordinates of the 
selected objects are computed and corresponding houseObject 
is searched in the memory and when found, houseld of the 
found object is handled. With this information, link between 
object geometry and attribute tables is constructed. Label 
coordinates serve as opposite work of houseld. In the house 
object structure, wall and roof geometry and topology are 
defined seperately and together. Thus, it is possible to make 
analysis and queries related to roofs and in a flexible way. 
Color components are used to represent the selection color of 
the house object. When a house object is selected it changes 
color with selection color defined by the user, and when 
unselected, it takes its original color properties. 
With the above structure, it is possible to selecet indivudial 
parts of house, such as edges, faces, vertex points etc. Thus this 
property facilitates the indivual queries of the decomposed 
cells. Deletion of an existing part or adding new components 
are also easy with this description. CellArray class instance 
variable represents the definition of each facet cells and their 
topological links. 
In the memory, we organize all house objects in a double sided 
binary tree. In Figure 1, we give the organisation of the house 
objects in a binary tree model. 
In 
  
In 
an 
thi 
th 
se 
ad 
lin 
Ne 
me