JMV: The New Generation

The original proposal

It was first introduced on Nov 7, 1996.


Design Principles

General structure

GUI Framework

The entire visual part of JMV should be built on a (platform-independent) GUI framework. The framework must support:

Provided the requirements above are met, the exact type of the framework isn't important. We may want to look into:

VisualWave from ParcPlace-Digitalk: provides the standard Smalltalk environment plus database and Web capabilities. The package includes a server SmallTalk and a distributed Smalltalk (with authentication and restriction on visibility and execution of objects)
VB is somewhat cross-platform. There are commercial products that let one run byte-compiled (binary) VBX/OCX/ActiveX under UNIX. There are also ports of VB itself on UNIX
cross-platform??? Hardly...
Oracle PowerObjects
They are really cross-platform. Moreover, they come with a built-in database connectivity, and even with a Lite version of the Oracle DBMS. The Lite version is compatible with the full-blown version, and is run-time-royalty-free.
Neuron Data Elements
Open Interface + Intelligent Rules + Data Access + Distributed Messaging + Web + Interoperable Objects.
Interface builder, C/C++
WinNT/95, Solaris and HP/UX
Forte/Forte Express
c-tree plus
A cross-platform DBMS: supports low-level ISAM all the way through ODBC. Full ANSI C source, $895. Runs on almost everything.


Layers can be switched on/off at any moment, or rearranged at will. There can be several modules to display the same set of data (say, observations), each displaying in some particular way. All available modules, views, that can handle a product selected by the user should appear on a special palette, for a user to choose. Probably one view should be designated "default". But the user can always switch to another, if possible.

JMV Objects

Map, Projection, Area, Grid, Product, Observation, etc.
The GUI framework uses objects to display a map, to convert lat/lon to x/y, to retrieve/compute a METAR observation and its parameters (e.g., a flight category), etc.

The objects can be either remote or local: it doesn't actually matter, as the interface is uniform, via CORBA.

The objects are persistent: stored in the database. Actually, objects's data are stored in a RDB.

Using CORBA allows customization of existing objects by subclassing.


The Database is the same on a client and a server. Server's database is a superset of that of a client. This facilitates replication/updates among the DBs. Also, a client can act as a server to other clients (if it's powerful enough)

Population of the database

Triggers in the database




The structure of the database is the same, for both a client and a server. Server's database simply has more products, which cover a broader area.

Here's a sketch of the database's structure

Table of Areas

Some areas come prepared off the server, but a client can add a few of its own. Also a server can keep an area for a particular client.

Table of Product Classes

Usually a read-only table

Table of Products

This table has a row for each product the current JMV client or server got hold of. Product's dimensions/resolution need not correspond to any particular area: A single product can be displayed in several areas (and a single area can display several products).

Table of Grids

This table describes every 2D grid product present in the DB

Table of METAR/SYN observations

Table of Satellite images

Table of Selected Products

Specifies Many-to-Many relationship between products and areas

Table of Clients

Usually only present on a server that has registered clients

Table of Client's areas

Usually only present on a server that has registered clients. The table establishes many-to-many relationship between clients and areas that are defined for them (or pre-defined requests that can be executed automatically).



The Roadmap

More detailed notes as to how to go about building the new JMV.


Proof-of-concept prototype

It should include a few modules that implement the most typical JMV functions. It's desirable also to implement something new, to hook potential users up. It appears that the proof of concept prototype should contain

The mapping module

It should display the map of a given area, a backdrop on which all the other overlays lay over.


The METAR/SYN observation module

This module is to display observational reports, and allow live updates. Each particular report is displayed as a dot on a map, which can have a different size/color, and can have annotations/symbols attached to it. It features:

There probably ought to be several views that deal with observations: one module just displays color-coded dots, another module display big dots with annotations (wind speed, temperature, etc). All available views would reside on an observations palette, so a user can display observations in a way he prefers. The user can even select several observational modules: each would display the same data in its own layer.

The modular structure should make it easy to add a new way of displaying observations: just subclass from the corresponding Observation object.

The drawing module

It's this module that lets a user to annotate the display with symbols, text, etc. The drawing is done on a separate overlay (which is stored in the database as a separate "product"). This product can be distributed/propagated as any other product. As any other overlay, the annotations can be switched on/off (and moved to front/shoved to back).


Modules to define areas. or
Your comments, problem reports, questions are very welcome!

$Id: History-JMVTNG-prop.html,v 1.1 1999/08/12 20:17:06 oleg Exp oleg $