Implementation and Visualization of Discrete Computational Geometry Using Database Managers

Database manager systems (DBMS) have been traditionally used for handling economic and alpha-numeric information, related to business, government, education, health, urbanism, etc. Making 3D geometry and topology and their related algorithms the raw material and subject of DBMS is rare. Attempts have been made in the specific field of Geographic Information Systems (GIS). However, for historical and economical reasons 3D geometry and topology was appended on top of 2D entities. The mechanism found is usually the addition of 3D information in the form of attributes for, for example, vertical extrusions of 2D entities. The related algorithms usually handle the interrogations and constructs of GIS, even though some GIS systems contain3D geometry and Topology, in the sense of Geometric Modelling. This manuscript presents the usage of DBMS graph capabilities for approximation of hard core computational geometry algorithms. This rarely used approach has the advantage of avoiding degenerate situations, at the price of lower precision. Taping into the vast graph capabilities of DBMSs has the obvious advantage of large algorithm libraries, which in this case we apply to computational geometry. The lower geometric precision of graph-based DBMS algorithms do not hamper their application, in problems of dimensional reduction, mesh parameterization and segmentation, etc. This manuscript is also attractive in that it illustrates the articulation of freeware display systems (e.g. JavaView) with DBMS for computational geometry applications. Keyword Geometry Databases, Topology Operations, Computational Geometry, Graph Databases, Triangular Manifolds GLOSSARY TIN Triangulated Irregular Network, used in this work to express terrain topography. DBMS Database Manager System GIS Geographic Information System


I. INTRODUCTION
Algorithms and constructions in Computational Geometry are usually served by dedicated CAD or similar software or libraries. In the particular case of Piecewise Linear SHELLs, LOOPs, etc. (e.g. in triangular meshes), floating point computations are conducted to calculate discrete counterparts of smooth operators (normal vector, derivatives, geodesic curves, etc.). However, it is not frequent the usage of database operations and interrogations on the 3D mesh graph to respond constructive or boolean queries on the mesh. As an example, geodesic curves between vertices v p and v q are usually calculated by using the fact that their acceleration is always parallel to the vector locally normal to the mesh. As an example, geodesic curves are rarely approximated by finding a shortest path between nodes v p and v q of the mesh graph.
The usage of constructors and queries on the mesh graph has the advantage of avoiding degenerate cases (e.g. the geodesic hitting a mesh VERTEX or flowing along a triangle EDGE). The obvious disadvantage is that discrete graph operators are approximations coarser than the floating point computations on the already approximated PL mesh. However, these approximations are still good enough for mesh operations. As an example, the dimensionality reduction of IsoMap [20] can be used as a mesh parameterization tool and the shortest path approximation of geodesics in IsoMap is good enough to find a parameterization for quasidevelopable meshes. Failures of IsoMap are not due to the coarse graph approximation of geodesic curves. Instead,holes or to the non-developable character of the mesh hinder IsoMap performance [15].
In addition to the attractiveness of discrete interrogations and constructions on a 3D mesh graph, there is the additional advantage of these operations being possible as Database operations. For that purpose, the 3D mesh has to be structured as a database. Although this is an apparently straightforward task, the correct database declaration (e.g. in Oracle TM ) of separate Topology and Geometry of a 3D mesh is not a trivial one, due to a historical bias in favour of (a) 2D entities (node, polyline) and (b)geographical TIN format for3D meshes. The TIN format (i) only serves meshes which represent surfaces z=f(x,y), excluding all meshes that are the boundary ∂B of a solid body B, and, (ii) assumes a connectivity (Topology) dictated by proximity of vertex projections on the XY plane and thus rejects the actual connectivity of the 3D mesh.
In response to these opportunities, this manuscript shows the conjunction between database resources (.e.g Oracle TM -Spatial, -Graph and -Point Cloud) and visualization tools (e.g. JavaView TM [11]), to implement discrete counterparts of computational geometry floating point constructs. The emphasis is set on the usage ofas far as possible-freeware tools (e.g. JavaView TM ). A. Terminology 1) Topology and Geometry in Computational Geometry.
In Computational Geometry, the term geometries refers to points p: R 0  R 3 , curves C: R 1  R 3 and surfaces S: R 2  R 3 . The term topologies refer to the connectivity among the three basic ones VERTEX, EDGE, FACE, which are subsets of the geometries point, curve, surface, respectively. The connectivity among topologies is expressed on the terms BODY, LUMP, SHELL, FACE, LOOP, EDGE, VERTEX. The term Edge relates to an Oracle TM name, while the term EDGE relates to the classic solid modelling topology.

