ARCH Vrml issues

Murray Bent (
Tue, 14 Jun 1994 12:15:22 --1000

Architectural requirements such as load sharing and process migration to
take advantage of network rendering capabilities are pretty complex, and
it'd make sense to build on other work such as ONG Object Services - the
interfaces work , and there is no restriction on implementing them.

HTTP is fairly expensive in network bandwidth, the way a new connection
is opened for each 'object', but structured/large objects could minimise
this overhead.

Sample VR sessions could always be made available using existing MPEG
links for those without 3d accelerated multiprocessing workstations,
and MPEG streams will continue to form a major part of VR sessions anyway
- if there's an existing video grab why not geo-reference it instead of
synthesizing that scene.

The Multimedia System Services spec on
has been over this ground quite comprehensively and elegantly.

I'd like to see existing collections such as government DEM, DLG, TIGER
files etc used as much as possible though there woudl be some clients
ignoring some of the accuracy or integrity of the information while others
could be built that preserved this information. A personal communicator-based
map would be no use unless it preserved accuracy, while a tourist fly-by
could be approximate to within 100 meters say.

While html data types are pre-defined, vrml needs more descriptive information
about the client setup (a cluster of cpu's? some graphics acceleration?)and
the data being served ( what is the geo-referencing of some video, or DEM ?).
This is easiest to achieve using an object model, and OGIS has built upon the
OMG Obejct Services in this area.

Earth Observation Data descriptions are already being developed using
OGIS objects, so a first cut of VRML may be in browsing descriptions
from various types of catalogs since this is a prerequisite to accessing
the information anyway.

See how I go, anyway.

Murray Bent
Cooperative Information Systems
QUT Australia