Abstract
Abstract
An oceanographic cruise is very costly, involves
data from many different sources, is a long time in planning and
often takes place in remote locations of the world which may not
be visited again for years. It is therefore important to take
advantage of available technology which may help ensure success
of the cruise. A GIS has proven itself as a valuable tool for
oceanographic cruise planning and data analysis. At the Monterey Bay Aquarium Research Institute (MBARI) we've
taken this one step further by creating a customization of ArcView
which incorporates oceanographic data as it is collected (in real-time).
The customization we've created uses real-time
navigation data to continuously update data files and the position
and orientation of scaled graphic objects indicating the true
position and heading of any number of vehicles and their location
in geographically registered oceanographic data sets. For example:
icons representing the heading and location of a surface ship
and a Remotely Operated Vehicle (ROV) are displayed on top of
data layers such as: a contour coverage of seafloor bathymetry,
acoustic reflectivity data, and previous day's dive tracks. This
allows the user to navigate efficiently and accurately using "point
and click" methods rather than with paper charts and notebooks
which are difficult to manage in a darkened control room on a
rolling ship. Specialized software "tools" for real
time operations were created that include a "digital notebook"
for recording geographically referenced comments and a tool for
capturing geographically referenced video stills from a remotely
operated vehicle.
The Oceanographic Research Cruise
A typical oceanographic research cruise can
have operating costs of more than $20,000 per day, take several
years to plan and involve many people. A cruise will often take
place far from shore and last from several days to months. The
finite number of research ships in the world and their associated
logistical restrictions dictate that at any given time only a
few locations of the globe can be visited. As a result a scientist
may only get one opportunity every several years to visit their
particular area of interest. These factors require that the oceanographer
be extremely careful to ensure the success of the mission.
When planning for a cruise, and while the cruise
is underway, previously collected data for the intended research
site (if it exits) are usually critically important. When compared
with land data, oceanographic data have more often been collected
digitally but they are relatively incomplete. The data that do
exist will often be stored in incompatible formats and at various
locations around the world. These data will usually be of widely
different scales, precision, map projections, and geographic coverage.
Often the data sets are large and require powerful computers with
large amounts of disk space to manipulate. Effectively managing
these data can be a significant problem (Wright 1997
, Basu 1996)
During a cruise the original cruise plan will
inevitably be modified and large volumes of data will be collected.
These data may not be analyzed for months or even years after
returning to shore. When away from shore the oceanographer operates
in a very limited frame of geographic reference because there
are no visible clues to position at the ocean surface or in the
mid water depths. Even when operating at the bottom with a remotely
operated vehicle or a submarine, the visibility is restricted
to the limits of the vehicle's lights. Without a good frame of
reference it can be difficult to insure the positional integrity
of the data being collected or to quickly make informed decisions
about possible changes to survey routes or intended sample locations.
The GIS Solution
That a GIS is highly suited to address the
types of issues mentioned above is not new and the usefulness
of a GIS to a research cruise for planning and analysis (both
at sea and on shore) has been described in the literature (Wright 1996).
This paper however, focuses on the use of a GIS during at-sea
operations as a real-time tool. It has been the experience of
the authors that the effectiveness of a GIS as a shipboard tool
is directly proportional to the ease and speed with which data
collected during the cruise can be imported into the GIS. Taking
this observation to it's logical conclusion we've created a customization
of the ArcView GIS which incorporates
data as it is collected (in real-time) into the GIS. As of this
writing, data which we are able to assimilate in real-time consist
of information related to vehicle navigation (Figure 1)
and the capture of still images (frame grabs) from
video data (Figure 2). Systems collecting
swath bathymetry or acoustic backscatter information produce huge
volumes of data and require extensive processing. These data are
collected and processed by a separate dedicated system and then
those processed data are quickly incorporated into the GIS during
the cruise (Figure 3).
The "typical" oceanographic research
ship is equipped with of a suite of sensors connected to data
acquisition computer(s) which perform preliminary data processing,
log the data to some form of long term storage, and make the data
available to other applications. The method with which the data
are made available is usually different on each ship and requires
a custom interface. The authors have deployed this system on 3
different research vessels and been able to access the real-time
data via a broadcast over the ships network, through a direct
serial connection, and by using network file sharing. Real time
video data stills are also collected and geo-referenced with the
GIS through a custom software interface to a Snappy™
video frame grabber. Communication between ArcView and the two
standalone MS Windows programs created for this project (the navigation
data interface and the interface to the Snappy™ frame grabber)
are done via the ships network using a DLL extension to ArcView
also created at MBARI.
The system has evolved to the point where only
one ArcView Avenue script and the MS Windows™ C++
interface to the navigation data need to be modified. This minimizes
the amount of customization required for each new deployment.
The modifications to the Avenue script are relatively simple and
provide information such as data directory paths, the dimensions
and names of vehicles which the GIS will track, and graphic update
rates. The modifications to the MS Windows™ C++ program however
are usually not trivial and include software code changes to the
network communication, the serial port I/O, and data reformatting
and buffering routines. This complication is due to the lack of
a standard way to access the real-time data aboard research ships.
Another fact adding to the difficulty of this type of software
development is that the programs will often be required to run
continuously for many days and therefore extra care must be taken
to ensure "resource leaks" or "bugs" that
appear only after the system has run for days are eliminated.
The research cruises on which we have deployed
this system all made extensive use of a Remotely Operated Vehicle
(ROV) which is an unmanned submersible connected to the mother
ship by a cable or "tether." The tether provides a power
and data link to the ROV (Figure 4). The
ROV is controlled from a control room on the mother ship specifically
set up for that purpose. During operations the control room is
usually darkened and there will be multiple computer screens and
video monitors displaying information from various systems aboard
both ship and ROV. The ROV is piloted with joystick(s) using on-board
video cameras as the "eyes" of the system and sonar
sensors for collision avoidance and target location (Figure 5).
The motion control commands are transmitted from the ship to the
ROV through the tether and the ROV sends video and sensor data
back.
To minimize the impact on the limited space
usually available in the control room the real-time GIS runs on
a laptop PC connected to the ship's network (Figure 6).
The tradeoff with using a laptop is that its limited screen resolution
and size make it difficult for more than one view window to be
displayed at the same time and routine GIS operations can be more
tedious than they would be on a desktop with a large monitor.
We alleviate this problem by setting up a separate desktop system
in a part of the ship where space was not at such a premium but
access to the ships network was still available. The desktop system
is also capable of operating in real-time mode (simultaneously
with the laptop system) but is more often used "off-line"
for data analysis and software development. New software tools
and data layers (themes) can be transferred over the network to
the real-time GIS running in the control room without interrupting
the vehicle tracking. ArcInfo running on a UNIX workstation (also
connected to the ships network) is used for some data processing
and those data are then incorporated into the real-time GIS.
Experience at Sea (Marianna Trench
Example)
A recent (Feb. 1997) 35 day marine geology
cruise at the west edge of the Mariana trench in the Western Pacific
ocean will be used as an example to describe system as it operates
at sea. The R/V Thomas G. Thompson operated
by the University of Washington and
the ROV "Jason" from
Woods Hole Oceanographic Institute (WHOI) were
employed for this cuise.
Overview
There were three vehicles to track in real
time: the surface ship, the ROV, and the "clump weight"
called "Medea". Medea's function is to "de-couple"
the ships motion at the surface from Jason and also to provide
a "birds eye " view of seafloor operations through a
down looking high light sensitivity video camera (Figure 4).
Jason was used at the seafloor to take heat flow measurements,
collect sediment samples called "push cores", deploy
instruments on the bottom, and to collect rock samples. We obtained
high resolution bathymetric data over an area of several kilometers
using a hull mounted multi-beam system called "Hydrosweep".
Previously collected data coverages of acoustic reflectivity and
bathymetery of several resolutions in both gridded and contour
form were used for cruise planning and to generate base maps.
System setup
Real-time navigation data was sent from the
Jason navigation computers across the ships network through a
data broadcast to a desktop PC located in one of the ship's labs.
The data were then reformatted and made available via the network
for real-time ArcView "client" access by a stand alone
MS Windows program created for this project. Live video from the
ROV's primary camera was sent to a video switcher and then to
a Snappy (TM) frame grabber connected to the parallel port of
a PC running a Windows application that allowed remote control
of the Snappy™ hardware. A UNIX workstation running ArcInfo,
also connected to the ships network, was used to perform operations
such as projection transformations and image registration. The
UNIX workstation was used as the central location for storing
data layers in order to eliminate multiple copies of data. This
file server arrangement was made possible by the network file
access program "Samba" which allows PC's to access coverages
stored on the UNIX workstation's hard drive(s) as if they were
stored on the PC's local drive (Figure 7).
Operations
When the ROV dive was in progress the real-time
GIS displayed the tracked vehicles (Thompson, Jason, and Medea)
as different colored outlines and dots representing their present
position, heading, and recent movement in one or more ArcView
windows along with any data themes shown in the view. The vehicle
outlines were drawn using the actual dimensions of the vehicles
if the view was "zoomed in" (Figure 1)
or to a percentage of the view window's size when "zoomed
out" (Figure 3) The real-time heading
data (if available) were used to rotate the graphics to the actual
heading and all the graphics were updated at a user specified
time interval (usually 5 seconds). Any of the tracked vehicles
could be designated as the "centering vehicle" who's
position was then compared with the geographic bounds of the view
window each time the navigation was updated to determine if the
vehicle had moved out of the view. If so, the view was automatically
panned so that it centered on the new position.
Real-Time Software Tools
The real-time tracking works both in geographic
and UTM projections, however ship navigation is usually done in
geographic coordinates. A software tool which automatically overlays
an approximate geographic grid on any view was created. Additional
tools for determining geographic coordinates and range and bearing
between locations on a view window using mouse "clicks"
were implemented (Figure 3).
Navigation information along with time in GMT
for all three vehicles could be automatically stored instantly
in a shape file with a single mouse click. An optional "comment"
could be stored along with the data creating a "digital notebook"
of cruise events. This shape file was changed automatically with
the change of GMT day and also automatically updated in the real
time view(s). Two specialized "digital notebooks" which
contained only data where either a heat flow measurement was taken
or a push core was recovered were also created (Figure 3).
These three shape files were all of the exact same format but
it was convenient to have the specific sample data stored in separate
files from the general cruise event information.
A similar function to the "digital notebook"
was created to store the time and navigation data of all tracked
vehicles along with a file name of a video frame grab. This ArcView
function also sent a command (using a DLL extension to ArcView)
to a Snappy frame grabber interface which could grab an image
(Figure 2) on command and save it with
a given file name. In this way geographically located images could
be collected and the file name used as a "hot link"
for accessing that image data in ArcView.
Near-Real-Time GIS
While at sea we were able to incorporate several
types of data in "near real-time." These data include
the high resolution bathymetry collected with the Hydrosweep system
and tabular information about bottom samples taken with a device
called a gravity core. The Hydrosweep bathymetry was processed
on a UNIX workstation to create a grid and a shaded surface model.
ArcInfo was used to contour the grids and registert the images
to geographic coordinates. The shaded surface was converted to
TIFF format and the contour coverage was converted to a shape
file for use by ArcView. The gravity core data was being tracked
in a Microsoft Excel spread sheet and could be used in ArcView
directly.
An unanticipated function of the at-sea GIS
system was to create a hard copy base map which was then used
to sketch a rough interpretation of the bottom geology and the
sites of potential interest. This sketch was then scanned into
a Tiff image and re-registered to its geographic coordinates.
The sketch could then be used in the real time GIS as a data theme
during ROV operations to guide the ROV to geologic target sights.
Conclusions
Using the GIS at sea provides a convenient
method to simultaneously access many types of oceanographic data
in a consistent interface. This interface provides the user with
a geographic frame of reference otherwise unavailable. This frame
of reference can be a great asset to the oceanographer required
to make difficult at-sea decisions and can save valuable time
when trying to locate (or return to) areas of interest. Additionally,
being able to use "point and click" methods to is a
vast improvement over using paper charts, mechanical dividers,
and hand written notebooks in a darkened control room on a rolling
ship.
By incorporating data in real-time or near-real-time
a first order check on the quality of the data is inherently done.
Sensor problems which might otherwise gone unnoticed for an entire
cruise are more likely to be spotted and corrected while at sea.
Quickly incorporating data collected at sea will also flag unintended
data gaps or poor coverage which can then be re-surveyed as needed.
The ability of the GIS to import and export
a variety of data formats and its capability of producing publication
quality hard copy output allow easy access to oceanographic data
of many types. This implies that data sets stored in a GIS will
be easily distributed and used among the greater scientific community
and thereby lower the cost per user of the data.
In order to interface the system to a specific
ship, create custom GIS software for a particular need, handle
unanticipated data formatting problems, etc., a highly skilled
programmer/technician or "Power User" can be indispensable.
This may require an additional cruise personnel or a member of
the science team with good computer skills to invest considerable
time learning the details of the real-time GIS and the standard
GIS software package on which it is based.
Figure 1: Real-Time GIS Graphical User interface
Figure 2: Video Frame Capture From the Snappy interface
Figure 3: Real-Time GIS Graphical User Interface Controls
Figure 4: ROV Cruise Components
Figure 5: ROV Control Room
Figure 6: Real-Time GIS Laptop
Figure 7: System Diagram
References
Basu, A., Development of a user friendly marine geographic information system with spatial data analysis and error estimation of a three dimensional data model in the Hawaiian Exclusive Economic Zone. Oceans 96 MTS/IEEE Conference Proceedings, 1996.
Wright, D.J., Fox, C.G., Bobbitt, A.M., A scientific information model for deepsea mapping and sampling , Marine Geodesy, in press, 1997.
Wright, D.J ., Rumblings on the ocean floor: GIS supports deepsea research , Geo Info Systems, 6(1): 22-29, 1996.