2) Topology and Geometry in Oracle TM .
Oracle TM Spatial [3] calls geometries the basic types point and polyline. On the other hand, Oracle TM topologies may be either: (a) simple topological types (node, edge, face), (b) composite types built by using the simple topological types (node, edge, face) , and (c) attributes of geometrical data (e.g. 'park' applied to a 2D polygonal region or 'street' applied to a polyline).

3) Topology and Geometry in Graphs.
In graphs, the term topology refers to the connectivity among graph nodes. The term geometry is not directly expressed in graphs. A graph might have a geometric incarnation but geometric information such as location, size, orientation, etc. is not usually considered as inherent graph information.
In this manuscript, we will in general refer to topology and geometry in the classic sense of Computational Geometry. In specific locations in which the context is explicit (e.g. Oracle TM ), a clear warning will be issued for the reader. 4) Manifold Condition.
A set M⊂R 3 is a 2-manifold [18] if for each point p ∊ M there exists a  ∊ R + such that for all radius r with 0 < r < , B(p,r) ∩ M is isomorphic to the disk S 2 . Informally, this definition denotes a closed or watertight shell, which presents no self-intersections. It indicates that all neighbourhoods of M are bijectively similar to, or deformable into, flat 0-thickness disks.

5) High Quality Triangular Mesh
This mesh contains quasi-equilateral triangles, whose minimal EDGE length  satisfies ≤ ( min / 2), where  min is the smallest geometric detail of the original BODY boundary (skin of a solid) that its sample M is able to detect or preserve (Nyquist -Shannon Sampling Theorem [10], [16]).
This manuscript is organized as follows: section II examines the state of the art. Section III describes the methods that materialized our work, section IV describes the results obtained. Section V concludes the manuscript and discusses possible new research directions.

II. STATE OF THE ART A. Oracle TM Triangulated Irregular Network (TIN) Libraries.
This section explores existing Database and Libraries or Oracle TM (i.e. PL/SQL) in order to construct a connection capacity between 3D geometry Viewers and Spatial databases. It must be noticed that commercial software may be used as viewer (e.g. MicroStation TM ) , but it is usually expensive and with other emphasis in the final goal. The freeware JavaView TM is used here as an alternative. The final goal is obviously to use the TIN representation to support 3D computational geometry constructs and related interrogation algorithms.
The Oracle TM -TIN library (SDO_TIN_PKG) was used to import the legal 2-manifold CAT model ( Fig.  1(a)).A TIN data set is only able to import the geometry (i.e. vertex positions, Fig. 1(b)), and the result is an incorrect object representation ( Fig. 1(c)), due to the fact that TIN does not accept importing connectivity information. Instead, TIN establishes an (x,y)-Delaunay vertex connectivity, derived from proximity of vertices in the XY plane (i.e. ignoring the $z$ coordinate).In addition, TIN only handles surfaces z=f( x, y ) (i.e. having at most a unique z value for a given 2D location ( x, y )). These limitations make TIN un-suitable for representing general triangular meshes. As the TIN representation collapses, any subsequent query or derived object algorithm does not proceed.
One concludes that, within a database environment, an alternative to the TIN formalism is required, which allow for the explicit declaration of vertex connectivity. A possibility explored later in this manuscript is the Point Cloud Oracle TM (SDO_PC_PKG) data type.
(b) Geometry Alone. (c) Wrong Topology inferred from VERTEX closest neighbours according to distance projected onto the XY plane.

B. Oracle TM Database Topology and Geometry
In Oracle TM , a Node has an associated( x, y ) pair. An Edge supports 2 or more Nodes. Edges do not include circular arcs. A Face is built by one or more Edge loops. Each Edge may contain the information of incident Faces. There may be island entities (Edge loops, Edges, Nodes) inside a Face.
As in a Wing Edge data structure [8], the concepts of NEXT LEFT, PREVIOUS LEFT, NEXT RIGHT, PREVIOUS RIGHT exist in Oracle TM . An indirect guarantee for manifold condition exists in the fact that there may be at most one NEXT or PREVIOUS Edge for a given Edge, both in the right and left directions (e.g. there can be no 2 NEXT LEFT Edges for a given Edge). This is a 2D world, with a primigenial Face created (with id = -1), and it is the universe on which all Nodes, Edges and Faces are contained. This topology has no geometry associated with it. A loop Edge is an Edge whose initial and final Node are the same. A loop Edge may have intermediate nodes. This means that a closed circuit may be represented by using one Edge.
In Oracle TM , the name Topology Geometry is what Computer Aided Design and Manufacture call a feature. For example, a vehicular roundpoint or traffic roundabout [13] is a feature or topology geometry, made by a particular combination of Edges.

