Full text: Proceedings, XXth congress (Part 3)

'anbul 2004 
function of 
present the 
cells) too. 
r rendering 
tions of the 
ally, actors 
en. At this 
ct with its 
citly in a 
le to render 
ties of the 
coordinates 
se from the 
ame way, a 
and so etc. 
ns between 
to “build 
> following 
use object. 
table with 
irface area, 
* variables 
ox of the 
for picking 
ng related 
icks one or 
(es) of the 
coordinate 
tes of the 
ouseObject 
Seld of the 
ik. between 
ted. Label 
the house 
pology are 
le to make 
xible way. 
jn color of 
it changes 
and when 
indivudial 
.. Thus this 
ecomposed 
omponents 
ss instance 
s and their 
yuble sided 
the house 
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B3. Istanbul 2004 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
— >| root 
y 
» | Ist house »| 2nd house 
La . . . . 
object with object with 
member member 
variables variables 
end 
-——-iprev |. next prev | next A 
  
  
  
Figure 1. Organisation of house object in a binary tree 
In Figure 1, each node of binary tree corresponds a house object 
and each node shows where the previous and next houses are in 
the memory, by using prevHouse and nextHouse pointers. With 
these pointers, each nodes are linked each other for the fast 
search tasks. In the above tree, a new house object can easily be 
added at the end of the tree by allocating necessary memory and 
linking this new memory area with the previous house object. 
Now, we can give the detailed description of one individual 
house object by defining both its geometry and topology. As 
mentioned before, points, cell arrays, poly data, mappers and 
actors are used. Mapper and actor is used for 3D visualization 
purposes, in order to present the data to graphical environment 
for rendering purposes and well known from computer graphics 
and 3D visualization libraries such as OpenGL, and 
visualization toolkit, (Scroeder, 1998). Relations between points 
and cells are shown in Figure 2. 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
Coord | ID ID typeo nCells, 
X 
y 0 n offset, cells 
Z 
x Po typei nCells; 
y | ffse cells 
Z ww P, offset, elis, 
: n 
X typem-1 nCells,., 
y n-1 4 Po N 
Z offset, cells, 
points cells cell types cells links 
Figure 2. Implicit representation of geometry and topology 
By using cell types, random access to each cell is provided. 
Above structure can easily be converted to relational model in 
our tool. For this purpose, from the main menu, “build 
topology" command should be selected. In this case, the 
topological relations of objects are written to relational tables. 
3D City-VAQS, supports dBase and Paradox relational 
database management systems. In Figure 3, firstly we give the 
general representation of geometry and topology of 3D objects 
used in 3D-City VAQS and then in Figure 4, we give the 
relational database model representation. 
561 
I 
Picking 
—— 
  
Geometry and 
implicit topology 
Texture 4 4 
map Topology in 
relational 
  
    
  
qp 
VII 
query results 
  
  
  
  
IH 
  
  
  
  
  
  
  
  
  
  
vy VI SalI made) 
= 5 (explicitly 
Show geometry of ES do stored) 
picked primitives = 
  
  
  
  
  
  
  
  
query 
—P 
€ 
id 
  
  
v 
V * 
Attribute Attribute 
information of information in 
relational 
  
object attribute table |a 
(can be indexed 
another tables) 
database with 
indexed tables 
  
  
  
  
  
  
Rendering properties 
  
  
  
  
  
Texture image 
  
  
  
Figure 3. General representation of geometry and topology 
With the representation shown in Figure 3, it is possible 
to manage the visualization tasks and database tasks in a 
flexible manner (independing and depending to each 
other). The box with number i in the figure represents the 
houseObject entities in the binary tree of visualization 
memory. This box wholly contains all of the member 
variables of houseObject entity. At this stage, even if the 
relational tables aren't created, the operations which are 
shown in the boxes with the numbers v, vi and vii are 
ready and effectively can be performed in the 3D 
visualization pipeline. I.e. this means, one can query the 
geometry of houseObject's geometric features such as 
point coordinates, id of any cell (face, edge, surface etc.) 
by picking on it with mouse on the render window. Here 
at this stage, only the volume and area of the houseObject 
can not be listed, since it requires additional volume and 
area computations and these computations are performed 
during the "building topology" process. Here, rendering 
properties of the objects can also be changed. For 
example; color, transparency, illumination conditions 
such as light, shading, reflection etc. Again at this point, 
only artificial textures can be mapped on to houseObject. 
Photorealistic texture mapping requires computation of 
texture coordinates, so photorealistic texture mapping can 
not be performed at this stage. It can be performed after 
building topology and with photogrammetric 
computations for obtaining texture coordinates. 
During topology building, object attribute table (OAT) is 
created. Each column of the OAT represents one attribute 
feature and each row represents one houseObject. In 
OAT table, “Internalld”, “Userld”, “FacetArea” and 
“Volume” items are created by the software 
  
 
	        
Waiting...

Note to user

Dear user,

In response to current developments in the web technology used by the Goobi viewer, the software no longer supports your browser.

Please use one of the following browsers to display this page correctly.

Thank you.