Monterey Bay Aquarium Research Institute
GIS at MBARI

The Customization of ArcView as a Real-Time Tool for Oceanographic Research

Gerald A. Hatcher Jr., Norman M. Maher and Daniel L. Orange
All from the Monterey Bay Aquarium Research Institute, Moss Landing, California

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. Arc/Info 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 cruise.

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 Arc/Info, 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. Arc/Info was used to contour the grids and register 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

  • Improved at-sea operations— 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.
  • Quantitative and qualitative improvement to data collection—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.
  • A good interface to oceanographic data—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.
  • A "power user" is helpful—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.