C. GIS Databases.
Reference [17] examines the extension to 3D of 2D geometry and topology primitives already present in GIS software and DBMS. An approach is proposed which amends the 2D polyline and XY-plane polygons to assume diverse z coordinates. Discussion also touches the usage of CGS modelling applied to GIS entities. This reference does not discuss graph operators for 2D or 3D GIS. Notice that the triangle -based Boundary Representation (a) is general and sound in geometric and topological terms, (b) allows for the most sophisticated scientific simulations (since it is based on 0-, 1-, 2-and 3-simplexes, base of Finite Element Analysis) and (c) has direct application in visualization, additive manufacturing, calculation of mass properties, etc. Triangular B-Reps are naturally representable by graphs, thus accepting tools present in Graph libraries of DBMS.
Reference [5] attempts the extension to 3D of 2D approximations stored of GIS objects, by using objectrelational databases. This reference proposes a relational DBMS equivalent to a flat -polygon -based Boundary Representation. However, the 3D model is not implemented. An example query of region proximity / intersection based on bounding boxes is presented. The long-term goal is to implement a 3D model of GIS systems, but it is not discussed in this reference. The reference does not use Graph operators nor exploits the flexibility of 0-, 1-, 2-simplicial complexes for full 3D representation (i.e. quadrangular / triangular meshes).
Reference [19] explores editing and visualization of 3D data in GIS databases. The visualization by commercial packages (e.g. MicroStation TM ) is possible, but it is economically expensive and computationally cumbersome. This reference cites VRML as a possible way for visualization. However, VRML does not solve the problem of editing, as it is usually a model -to -image unidirectional solution.
The reference finds that3D primitives not supported by the DBMS. This limitation leads to exotic behaviour, such as impossibility to handle vertical Faces (a problem already encountered in the TIN standard).

D. Graph-based Geometry Computations.
Reference [6] is an example of continuous domain computational algorithms which are approximated by a reasonable graph discrete counterpart. In this particular case, a curve is required in a continuous domain, on which a line integral of a penalty function is minimized. In this particular case, the anisotropic penalty function depends on the position and tangent vector on the curve. The authors show that such a problem has an approximate solution if the function and curve domains are represented by a graph. The optimal curve is the shortest path on the synthesized graph.
Reference [20] presents a graph minimal path variant for the calculation of geodesic curves in an mdimensional manifold M embedded in R n with n > m. This graph -based distance measured on the m-manifold is used to assess an isometric map MR m . In the case n=3 and m=2 this dimensional reduction algorithm constitutes in fact a mesh parameterization [15].
Reference [9} surveys data structures used in GIS. References [21] (Simplified Spatial Model -SSM) and [2] (Urban Data Model -UDM) appear as the earliest data structures that are topologically complete for expressing flat face 3D BODYs and SHELLs. The representation uses the concepts of BODY, SHELL, FACE, LOOP, EDGE and VERTEX (possibly with other names). No mention is made respect to the usage of DBMS to implement such structures. This survey expressly favours Object Oriented over Relational databases, and does not include a discussion on any concrete database. Reference [12] in the survey addresses the time stamps of the database to register the history of the sites and estates. However, no reference is made to actually using the database for the storage of 3D full topological / geometrical information.

