The usage of the framework can be divided into two categories: The first is simply using the already developed framework while the second is extending the framework and adding functionality to the framework. Both usages are described below.
Using the framework can basically be divided into two or three steps depending on what you are doing.
First you must import your data (which as of this writing can be either station or gridded data). For your conveniance (and mine) a FileHandling class has been included. Take a look at it to see which formats can already be read in with it. If your format is not available you need to write your own filehandling method or class. The source code of the FileHandling class is also useful for inspiration when writing your own FileHandling method. If the format you are writing the filehandling for is generic (like NetCDF or HDF) it would be most appreciated if you include your filehandling in the FileHandling class and send the patch to the author.
The methods in the FileHandling class returns a Grid object. Grid objects are the core of JOG. When you have created a Grid object you are ready to perform manipulations on it.
As you now have a Grid object containing your data we would like to perform some operations on this data set. Currently only a class to perform interpolations (the Interpolation class) has been developed. In addition the Grid class also contains methods for simple masking and merging of Grids.
Having performed all the operations we need to do on our data set we want to write it out to have a look at the resulting fields. If you need to write out to some special format you should write your own custom output method. Otherwise you might find the format you are looking for in the FileHandling class. Again, if you want to write out to a generic format I would appreciate if you send me the code for inclusion in future releases of the FileHandling class.
It is possible to extend the framework. For example someone might find it useful to have the ability to do different kinds of statistical analyses on the gridded data or to build some graphics into the framework. The preferred way of doing this is through the "composition" technique and not using the "extend" technique. This means that one should make a new class or maybe even (sub)package if it is a large extension and then use the public API and classes from the framework to implement the new class(es) instead of using inheritance to extend the package. An example of this practice is the Interpolation class which uses composition to extend the Grid class (you might want to have a look at the source code for that class if you plan to perform extensions).
The motivation for preventing extension can be found in Joshua Bloch's: Effective Java.
If you feel that some of the core framework needs improvement you are most welcome to contribute as long as the above design goals are respected. The following additions would be most appreciated:
To secure the quality of the code and ease debugging the testing framework JUnit is used. If you just want to make some minor changes or try out the framework please do not bother with it - but if you plan to do some serious development work on the framework please consider writing JUnit tests.
Presently the data model (i.e. the way data are organized and described) in Java Ocean Grid is pretty simple. It is the authors intent to change the data model to take advantage of the experience in the VisAD project. A description of their data model can be found here.