Sisi Zlatanova
Associate Professor,
Delft University of Technology,
The Netherlands
[email protected]nl
GIS, CAD & DBMS systems used to differ significantly. Initially,CAD systems were intended to provide 3D tools for the design of relatively small models (constructions,industrial parts,cars, etc.) in local coordinate systems.

Since it was design software, a lot of emphasis was given to editing tools and effective 3D visualization. By contrast, GIS was developed to represent the real world, and more specifically all the tasks that used to be performed on 2D paper maps. DBMS systems were designed to manage in an efficient and secure way large amounts of text and numerical data as no attention was paid on spatial information. In the last years mainstream DBMS have provided spatial support but still the data types are limited to the simple data types as described in the OGC Implementation Specifications. Presently, many applications have been looking for possibilities to bring together attractive properties from the three different environments, such as complex shapes from CAD systems, elaborated spatial analysis from GIS systems and ability to manage large data sets from DBMS. Examples are large civil engineering works, medical and geological applications.

A number of developments, technology or application driven, have contributed to the better exchange of spatial data between CAD and GIS based on agreed well-known industrial file formats (such as dxf, shape, dwg, etc). Open Geospatial Consortium (OGC), within its interoperability program, has reported successful tests allowing the access and visualization of CityGML models (OWS-4) and buildings represented in Industrial Foundation Classes (IFC). Following this approach simple CAD and GIS models can be visualized in one (web) environment.

Much of attention is given to integrating CAD/GIS and spatial DBMS. Diverse data models and data types have been investigated to be considered in DBMS as well and some of them have been tested in a prototype environment. Despite some progress in management of simple geometries, it is still a challenge to maintain complex CAD geometries (such as cones, spheres, B-splines curves and surfaces) in DBMS.

In the last years we have experimenting with extending the functionality of DBMS with complex data types such as Bézier, Bspline and Non-uniform rational B-spline (NURBS) curves and surfaces. Why exactly these types? Firstly they are increasingly used in the design process and for modeling of complex real-world surfaces (terrain or geology). Secondly they all are parametric functions and as such they allow for more compact data storage compared to triangulated surfaces and meshes.

The simplest of the three methods to represent a freeform curve is the Bézier curve. Its shape is basically defined by a sequence of n+1 control points Pi (i=0..n) in 3D space. A Bézier surface is, similarly, defined by a grid of (n+1)*(m+1) control points Pi,j (i=0..n, j=0..m). One of the major problems with Bézier curves and surfaces is that it is usually preferable to keep the degrees low, i.e. not higher than 3 or 4, and complex shapes therefore have to be modelled by a composition of several curves or surfaces. This, in turn, requires specific configurations of control points to guarantee a certain order of continuity. B-spline curves and surfaces, which are generalizations of Bézier curves and surfaces, do not have this problem, because here the degree can be defined independently from the number of control points, and continuity of the curve or surface is realized automatically. A B-spline curve of degree p, or order k=p+1, is defined by a sequence of n+1 control points Pi (i=0..n) in 3D space, and a knot vector of n+k+1 knots. It is a piecewise polynomial curve. NURBS are a generalization of B-splines. The main difference between NURBS and Bsplines is that the control points of a NURBS curve or surface each have a weight, which determines how much the control point contributes to the curve or surface. This gives extra degrees of freedom for modeling. Altogether, the NURBS method is one of the most powerful methods for representing freeform curves and surfaces.

Figure 1. UML diagram of implemented data types


The new geometries are designed as individual data types with OCC specifications, i.e. as separate data types (Figure 1). The two major advantages of mapping the conceptual model into separate freeform data types are – the data types are clearly and explicitly defined, and little redundant information is stored since every data type has its own attribute. Adapted data types can easily be inherited from existing prototypes, and functions on prototype types will be also operational for inherited types.

The implementation is done in Oracle Spatial, but the approach is applicable for any DBMS. New data types can be designed in Oracle using natively supported data types, such as object types, REFs, VARRAYs, and Nested tables. The userdefined data types in Oracle can be declared using the SQL statement CREATE TYPE. PL/SQL, Java or C++ can be used to implement the declaration. In implementation, Java has been selected because it supports Oracle Spatial well. The procedure for creating data types using Java can be divided into three main steps: creating Java classes, loading the classes in Oracle spatial and declaring the data types in Oracle using the SQL statement CREATE TYPE.


Figure 2.A cross road (left: CAD model in MicroStation; right: GIS model in ArcGIS)

Assuming that freeform curves and surfaces should be dealt with as any other geometry data type (although more complex), operators similar to those for simple features have to be provided. This is to say that operations for validation, detecting topological relationships, metric computations (length, distance, area, etc.), proximity (distance between two features, objects within distance, etc.), operations creating new geometries (intersection, difference, union, buffer, etc.) might be considered. Validation, i.e. checking the correctness of geometry, is one of the most important functions. This function is also provided. In our case, the validation rules is derived from the geometry definition. This includes two levels of checking: first, the function checks whether all the parameters required are present (storage validity), i.e. coordinates for control points, degree value, weight values and knot vector; second, the basic mathematical requirements between parameters should also be satisfied (geometry validity). For NURBS curve the geometry validity rules are:

  • degree > 1,
  • number of control points >3,
  • degree = number of knots -number of control points- 1,
  • number of weight values is equal to the number of control points,
  • each weight value > 0,
  • knot vector is non-decreasing & has more than 1 knot,
  • upper trimming value > lower trimming value.

For example, a 4 degree NURBS curve with 3 knots and 5 control points doesn't exist in reality. A NURBS record with these values in the database is considered a bad record and can be detected with validation function.