E. Conclusions of Literature Review.
The reviewed literature shows that, possibly for historic reasons, Geographic Information Systems consumed spatial services from databases. Therefore, the spatial topology and geometry were oriented to serve 2D versions of features of a GIS system (roads, plots, parcels, rivers, lakes, etc.). Then, features and additional information (taxes, price, people) was hanged to these features, which is naturally stored in a DBMS. Then, a drive for 3D modelling was experienced for 3D spatial databases, but it collided against an already essential 2D structure. As an example, 3D topology cannot be stored in TIN format, since TIN topology is dictated by 2D proximity. This absence of full 3D topological and geometrical representation in DBMS domain is also visible in the absence of computational geometry algorithms actually mounted on DBMS -geometry based software. Our manuscript responds to such void, taping from the DBMS Graph libraries, with the expectation that more CAD, CAM or Reverse Engineering SW may actually be placed in DBMS.
According to the reviewed literature, we find that the following features of our manuscript are attractive for the reader: (a) replacement of the default TIN topology in OracleTM Spatial by the actual mesh topology. This replacement is conducted here by using additional relation declarations of Logical Network of the OracleTM Spatial database. (b) Implementation of the Boundary Representation Wing-Edge data structure [8] by using the spatial database. (c) Replacement of floating-point operations on 3D meshes (e.g. Geodesic curves) with discrete approximations (e.g. Shortest Path) of Graph Operations mounted on a spatial Database. (d) Additional operations / constructs on the B-Rep Graph mounted on spatial databases (e.g. Minimal Spanning Tree). (e) Usage of JavaViewTM for end-user interaction as either (1) Master, which uses the services of a Database server or (2) Visualization Server, subordinated to a Master Database application.

A. Implementation.
The present section reports the implementation and results of module articulation as per Fig. 2. A standard database (e.g. Oracle TM ) appears as foundation. On top of this database, an abstraction (Oracle TM Spatial) is built, in which the entities have geometric meaning. Likewise, the Graph abstraction to implemented (e.g. Oracle TM Graphs). Both, Oracle TM Spatial and Oracle TM Graphs are provided by Oracle TM . On top of them, we built the abstraction of a Boundary Representation(B-Rep) which is a standard formalism for solid and 3D SHELLs description. For the purposes of illustration, we have chosen to implement 2 different discrete approximations of Geodesic Curves on the 3D mesh. We do not implement a floating point PL approach (briefly commented in section I). Instead, we use the discrete approximation of Geodesic Curves made possible by the B-Rep on top of Oracle TM Spatial and Oracle TM Graphs.

B. Required Topology Constructors and Queries.
The SW component structure shown in Fig. 2 supports the following functionality by a combination of the database, its functions and its additional SW layers.

initial_vertex(EDGE):
 The interrogation owner_edge(VERTEX):  EDGE} returns any EDGE for which the given VERTEX is the head. Consistently, the interrogation incident_edges(VERTEX):  [EDGE] returns a CW-or CCW-ordered sequence of EDGEs, incident to the given VERTEX. Fig. 3 represents 3 different B-Rep graph construction processes, with mixed success results, implemented for the present manuscript. A pre-condition is, of course, the existence of a 3D 2-manifold triangular mesh M. Although it is not a requisite for 2-manifold condition, the used mesh is closed or watertight and thus contains no border. A necessary step to declare the 3D mesh M inside Oracle TM is the importation of Geometry and Topology information.

C. B-Rep Database and Interface Architecture. 6) Construction of B-Rep Database and Graph.
As established in the Literature Review section, declaring a Topology (i.e. connectivity) in the TIN standard is not possible, ending up in an illegal situation. The TIN option connects a VERTEX v with the neighbour ones that are closest according to their separation with v, projected on the XY plane. TIN assumes that M represents a surface z = f( x, y ), with f: R 2 R being a function. Therefore, TIN excludes, among others, meshes M which represent the boundary of a solid region. Typically, TIN allows only terrain -like digitisations. Fig. 1(a) shows the Cat data set. Fig. 1(b) shows the Geometry (point set) as imported and inserted in Oracle TM . Fig. 1(c) displays the defective Topology that Oracle TM TIN infers from the Geometry. Declaring an arbitrary Topology in Oracle TM implies to ignore the TIN standard and instead to declare the actual Topology via a Oracle TM Graph. The Geometry (point set) is still declared via Oracle TM Point Cloud. Our implementation compares two graphs: (a) with EDGEs having unitary weight, (b) with EDGEs whose weight is their Euclidean length. 7) Graphical User Interface. JavaView TM Fig. 4 displays an implementation of the Graphic User Interface, using JavaView TM . The user interacts with, and receives feedback from, the JavaView TM client. This client passes the queries to a Computational Geometry application. In this report, the particular case of discrete approximation of geodesic curves on the mesh M is conducted. The application communicates the relevant interrogations to a translator Java/Database, which expresses the interrogations in terms of the Graph and Database operations. The database responds with the query / construct result, which is then translated into the data structures of the Computational Geometry Application and into Java commands, for human visualization.

