Download Using VRML as an Interface to the 3D Data Warehouse

Using VRML as an Interface to the 3D Data Warehouse
Volker Coors and Volker Jung
Fraunhofer Institute for Computer Graphics
Abstract
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. GOOVI3D 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 [Information Systems Applications]: Geographic Information Systems,
GIS; I.3.6 [Methodology and Techniques]: Languages, VRML;
I.3.7 [Three-Dimensional Graphics and Realism]: Virtual Reality
Additional Keywords: Data Warehouse
1
INTRODUCTION
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.
{coors, jung}@igd.fhg.de, http://www-a5.igd.fhg.de
Fraunhofer Institute for Computer Graphics
D-64283 Darmstadt, Germany
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 interaction. 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 questions as simple as: What are the name and address of this building?
What is the safest way from this place to the kindergarten? A genuine 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 integrated 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 dynamic update by CGI-programs.
Another very active area of research has been the coupling of middleware technology, e.g. CORBA, and the WWW. Vogel [15] argues 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 Request Broker that is not CORBA-compliant but provides the lowlevel communications in a corporate environment.
Even with all this new research going on, VRML does not yet provide support for real interaction and on-line access to databases, although 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 database 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 extensions of VRML can make the development of business applications much easier: An integrated name dictionary management and
an SQL node.
2
2.1
GOOVI-3D: A VRML-BASED
INTERFACE TO 3D-GIS
Motivation
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
specialized databases such as digital elevation models, land registers, 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.
DB
GIS should be serviceable for people with various levels of computing knowledge and available on different hardware platforms. Because 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 geographic information which is essential, especially for casual users.
thematic
data
geometry
topology
GOOVI-3D is such a system, which allows interactive access and
visualization of 3D geographical information. This new architecture 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 consequences. With GOOVI-3D, users can get additional information interactively, e.g. find a specific building or a safe way to the
kindergarten.
2.2
3D GIS
Server
WWW Server
CORBA/IDL
Interface
IIOP
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 installing specific software on the client.
The interface of the data warehouse is provided through CORBAIDL 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 remaining 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 representation 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.
2.3
DB
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.
GOOVI-3D in
WWW-Browser
GOOVI-3D in
WWW-Browser
Figure 1: System Architecture of GOOVI-3D
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.
2.4
Name Dictionary Management
For a visualization of the query results, e.g. by highlighting the resulting 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
Name Dictionary
Name
VRML Scene Graph
VRML node
...
japan
japan_1
japan_2
Shape
TouchSensor
Figure 2: Object Management and VRML scene graph
while searching a geo-object. This can be avoided by using another
data structure optimized for managing the geo-objects.
2.6
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.
During the development of GOOVI-3D based on the state-of-theart, we have learned some lessons about VRML. VRML is excellent 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 database access within VRML are crucial disadvantages. These are fundamental 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 propose two small extensions of VRML that help to avoid this unnecessary effort.
This name dictionary solves the task of mapping geo-objects to
VRML nodes. As shown above, the query returns an object identifier such as japan. The name dictionary leads to the corresponding
GeoObject node which then can be highlighted.
2.5
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 model (e.g. getting point normals, textures, selecting 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 JAVA. This GUI supports the user posing queries and displays query
results.
Lessons learned about VRML
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
Figure 3: Data Transfer Protocol
3
PREPARING VRML FOR THE DATA
WAREHOUSE
3.1
An Interface to Name Dictionary
Management
If VRML is used as a data warehouse front end, there is a special
need for a name dictionary management. This name dictionary extension 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 special 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 dictionary management in any script, the browser’s interface has to be extended by an additional method:
public NameManagement getNameManagement()
However, no browser has implemented this name dictionary management yet. Therefore the recommended practice is using a PROTO 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.
3.2
An Embedded SQL extension for
VRML
SQL is the industry standard language for specifying relational database 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; however, 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 colons. Input parameters act as variables whose values are assigned
immediately before execution of the SQL statement. All input parameters 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 references an implementation of the execsql Java class.
3.3
Examples
The two examples in the boxed section will show how the name
dictionary management and SQL scripting node can be used for interaction in a VRML scene graph.They both use a database with the
following schema:
Table: skyscraper
name
stories
id
Japan-Center
25
1
BFG head office
40
2
Table: objectpresentation
nodename
In the second example the user searches objects fitting specific conditions, e.g. buildings having less than 30 stories.
DEF INFO Script {
Define embedded SQL node for
field SFString sql “SELECT name
getting the name of an selected
INTO :name:
object.
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
}
Group {
children [
DEF VBUTTON TouchSensor {}
Box { size 2 4 2 }
]
Define a virtual button for executing the SQL-Statement.
The query will be executed by
clicking on this virtual button.
}
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 geoobject identified by the name “japan”.
ROUTE JAPAN.selectedId TO INFO.id
If the node JAPAN is selected, its
field id will be used as an input
variable of the SQL-Statement.
This node is interactively selectable by using a TouchSensor node.
objectid
japan
1
japan_1
1
japan_2
1
bfg
2
Table skyscraper describes some skyscrapers in the city of Frankfurt. 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 object is asked. Of course, it is possible to query any other attributes
of the database tables.
Example 1: Selecting a named object as a database query input variable.
DEF SELECT Script {
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 associated with buildings
that have less than 30
stories
DEF NAME2NODE MapNameToNode {}
Map resutling node
ROUTE SELECT.id TO NAME2NODE.names names to associated
nodes
DEF HIGHLIGHT Script {
eventIn MFNode nodes url “highlight.class”
}
ROUTE NAME2NODE .nodes
TO HIGHLIGHT.nodes
Highlight these nodes
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 topologies, 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.
References
Example 2: Mapping node names resulting
from database query to the associated nodes to
highlight them
4
Discussion
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. 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 instead of the sql field. However, no VRML browsers have yet implemented 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 protocol 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
[1]
J. Couch. JVerge: a free VRML 2.0 Node java class
library. http://www.vlc.com.au/JVerge, 1997.
[2]
VRML Database Working Group.
http://www.vrml.org/WorkingGroups/dbwork
[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. http://www.tomco.net/~raf/faqs/eaifaq.html
[5]
S.Flick. An object-orientated framework for the realization of 3D geographic information systems. Second Joint
European Conference & Exhibition on Geographical,
Information, Barcelona, Spain, 1996, IOS Press, 167176.
[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 Integrating GIS and Environmental Modeling. National Center for Geographic Information and Analysis, Santa
Barbara CA, 1996.
[8]
D. Lipkin, Proposal for a VRML Informative Annex:
Database Extensions, 22.8.97. http://www.vrml.org/WorkingGroups/dbwork/oracledbex.html
[9]
C. Marrin, Proposal for a VRML 2.0 Informative Annex:
External Authoring Interface Reference, 21.1.97.
http://vrml.sgi.com/moving-worlds/spec/ExternalInterface.html
[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,111118.
[12]
R. M. Roher, E. Swing. Web-based information visualization. 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. http://vag.vrml.org/VRML2.0/FINAL
[15]
A. Vogel. WWW and Java: Threat or challenge to
CORBA? MiddlewareSpectra, Spectrum Reports, Winchester, UK, May 1996, 36–40
Figure 4: Model of the City of Frankfurt (Browser: CasusPresenter).
Figure 5: Interactive data query