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)