D. Background on Mesh Geodesics.
The purpose of this section is to give a short background on the Computational Geometry problem which serves as an example for our discrete approximation by using the Oracle TM Graph and JavaView TM capabilities. In this case, we consider the problem of finding a discrete approximation for the geodesic curve that joints two points of a surface M. The geodesic curve remains on M and has the property of being straight within M and thus uses a minimal length for joining these two points on M. For the purpose of completeness, we briefly discuss geodesic curves on a PL triangular mesh M. For interesting discussions of geodesics, see [34]. (a,b). The geodesic curve, on a surface, joining two points of that surface is in general not unique (for both PL and smooth surfaces).  There exist particular cases, in which the geodesic hits a VERTEX or aligns itself with an EDGE. Notice that such cases do not appear if the geodesic is approximated by the shortest or lowest cost paths between the two vertices in question.      8 shows two low quality data set meshes M (Cat and Antelope). For each data set, 2 graph -geodesic approximations are shown: (a) by a path with minimal EDGE count, (b) by a path with minimal distance. The two approximations render different paths. A reasonable expectation is that, as the triangulations have better quality, the two paths will converge to one, and they will converge to the PL curve obtained with the floating point geodesic calculation.  Fig. 9 shows a higher quality data set mesh M, called Vertebra. Fig. 9(a) shows illustrative paths from VERTEX v 0 to two VERTEXes v 1

PL Geodesic. A PL path :[a,b] M is a piecewise linear geodesic curve on M if and only if ''(t) is parallel to the vector normal to M, n((t)), for each t in the interval
If a second vertex v 2 is chosen, such that its geodesic distance to v 0 equals the distance from v 0 to v 1 (Eq. 3), one has the situation of Fig.9(a). Notice that the colour texture in Fig.9(a) Notice that the E M ( ) count of minimal path EDGEs does not represent a distance unless multiplied by the length of the EDGE (assumed constant in a High Quality Triangular Mesh). Table I   Homogeneous EDGE length meshes are not a rarity, since tasks such as mesh segmentation and parameterization are very difficult with other meshes. Meshes with non-homogeneous EDGE length are convenient for data reduction, but are very counter-productive for mesh segmentation and parameterization.  Fig. 10 displays several nearly iso-length paths (green colour) from an origin node in the Vertebra data set. As expected, the locus of the path end vertices approximates the geodesic iso-distance map of Fig. 9. Fig. 10 also shows iso-step paths, which are based on the number of edges traversed (assuming nearly constant edge length). As the triangulation improves in quality (small constant size EDGEs forming equilateral triangles), the iso-length and iso-step paths tend to be the same. The yellow strip represents a vertex set reached by paths which start from vertex v 0 and reach vertices whose lengths are in a given interval. Notice the (expected) resemblance with the iso geodesic lengths of Fig. 9(a). G. Minimal Cost Spanning Tree on M. Fig. 11 presents the Minimal Cost Spanning Tree for the Vertebra data set. This result is also achieved using the Oracle TM Point Cloud type (for the geometry data), supplemented with the Oracle TM -Graph tables (for the topology or connectivity) and algorithm. The display is executed in JavaView TM .

V. CONCLUSIONS AND FUTURE WORK
This manuscript presented an articulation of database types and algorithmic, for the purpose of treating computational geometry and topology as other usual database information (client, payroll, assets, debt, address, etc.). This work has relevance given that spatial databases, mostly related to GIS, historically deal with 2D entities (parcel, road, block, highway, bay) and only ad-hoc incorporate 3D information.
The manuscript remarks the usefulness of database operators (e.g. graphs) given the fact that many interrogations and constructs in 3D Computational Geometry may be defined or approximated in terms of graph operations. A specific example is presented, of the geodesic field on a manifold triangular mesh M, which can be approximated by shortest path interrogations in a high-quality mesh M. High-quality meshes are compulsory for mesh segmentation and parameterization. Thus, the application pre-conditions for graph operations do not seem overly demanding.
This manuscript presents an added value of tool articulation, by including the application of JavaView TM to serve as interface with the DBMS and with the Graphic User Interface. The facts that JavaView TM is open software and database managers may be also found as open, indicate the possibility of cost-effective articulation of open tools for large data set computational geometry.