Using VRML as an Interface to the 3D Data Warehouse






Full text


Using VRML as an Interface to the 3D Data Warehouse

Volker Coors and Volker Jung

Fraunhofer Institute for Computer Graphics


In its current state, VRML does not provide support for interaction and on-line access to databases, even though these are two fundamental issues for business applications. We have created GOOVI-3D, a prototype system that provides access and interaction with a 3-D spatial database over the WWW. GOOVI-3D is implemented in Java and VRML using CORBA for accessing the data warehouse. In an urban planning application, GOOVI-3D is used to interact with 3-D models of the city of Frankfurt. Based on the experience with GOOVI-3D, we propose two lightweight extensions of VRML that can make the development of business applications much easier: An integrated name dictionary management and a SQL node.

CR Categories and Subject Descriptors: H.3.3 [Information

Search and Retrieval]: interactive query formulation; H.4 [Infor-mation Systems Applications]: Geographic Infor[Infor-mation Systems, GIS; I.3.6 [Methodology and Techniques]: Languages, VRML; I.3.7 [Three-Dimensional Graphics and Realism]: Virtual Reality

Additional Keywords: Data Warehouse



The need for data warehouses (DW) that store and exchange corporate information has become obvious in the last years. Data warehouses reduce the data acquisition cost, make management decisions more efficient and also increase the transparency of the decisions made [6]. CORBA and the WWW are becoming powerful middleware and front-end technologies for DW and recently 3-D front-ends have been introduced that use VRML to explore and access data [13]. With new applications like urban planning it becomes even more important to incorporate VRML into the DW front-end, and make it deliver and interact with 3-D models of buildings and cities.

However, there is an obvious limit in the usefulness of VRML to interact with the 3D data warehouse. Just like the WWW itself, VRML was initially created for viewing data only, not for interac-tion. Therefore, it delivers the 3-D model of a city, but you cannot use it in an intuitive way to interact with the model and ask ques-tions as simple as: What are the name and address of this building? What is the safest way from this place to the kindergarten? A gen-uine information system should give the answer to the last question as a set of VRML nodes highlighted in the model.

Consequently, many of the major new developments concerning the WWW and VRML were meant to increase the interactiveness of this medium. VRML 2.0 [14] introduced touch sensors and inte-grated a Java language interface. JVerge [1] is a library on top of the External Authoring Interface [4] for representing VRML nodes as Java Objects that provides a basis for interactive use of VRML. Rohrer and Swing [12] give examples of systems that use VRML to deliver information spaces and achieve a minimal level of dy-namic update by CGI-programs.

Another very active area of research has been the coupling of mid-dleware technology, e.g. CORBA, and the WWW. Vogel [15] ar-gues that these are indeed complementary technologies creating a huge synergy effect. Koschel et al. [7] developed an architecture for environmental information systems that incorporate the WWW and CORBA. Duan [3] implemented HORB, a Java-based Object Re-quest Broker that is not CORBA-compliant but provides the low-level communications in a corporate environment.

Even with all this new research going on, VRML does not yet pro-vide support for real interaction and on-line access to databases, al-though these are arguably the two most fundamental problems that need to be solved for business applications. Using current VRML and CORBA technology we have created GOOVI-3D, a prototype system that provides access and interaction with a 3-D spatial data-base over the WWW. In an urban planning application, GOOVI-3D is used to interact with 3-D models of the city of Frankfurt. Building GOOVI-3D, it has become obvious to us that two lightweight ex-tensions of VRML can make the development of business applica-tions much easier: An integrated name dictionary management and an SQL node.






3D Geographic Information Systems (GIS) integrate a large amount of different data of the world’s geographical objects. This includes geometrical, topological and other thematic information. In most scenarios, e.g. in urban planning, the required data is not available in a single database. Rather, it is distributed over many {coors, jung},

Fraunhofer Institute for Computer Graphics D-64283 Darmstadt, Germany


specialized databases such as digital elevation models, land regis-ters, ecological data and so on. One aim of a data warehouse in the GIS context is to offer easy access to this entire information for each user.

GIS should be serviceable for people with various levels of comput-ing knowledge and available on different hardware platforms. Be-cause of its popularity the World Wide Web can be used to spread information to a multitude of users. A data warehouse front end should use the WWW also for greatly simplifying access to the geo-graphic information which is essential, especially for casual users. GOOVI-3D is such a system, which allows interactive access and visualization of 3D geographical information. This new architec-ture does not intend to create a new information system. Rather, the aim is to use available systems in order to allow data to be accessed flexibly, and transparently by the World Wide Web community. One of various application fields of GOOVI-3D is urban planning, where interested citizens participate in the planning process and in the decisions made. Citizens can access 3D-models of plans via WWW. However, visual information only is not enough to find one’s way around in the model and to evaluate the practical conse-quences. With GOOVI-3D, users can get additional information in-teractively, e.g. find a specific building or a safe way to the kindergarten.


System Architecture

The aim of GOOVI-3D is provide the user access to the information system via the WWW. Therefore the client software was realized using Java and VRML. It can be downloaded from the WWW and locally executed, thus allowing easy access to the data without in-stalling specific software on the client.

The interface of the data warehouse is provided through CORBA-IDL for getting homogeneous access to the entire geo-information. The client accesses the geo-data via this interface using the IIOP protocol. The data component is therefore independent of the re-maining system and thus easily interchangeable. Therefore, the front end software can be used to access other data warehouses with a suitable CORBA-IDL-Interface.

To minimize the amount of data transmitted, only a VRML repre-sentation of the geo-objects is sent to the client. Further information can be requested interactively. The GIS server extracts the queried data from a database and forwards it to the client.


Database Access

In the GIS context, there are two different classes of data queries both requiring interactive specification. The first one is focused on obtaining additional information about a selected object. Using VRML this can easily be done by a hyperlink to a HTML page or, more dynamically, by script nodes. A special field id can be used in this script to identify the selected object outside the VRML scene graph such as starting a database query.

The second kind of data query works in the opposite direction. The user searches objects which meet specific conditions (e.g. which building represents the Japan-Center). In this case the query results in a set of objects, identified by their objectid.

Consequently, the server has to access at least one database in order to answer these queries and send back the results to the user. This communication is implemented as a Java script node at the client’s side and the IDL interface of the server using IIOP.


Name Dictionary Management

For a visualization of the query results, e.g. by highlighting the re-sulting objects, it is essential to map the geo-objects to VRML nodes. There are two ways of performing this mapping. The first one is to route a result set to all VRML GeoObject-nodes. Each node checks whether it is an element of the result set or not. If this is the case, the GeoObject node will change its appearance into the highlight color for example. On a single processor hardware (which most WWW-Clients are), this algorithm is not very efficient. Each of the n nodes has to check the result set of cardinality m. The time complexity of the algorithm is in the order of O(n log m). Based on the assumption that m is much less than n (m << n), this is not the sensible choice to do the query result-VRML node mapping. An alternative algorithm is to search each result set’s objectid in the VRML scene graph. The algorithm’s time complexity is

O(m log n), which is much more efficient. However, this advantage will be lost, if the VRML scene graph has to be parsed each time

Figure 1: System Architecture of GOOVI-3D 3D GIS Server CORBA/IDL Interface IIOP geometry topology DB thematic data DB WWW Server GOOVI-3D in WWW-Browser GOOVI-3D in WWW-Browser


while searching a geo-object. This can be avoided by using another data structure optimized for managing the geo-objects.

The data structure can be built by parsing the VRML scene graph initially or, as it is done in GOOVI-3D, by extending the transfer protocol. In this case, the server does not send the whole VRML scene graph at once. Each geo-object is transmitted to the client separately, while sending the object identifier and its VRML representation (which might be null in special cases). The object identifier can be used to build the object management structure and the VRML description can be used to build the scene graph, using

CreateVrmlFromString(), by the client. Each element in the object

management structure is linked to its VRML presentation in the scene graph (Figure 2). Because the DEF/USE instancing is local, there is also a need for material and texture management to reuse these nodes and to keep the amount of transmitted data low. See Figure 3 for the protocol.

This name dictionary solves the task of mapping geo-objects to VRML nodes. As shown above, the query returns an object identi-fier such as japan. The name dictionary leads to the corresponding GeoObject node which then can be highlighted.


Using GOOVI-3D

Starting GOOVI-3D in a WWW browser results in getting a VRML scene graph containing only a script. This script opens a Java GUI where the user can specify several parameters to get a suitable mod-el (e.g. getting point normals, textures, smod-electing geo-objects). Then it connects to the GIS server and loads all selected geo-objects into the scene via the IDL interface. The server will generate the VRML scene graph dynamically. After receiving the scene, the user can navigate in the model and identify geo-objects by selecting them. In addition there is also a 2D user interface available, written in JA-VA. This GUI supports the user posing queries and displays query results.


Lessons learned about VRML

During the development of GOOVI-3D based on the state-of-the-art, we have learned some lessons about VRML. VRML is excel-lent for the visualization of 3D geometric information via the WWW. Through the integration with Java VRML can be used to build a hardware independent client for the access and visualization of 3D data warehouse information. However, accessing not only 3D visual data but also additional information is not supported very well in VRML. Especially the lack of object management and data-base access within VRML are crucial disadvantages. These are fun-damental things to use VRML as a data warehouse’s front end. Many other application developers will have to re-invent the wheel by re-implementing this functionality. In the next section, we pro-pose two small extensions of VRML that help to avoid this unnec-essary effort.

Figure 2: Object Management and VRML scene graph

VRML Scene Graph

Name Dictionary




Name VRML node japan japan_1 japan_2

Figure 3: Data Transfer Protocol Scene = GeoObject | GeoOject; Scene GeoObject = action

action = new ObjectId ViewVRML |

newmaterial MatId VRML | setmaterial ObjectId MatId | newtexture TexId VRML | settexture ObjectId TexId |

ObjectId = “<String>” ViewVRML = VRML | “NULL”

VRML = “<VRML-node description>” MatID = unique material index TexID = unique texture index






An Interface to Name Dictionary


If VRML is used as a data warehouse front end, there is a special need for a name dictionary management. This name dictionary ex-tension can be realized with little effort by introducing a new node

Naming to name any VRML node: Naming {

Field SFString id ““

exposedField MFNode node NULL exposedField SFBool enabled TRUE eventIn SFBool nodeIsSelected eventOut SFString selectedId }

The node field contains the node identified by the name in the id field. The Naming node can be enabled or disabled in order to reduce the size of the dictionary. When a named node is selected interactively it should also be identified outside the VRML scene graph. Therefore the corresponding Naming node generates a

selectedId output event containing the name of the selected node. If

the selection is done by a TouchSensor, e.g., the TouchSensor’s

isActive output event is routed to the Naming node’s nodeIsSelected

input event. Getting this event the Naming node generates a

selectedId event.

In addition, the mapping of a name given to a VRML node has to be supported by the name dictionary management. Therefore a spe-cial Script node MapNameToNode is integrated in the VRML scene. This node receives a number of names via the input event names and issues the corresponding nodes:

PROTO MapNameToNode [ eventIn MFString names eventOut MFNode nodes ] { Script {

url “MapNameToNode.class” eventIn MFString names eventOut MFNode nodes }


The actual name dictionary management is done by the browser. To achieve this, the browser uses a NameManagement class containing methods to add and remove names as well as to get a node identified by a name.

class NameManagement() {

void add (String id, MFNode node) void remove (String id)

SFNode get (String id) }

While parsing the scene graph, the browser stores Naming node’s (id, node) pairs in the name dictionary. Disposing the name dictio-nary management in any script, the browser’s interface has to be ex-tended by an additional method:

public NameManagement getNameManagement()

However, no browser has implemented this name dictionary man-agement yet. Therefore the recommended practice is using a PRO-TO definition of the Naming node. The semantics of this node is defined in a script. Because exposedFields are not allowed in a

Script node the equivalent combination of a field, an eventIn and an eventOut are declared in the Script.

PROTO Naming [ field SFString id ““ exposedField node exposed Field enabled eventIn SFBool nodeIsSelected eventOut SFString selectedId ] {

Script {

url “naming.class” field SFString id IS id field MFNode node IS node

eventIn MFNode set_node IS set_node field SFBool enabled IS enabled

eventIn SFBool set_enabled IS set_enabled

eventOut SFBool enabled_changed IS enabled_changed eventIn SFBool nodeIsSelected IS nodeIsSelected eventOut SFString selectedId IS selectedId } Group { children IS node set_children IS set_node children_changed IS node_changed } }

The NameManagement class is static, so it can be reached in any script.


An Embedded SQL extension for


SQL is the industry standard language for specifying relational da-tabase operations. Currently, there is no standard for executing SQL commands from within a VRML application. VRML authors can perform database operations using Java scripts and Jdbc; how-ever, this remains an immature technology that imposes substantial overhead even for simple SQL operations.

For this reason the VRML Database Working Group [2] was formed to define a set of standard interfaces for employing a variety of database functionality within VRML. One of its areas of interest is a database extension to expand VRML with common database connectivity features such as embedded SQL.

Modifying Lipkin’s approach [8], that is not yet practically usable (see discussion in Section 4), we propose a high-level node making it possible to incorporate SQL within the flow of a VRML scene easily. This node vastly simplifies the authoring of VRML database applications:

Script {

field SFString sql “” eventIn SFString set_sql eventOut SFString sql_changed


eventIn SFBool execute eventOut SFInt32 result

eventOut SFString error_message url “execsql.class”

# and any number of

field fieldTpye param_name initialValue eventIn eventType in_param_name eventOut eventType out_param_name }

The sql field contains the SQL statement to be executed. Parameters are embedded within the SQL statement and are delimited by co-lons. Input parameters act as variables whose values are assigned immediately before execution of the SQL statement. All input pa-rameters must have either a corresponding eventIn or field. Output parameters act as variables whose values are mapped to an eventOut of the same name. They are part of an INTO clause of a SELECT command. The execute event is used to signal execution of the SQL command. If the command failed, result and

error_message should contain error information. The url field

ref-erences an implementation of the execsql Java class.



The two examples in the boxed section will show how the name dictionary management and SQL scripting node can be used for in-teraction in a VRML scene graph.They both use a database with the following schema:

Table skyscraper describes some skyscrapers in the city of Frank-furt. The table objectpresentation connects the named nodes of the VRML scene graph and the objects in the table skyscraper. The first example shows a data query which is used to get additional information about a selected object. In this case, the name of the ob-ject is asked. Of course, it is possible to query any other attributes of the database tables.

In the second example the user searches objects fitting specific con-ditions, e.g. buildings having less than 30 stories.

Example 1: Selecting a named object as a

da-tabase query input variable.

Table: skyscraper

name stories id Japan-Center 25 1 BFG head office 40 2

Table: objectpresentation

nodename objectid japan 1 japan_1 1 japan_2 1 bfg 2

DEF INFO Script {

field SFString sql “SELECT name INTO :name:

FROM skyscraper, objectpresentation WHERE nodename=:id:

and id=objectid” eventIn SFString set_sql eventOut SFString sql_changed eventIn SFBool execute eventOut SFInt32 result eventOut SFString error_message url “execsql.class”

# own fields eventIn SFString id eventOut MFString name


Define embedded SQL node for getting the name of an selected object.

Define a virtual button for exe-cuting the SQL-Statement.

The query will be executed by clicking on this virtual button.

Group { children [

DEF VBUTTON TouchSensor {} Box { size 2 4 2 } ] } ROUTE VBUTTON.isActive TO INFO.execute Transform { children [ DEF J_TS TouchSensor{} # named object JAPAN DEF JAPAN NAMING {

id “japan” node Shape {... } ] } ROUTE J_TS.isActive TO JAPAN.nodeIsSelected

Define a named node JAPAN which is associated wtith the geo-object identified by the name “ja-pan”.

This node is interactively selecta-ble by using a TouchSensor node.

ROUTE JAPAN.selectedId TO If the node JAPAN is selected, its field id will be used as an input variable of the SQL-Statement.


Example 2: Mapping node names resulting

from database query to the associated nodes to

highlight them



In its current state, VRML does not provide support for interaction and on-line access to databases, even though these are two fundamental issues for business applications. We have created GOOVI-3D, a prototype system that provides access and interac-tion with a 3-D spatial database over the WWW. GOOVI-3D is implemented in Java and VRML using CORBA for accessing the data warehouse. In an urban planning application, GOOVI-3D is used to interact with 3-D models of the city of Frankfurt. Building on the experience with GOOVI-3D, we propose two lightweight extensions of VRML that can make the development of business applications much easier: an integrated name dictionary management and an SQL node.

Lipkin [8] has proposed a slightly different approach for embedded SQL in VRML, that employs a special SQL language protocol in-stead of the sql field. However, no VRML browsers have yet imple-mented or even proposed an interface for third-parties to add custom scripting languages, making an implementation difficult at this stage. The SQL scripting node proposed by us can already be implemented with the current VRML standard. It has been adapted in [8] as the recommended practice before an SQL language proto-col becomes available.

The name dictionary management allows the identification of VRML nodes by names. All named nodes will be accessible even if they are created dynamically by createVrmlFromString(), createVrmlFromURL(), or Inline nodes. This is a great advantage

over the External Authering Interface (EAI) [9] getnode() method which is an approach to identify nodes using DEF names. Identifying nodes by DEF names leads to several problems because of its local nature [4]. Furthermore most DEF names are not intended to name nodes but to reuse them, e.g. material and texture nodes. Thousands of named nodes may be created, most of them useless for identifying objects. Due to the missing management facility in EAI, the name dictionary will grow without a possibility of ever shrinking. To avoid these disadvantages, the EAI can even use the name dictionary management we proposed through the browser interface.

An interesting area for further research is to extend GOOVI-3D to provide access to the spatial data warehouse not only through city models but also through more abstract information spaces [10] set up as VRML scenes. Information spaces such as network topolo-gies, cone trees and perspective walls could give interactive access to spatial databases with advanced search criteria such as topology, scale, and data quality. GOOVI-3D’s database access capability and name dictionary management are two initial steps towards making such VRML information spaces possible.


[1] J. Couch. JVerge: a free VRML 2.0 Node java class library., 1997. [2] VRML Database Working Group. [3] N. N. Duan. Distributed database access in a corporate

environment using Java. Proc. Fifth Int. World Wide Web

Conference, Paris, France, 1996.

[4] VRML 2.0 External Authoring Interface. Frequently Asked Questions.

[5] S.Flick. An object-orientated framework for the realiza-tion of 3D geographic informarealiza-tion systems. Second Joint

European Conference & Exhibition on Geographical, Information, Barcelona, Spain, 1996, IOS Press,


[6] B. Immon. Building the Data Warehouse, Wiley, London, 1996.

[7] A. Koschel, R. Kramer, R. Nikolai, W. Haag, J. Wiesel, H. Jacobs. A federation architecture for an environmental information system incorporating GIS, the World Wide Web and CORBA. Proc. 3rd Int. Conf./Workshop on

Inte-grating GIS and Environmental Modeling. National

Cen-ter for Geographic Information and Analysis, Santa Barbara CA, 1996.

[8] D. Lipkin, Proposal for a VRML Informative Annex: Database Extensions, 22.8.97.


field SFString sql “SELECT nodename INTO :id:

FROM skyscraper, objectpresentation WHERE stories<30 and id=objectid” eventIn SFString set_sql

eventOut SFString sql_changed eventIn SFBool execute eventOut SFInt32 result eventOut SFString error_message url “execsql.class”

# own fields eventOut MFString id }

Define embedded SQL node for getting the VRML nodes asso-ciated with buildings that have less than 30 stories

Map resutling node names to associated nodes



eventIn MFNode nodes url “highlight.class” }



[9] C. Marrin, Proposal for a VRML 2.0 Informative Annex: External Authoring Interface Reference, 21.1.97.

[10] Ramana Rao et al. “Rich interaction in the digital library.” Communications of the ACM, Vol. 38, No. 4 (April 1995), pp 29-39.

[11] S. Ressler et al. Using VRML to access manufacturing data. Proc. VRML’97, ACM Press, New York,1997,111-118.

[12] R. M. Roher, E. Swing. Web-based information visuali-zation. Comp. Graph. and Appl., Vol. 17, July/Aug. 1997, 52–59.

[13] V. Stewart. Interacting with the data warehouse: applying virtual reality technology for exploratory data analysis.

Proc. 1st. Int. Conf. on GeoComputation, Univ. of Leeds,

Leeds, UK, 1996, 766–776.

[14] The VRML Architecture Group. The Virtual Reality Modeling Language Specification. Version 2.0. August 4, 1996.

[15] A. Vogel. WWW and Java: Threat or challenge to CORBA? MiddlewareSpectra, Spectrum Reports, Win-chester, UK, May 1996, 36–40






Related subjects :