JMV: The New Generation
The original proposal
It was first introduced on Nov 7, 1996.
Design Principles
General structure
- GUI framework
- objects
- database
GUI Framework
The entire visual part of JMV should be built on a (platform-independent) GUI framework. The framework must support:
- overlays: several transparent/translucent windows that can be stacked upon each other
- plug-in architecture: dynamic linking/binding
- property-sheet interface
- standard GUI gadgets, including a tool palette
- an ability to deal with CORBA objects, RDBMS connectivity
- allow rapid prototyping and customizing (including a foreign language interface)
Provided the requirements above are met, the exact type of the framework isn't important. We may want to look into:
- Smalltalk
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
- 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
- Delphi
- 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.
- OpenDoc
- Neuron Data Elements
- Open Interface
+ Intelligent Rules + Data Access + Distributed Messaging + Web + Interoperable Objects.
Supports CORBA/OLE, ODBC
Interface builder, C/C++
WinNT/95, Solaris and HP/UX
- JACC
- 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.
Overlays
- Just a map (with political boundaries, land fills, rivers, etc)
- Drawing: lets a user draw standard etc. symbols
It's this layer that has a palette of drawing tools
- Synoptic observations
- Isoplots
- Each product is shown in its own layer
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.
Database
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
- from packed.dat, GRIB files, OTH-GOLD, BURF etc. files
- via inter-db transfer: (selective) replication of the server database
Triggers in the database
- based on absolute time or other external events
- a trigger can request a replication/update/upload, etc.
Notifications
- Any process can request a notification when the DB (or specific part of it) is updated
- publish-subscribe mode
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
- Area's full name
- Area's ID
- Boundary Box
- Projection
- Projection Parameters (Latin for a Mercator, Standard Parallels for Lambert-Conformal, etc).
- Resolution
It's only a hint: each product has its own resolution. Area's resolution is used only to discriminate between "relevant" and "irrelevant" (that is, too small) features. Obviously, only relevant features need be displayed.
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
- Class
ID (similar to NODDS's catalog-number)
- Full name of the product
- Units
- Scale factors
- Other hints as to display of the product
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).
- Product's class
ID
- Timestamps (reference time, valid time, forecast
TAU, etc)
- Boundary box
- Reference to a particular product: grid, image, observation, etc.
Table of Grids
This table describes every 2D grid product present in the DB
- Product's class
- Product
ID
- Grid dimension
- Projection
- a matrix grid data points
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
- Client's
ID
- Client full name
- Authentication and Authorization information
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
- A mapping module
- A drawing module
- A METAR/SYN observation module
The mapping module
It should display the map of a given area, a backdrop on which all the other overlays lay over.
Features:
- zooming in/out, including an option to "zoom to fit" the current screen window
- Scrolling. The whole map of the area at a given scale may be too big to fit the screen. In that case, horizontal/vertical scrollbars should be shown to allow a user move to a part he's interested in
- A scale ruler, showing the current resolution and the scale
- Do the right thing when the user resizes the whole window
- Display map in Mercator, UTM, Lambert-Conformal projections
- Options to turn on/off the display of rivers, roads, etc.
- Do not display the features that are too small for the current resolution/scale
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:
- Options to color-code the dots based on flight-categories, age of observations, etc. information
- Subscribe to updates of the corresponding table in the database, so when new observations come in, the display changes automatically
- Poll the "central" site for new data (implemented via database triggers)
- Display the observation dots on Mercator, UTM, Lambert-Conformal maps
- The database population module should accept METAR, etc. raw reports, BUFR and SYN files, and a direct inter-db transfer (from a server to a client db, probably a subset of the server table).
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).
Extensions
Modules to define areas.
oleg-at-okmij.org or oleg-at-computer.org
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 $