NClip Design Manual
This manual will describe the features and implementation of the
NClip application. The main sections are
- A Short Description of the project.
- Introduction
- Objectives
- Features
- Implementation
- Vocabulary
- Index
For further information, see the main documents page.
Introduction
NClip is the successor to Splicer and Sagan, combining the features of
each application into this single application.
NClip provides
graphic, interactive data analysis products for depth-merging and integrating core and downhole log data. It consists of three main components:
- The NClip Application
- An optional embedded web server
- An
optional local data base.
The Application
The application is a C++ system based on wxWidgets. For purposes of this
design document we will included some pictures from the legacy Splicer and
Sagan applications.
Well Compositing
We will allow interactive depth-shifting of multiple holes of core
data to build composite sections using an optimized cross-correlation
approach. Multiple data types can be compared simultaneously in order
to quickly determine the best correlation for all variables.
Here is a sample splice picture:
Supported example applications include:
- Simultaneous comparison of multiple data types from multiple holes.
- Tying holes together to build a common "composite" depth scale.
- Build a continuous sediment section by "splicing" overlapping cores.
- Enter and compare stratigraphic data from various holes down the splice.
- Output data on the new composite depth scale (mcd) as well as mbsf.
- Output a continuous "spliced" records for further analysis.
- Tie the downhole spliced record to reference data such as insolation or isotope curves
For more details, see: here.
Producing a Mapped Composite
Sagan has been used to make a mapped composite from the Splicer
output. The types of mapping are: depths, time via isotope records,
or orbital frequency spectral mapping, etc...
Integrated mapping will be an function of NClip.
Here is a sample picture:
Some specific example features are:
- Compare multiple core data types (in mbsf or mcd space) to
downhole log records (log mbsf).
- Automatically or manually map core data back to log data to
determine original stratigraphic depths.
- Accurately estimate the size and position of coring gaps, as
well as the accuracy of the composite section.
- After mapping core data into the logs, the core data can be
saved versus Estimated Log Depth (eld) as well as mcd and mbsf.
For more details, see: here.
It is our objective to combine these two compositing methods into a
single application.
Data Retrieval
The system will use web services to retrieve data. We will be using
an embedded curl library to fetch
the data from remote to local places. However, in order to make a
stand alone application, we will need to supply local web services,
and to that end, we will provide the following two add-ons:
Back to the Top.
The Embedded Webserver
When data is stored locally, we will provide a Perl based standalone
server that only runs locally, but will mimic a typical data
web service for the purposes of unifying the data retrieval methods.
In NClip, the use will have the option of opening local data sets, and
then storing them in a local data base. In this way, the user will
be able to create a local copy of the remote data base, and
interact with it in the same way.
The Local Database
Normally, a local workflow database will be supported in a separate
process using MySql. However, in the interests of a small (500kb)
footprint, we will provide a small footprint Berkeley DB database. This
database will mimic the larger MySql DataVault database, and will
scale comfortably for individual and possibly stand alone users.
Back to the Top.
Objectives
- Wherever possible, separate the Graphics User Interface (GUI)
from the computations and file activities.
- Store and
retrieve all states, data formata, picks, files, origins, author, etc.
as XML.
- Do not hard code any data dependent parameters. Rather, build into
the system the ability to learn new data dependencies, e.g. formats of
data sets, weblocations of the data ...
-
-
Features
Session
The current state of the application can be saved in XML as a session.
There will be the following options when saving that session:
File Formats
We will support the following file types:
- Text based files. This can be CSV (Comma Separated Variable),
excel (xls), and tab delimited.
- XML files, such as the POSC standard.
- Binary files, such as BMP, JPG, ...
In addition, we will allow the use of a ClipIn
module that will allow the user to provide the means of reading a
foreign format.
Printing
Hardcopy output can be created by printing the tracks as they are
displayed on the screen, and by printing a summary of the session,
using the XML file of the saved session.
Saving
There will be two types of saving: In Place and Duplicate.
Inplace Saving
In Inplace saving, the current session is saved as an XML file,
and the associated tracks are not modified. In other words, if
there has been any picking, and/or
any pending normalization during this session,
the information necessary to reestablish those states while using
the original data will be saved in an XML file.
Duplicating Saving
In Duplicating Saving, we will first complete all pending
stretches and shrinks on a cache copy of the tracks' data,
and then store the copies of those tracks' data in a user specified
location. We will then store the XML file describing the result
of this session, as applied to the the new data, in an XML session file.
In this way, we will have a stand alone copy of the data, and an XML
that works with that data.
Copying
Although making a copy of a session will be a separate menu item,
it will simple implement the Duplication Saving action.
Importing
When we import, we mean retrieving a track's data from another location,
and adding that data to this session.
Exporting
When exporting, we will be saving a tracks data in a new location,
and optionally registering that new location with the current session.
We will also optionally complete any pending normalization before
saving.
Actions
There are several types of actions that may be performed on a track.
Which action is performed by a mouse state is user configurable.
More than one action can be associated with a mouse state.
Annotate
When the annotation mode is active, a click in a track will
produce a pop-up box that will allow the user to add HTML or plain text.
Possible display states of an annotation are
Visible/Hidden
Fit to box/Display Full Size
Auto Pop-up/Manual Pop-up
The latter toggle means the annotation will pop up whenever
the mouse is within the Annotation Radius.
Pick
This is the process of assigning a control point to a track.
Depending on the current state, a pick may start a new control point,
or extend a current control point.
Add
Start a new control point by a pick.
Subtract
Remove a pick from a control point.
Normalize
Stretch and/or shrink the current track to fit the control points.
XML
Sessions are saved in XML, either in-place, or as a copy. See
Saving, Copying, Importing, and Exporting for more details.
Opening Files
Opening a file means creating a track, and association an MDO with that
track. The association of an MDO means supplying the MDO with a
map to the data's location, e.g. a file of a supported format.
Fetching Files
We will be fetching files from one of three locations:
- A file in the local file system.
- A Web Service, e.g. a URL.
Database access will occur via a web service. We will provide
an Embedded Server that will provide web service access to
local or remote databases.
Uploading file copies to a web service is not a feature of
this application. We will however, supply a plug-in that will
complete this type of event.
Tracks
Several actions are associated with a track. They are:
Picking
Adding a location on this track to the session. The
coordinate system used is the decided by the track affected.
Displaying
Show the contents of this track on the canvas, or the printer.
Stretching/Shrinking
Given a pair or more control points, we will stretch or shrink
the display in this track to match those points.
A control point in two or more
tracks is de-referenced through the meta track.
ClipIns
These are external functions provided by the user or a third party.
These plugins are accessed at run time. A plug-in designers kit
will be provided. Events that can trigger plugins are:
Properties
The session state will have several properties:
Annotation Radius, in pixels. This is the distance within which
a mouse location will cause an annotation to pop-up.
Back to the Top.
Implementation
The implementation of NClip is in C++. Most features are
supported by a given object. We list below several visualizations of
these objects:
Dependency Graph
Inheritance Graph
Object List
We present here a list of the objects that we will use to implement the features.
For complete documentation of the object's code, see
the code documentation for more details.
NClipApp
This the the "main" program, i.e. the point at which execution is started.
It is not an object, but rather the starting point.
This is accomplished by using the IMPLEMENT_APP(NClip) wxWidget macro.
Thus, it supplies the bool NClip::OnInit() entry point.
Details
MDO
MDO is a class that provides methods for data storage and retrieval.
Various features include disk stripping, block multiplex IO, fast data access, etc.
Each object of the class MdoADT (Abstract Data Type) has several fundamental members:
The number of dimensions (directions) of the data in this MDO, called
dimension.
The number of data stored in each direction, called counts.
The length of each entity stored, in bytes, called storageWordLength. This
allows the storage of arbitrary entities, including bytes, ints, floats, polygons, etc.
Each of the above listed entities must be set before the MDO may be used.
They are set in the call setDimensions.
Once the dimensions are set, the user if free to store and retrieve data
from the object using the methods listed below.
Type of data storage supported include: memory and disk, with
one or more disk files, using block multiplex storage).
The data stored need not be specified by type. In fact, each datum
can be an arbitrary number of bytes. However, if the data type specified
is float, long, or H_BYTE, records of the maximum and minimum value of the
data stored are kept during the storage process.
The object stores data in an arbitrary fashion. The user and programmer may use a
familiar API (Application Programmers' Interface) using an object that only uses ANSII
C++.
We will subclass various types from the MdoADT: Dense, Sparse, Lexigraphic.
The MDO will interface with the wxWidgets Grid data type. By this we
mean that an MDO may in instantiated as a wxGrid. This is especially useful
when displaying the MDO's data in a track.
Details
MyCanvas
This is the object that hosts the wxWidgets canvas that is used to draw the
tracks in the current session.
Details
MyFileManager
This is used for the File Save, Save As, and Copy features.
Details
MyFrame
This is the WxFrame that hosts NClip. It's children include MyCanvas, NclLog, etc.
Details
MySplitterWindow
This window manages the (possibly) multiple canvases in the frame.
Details
NclBase
The base class for the NClip objects that are not in the wxWidget's hierarchy.
Details
NclLog
The object that manages log entries.
Details
Vocabulary
- Canvas: The area on the screen where the Tracksare plotted.
Plotting can be vertical or horizontal.
- Control Points
are co-located in more than one coordinate system. They are used to
relate features between tracks. For example, with a pair of tracks,
control point A may be 1000m in track 1, and 945m in track B. A control point
can apply to one or more tracks, with no limit in the number
of tracks. Once created on one track, a control point can have other
tracks added to it.
When a track is added to the system, its top and bottom are associated with
its corresponding postion in the meta track.
Thus all tracks are normalized
through their control points.
- Coordinate System specifies the algorithm used
to locate events in tracks. Examples are Age, Depth, wire length, etc.
- Meta Track is the invisible track that is
used in the MDO. When a control point is created by a the first
pick on a track, we will establish that track's pick by its location
in the MDO's coordinate system. All future picks
associated with that control point will be related
to the same location in the Meta Track. Global
stretching and shrinking
is invoked by changing the control points entry on the
meta track.
You can think of the metat track as the systems virtual coordiante system.
There is always a control point at the top and bottem of a meta track.
When a track is added to the system, its top and bottom are associated with
its corresponding postion in the meta track.
Thus all tracks are normalized
through their control points.
Roughly, a meta-track's
units are some fraction of a pixel.
ToDo: This definition needs work.
- Mouse State
is an event triggered by the mouse and/or the keyboard. Examples are:
- Left Mouse Button Down
- Middle Mouse Button Up while the shift key is pressed
- Control Right Mouse Button Up
- Track: The object that is displayed, plotted,
imported and/or exported from NClip. Several Tracks make a Canvas.
- Normalization: This is an action carried out on a track. When a track is normalized, that means a series of control points
have been chosen, and the data as displayed has been stretched and/or
shrinks to reflect the location of those control points.
Back to the Top.
Index
Back to the Top.
Last Change Date: $Id: index.html,v 1.8 2005/09/27 19:48:08 kamp Exp $
Bill Kamp