Full text: The 3rd ISPRS Workshop on Dynamic and Multi-Dimensional GIS & the 10th Annual Conference of CPGIS on Geoinformatics

ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS”, Bangkok, May 23-25, 2001 
236 
neighborhood relations of items consists of a list 
representation with four lists: a point list, an edge list, a surface 
list and an body list The advantage of a list representation is 
the compact storage of the items, since e g. each point is only 
stored once and then referenced by several edges. 
4 REQUIREMENTS ON A DATA STRUCTURE FOR A 
3D-GIS 
On the basis of the prior made considerations, on can 
formulate three basic requirements on a 3D GIS datastructure 
4.1 Vector data structure 
Even if the underlying data model is more complicated than a 
raster or a CSG approach, a vector data structure is more 
suitable. Today, most 2D-GIS base on a vector data structure 
It thus can be ensured by the selection of the vectorial 
approach, that already to a great extent available (vectorial) 
2D-data can be used without much change in the new 3D-GIS. 
4.2 Boundary Representation 
The B-Rep is the logical continuation of the node-edge data 
structure. It enables a topologically correct representation of 
the objects. Furthermore, with B-Rep not only solids can be 
modeled, but also further geometrical objects like surfaces, 
edges and nodes. Because e g. the surfaces of a solid object 
are again independent objects, attributes can be assigned to 
them individually. Besides, B-Rep permits a redundancy-free 
management of the geometric information and guarantees 
thus the data integrity at longer term. 
4.3 Topology 
Most analysis functions require the topology of an object. By 
using a B-Rep data model the topology is already to a large 
extent available and only few additional data, which can 
usually be computed at runtime is needed. 
5 IMPLEMENTATION OF A PROTOTYPE 3D-GIS 
At present we investigate in our research group a prototype of 
a 3D Vector-GIS called 'SOMAS' (Solid Object Management 
system). ). The main focus of the project is to develope and 
implement a suitable geometric and thematic data model, to 
optimise the data management (storage and access) and to 
get a tool for further investigation of 3D and 4D analysis 
functions. 
For several reasons we decided to store both, geometric and 
thematic data in a relational database (Fig. 4): First, we can 
model the objects with the relational method to a large extent 
redundancy-free, and secondly databases offer different tools 
for garanteeing the data integrity and security, the data access 
and memory optimization. 
The geometric model is the fundament of every GIS. Therefore 
it must be modeled very carefully. The possibilities 
(functionality) and the performance of a GIS highly depend on 
an efficient geometric data structure. The use of a relational 
model for the geometric data enables us on the one hand to 
reduce or even avoid data redundancy and on the other hand 
to store topological and metrical information in separate tables, 
so we either can access the topologic information only (its 
useful for some operations) or we get topology and metric for a 
complete representation of the objects. The reduction of 
redundancy means for example, that we only need to save a 
small limited number of topological relations explicitly. The 
other relations either are implemented with relations 
(constraints) or can be computed quite easily. 
In the data model presented the only table containing metrical 
information ist the table 'vertex'. All other geometry-related 
tables contain only topologic information. The realization of the 
before described list representation with a relational data 
model requires some additional tables for dissolving the 
multiple-multiple relations. E.g. the relation between points and 
edges looks as follows: A point can be member of one or 
several edges and an edge consists of several points. 
Datano*! Edit Vl eu Database 
! Cowunal.GIS 
-¡3 BUILDING 
-li GEOLOGY 
-23 aaxjNiMSTER 
-23 PLANING.ZOIC 
-S3 RIVER 
-33 STREET 
TREE.REG1STER 
T-’Vise 
F 7 * HEIGHT 
— 
z^mmmrn 
Help j 
Entity | Attributes j Graphic* j 
Enable eystee attribute« 
N0 SYSTEM ATTRIBUTES 
Attribute none 
[bl(»ETER_CRO« 
: Attribute type 
jÄÜST" 
Leogth 
No of DeciMl pieces 
""•* Pii 
i Fils Edit The»e view Query 
Help j 
Fig. 5: Screenshot of SOMAS (Solid Object MAnagement System)
	        
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.