ArcGIS Marine Data Model - Dawn...

ArcGIS MarineData Model(June 2003)

This document provides anoverview of the ArcGIS Marine

Data Model. This model focuses onimportant features of the ocean

realm, both natural and manmade,with a view towards the many

applications of marine GIS data.

ArcGIS Marine Data Model Reference

ArcGIS Data Models

Dawn J. Wright, Oregon State U.

Patrick N. Halpin, Duke U.

Michael Blongewicz, DHI

Steve Grisé, ESRI Redlands

Joe Breman, ESRI Redlands

2 • ArcGIS Marine Data Model

TABLE OF CONTENTS

Acknowledgements ................................................................................................................... 4Introduction ............................................................................................................................... 5

Why a Marine Data Model? .................................................................................................... 6Intended Audience and Scope of the Model............................................................................ 8

The Process of Building a Data Model ..................................................................................... 10Final Data Model Content, Purpose and Use........................................................................ 14

Data Model Description ........................................................................................................... 16Overview ............................................................................................................................. 16

Conceptual Framework ..................................................................................................... 16Core Packages ................................................................................................................. 19Synthesis.......................................................................................................................... 21

Marine Data Model Object Class Glossary............................................................................... 21SAMPLE DATA....................................................................................................................... 22

Generic Marine Data Sources .............................................................................................. 22Sample Geodatabase Sources............................................................................................. 25

Implementing the Model: Case Study Applications................................................................... 25A Preliminary Note About Prototyping a Design.................................................................... 25

A Note on Cross References to Existing Standards ................................................................. 26References ............................................................................................................................. 27List of Acronynms Commonly Used with Marine GIS Data Sets ............................................... 30Overview of ArcGIS Object and Geodatabase Concepts.......................................................... 33

Objects ................................................................................................................................ 33Features .............................................................................................................................. 34Feature Data Set.................................................................................................................. 34Relationships ....................................................................................................................... 34

ArcGIS Marine Data Model • 3


ACKNOWLEDGEMENTS

The authors gratefully acknowledge the following people for providing comments and input on

the data model and supporting requirements, as well as for reviewing drafts of this document:

Simon Evans, ESRI, Member of Marine Data Model Working Group

Jason Marshall, NOAA CSC, Member of Marine Data Model Working Group

Eric Treml, Duke University, Member of Marine Data Model Working Group

International Review and Case Study Team Members listed as

http://dusk.geo.orst.edu/djl/arcgis/people.html

This effort could not have been completed without the benefit of their participation.

We also acknowledge the support and reviews of the FGDC Marine and Coastal Spatial Data

Subcommittee for review and feedback related to design efforts and linkages between the

model, the Hydrography Data Content Standard for Inland and Coastal Waterways and the

broader Coastal National Spatial Data Infrastructure.

And finally, we acknowledge the support and encouragement of Kevin Curtin, lead author of

the UNETRANS Data Model, and Nancy Von Meyer, lead author of the Parcels Data Model.


Introduction

Just as fish adapted to the terrestrial environment by evolving into amphibians, so GIS mustadapt to the marine and coastal environment by evolution and adaptation.-- Goodchild (2000)

Indeed, it appears that marine GIS has finally “arrived” as a well-established application

domain. The initial impetus for developing a marine specialty in GIS was the need to automatethe production of nautical charts and to more efficiently manage the prodigious amounts of

data that are routinely collected at sea. But the application domain has progressed fromapplications that merely collect and display data to complex simulation, modeling, and the

development of new coastal and marine research methods and concepts. The domain has

triumphed by successfully adapting to a technology originally designed for land-basedapplications, and structured in a 2-dimensional framework that has never perfectly matched the

ocean environment. Fortunately, the "state-of-the-art" has continually improved as increasedcommercial, academic, and political interest in coastal regions, oceans, and marginal seas

have spurred fundamental improvements in the toolbox of GIS, while extending themethodological framework for marine applications. Many challenges remain, such as

addressing the multiple dimensionality and dynamism of oceanographic data, handling thetemporal and dynamic properties of shoreline and coastal processes, dealing with the inherent

fuzziness of boundaries in the ocean, the great need for spatial data structures that vary theirrelative positions and values over time, and last, but not least, the development of effective

conceptual and data models of marine objects and phenomena. For a full discussion of these

and many any other research issues, the reader is referred to by Li and Saxena (1993), Bartlett(1993a and b), Lockwood and Li (1995), Wright and Goodchild (1997) and Wright and Bartlett

(2000 and references therein).


Why a Marine Data Model?

As noted by Bartlett (2000), one of the most important lessons to be learned from collectiveexperience in the application domain of marine GIS, both published and unpublished, is the

importance of rigorous data modeling before attempting to implement a GIS database. Indeed,data models lie at the very heart of GIS, as they determine the ways in which real-world

phenomena may best be represented in digital form. With regard to ESRI products, manymarine and coastal practitioners and organizations have invested in the coverage data model.

Although this has largely been successful, coverages have important shortcomings. For

example, features are aggregated into homogenous collections of points, lines, and polygonswith generic, 1- and 2-dimensional "behavior" (Zeiler, 1999). And there is no way to distinguish

between behaviors within feature classes: e.g., the behavior of point representing a markerbuoy is identical to that of a point representing a pulsing transponder; the behavior of a line

representing a road is identical to the behavior of a line representing a dynamic shoreline.ArcGIS 8 introduces a new object-oriented data model called the geodatabase, in which GIS

features are "smarter", i.e., they can be endowed with real-world behaviors for individualobjects within the same categories, and any sort of relationship may be defined among them

(for an overview of ArcGIS object and geodatabase concepts see the Appendix or Zeiler,

1999). This has wonderful implications for marine and coastal applications, but questions andconcerns in the community have surfaced (not unlike those posed by the forestry community;

FSIG, 2000): Given the existing investment, how and when should one make the transition to

object-oriented ArcGIS 8? How well are marine application domain requirements met in the

geodatabase structure now? What can we do as a group to understand the technology and

identify requirements? What are the potential benefits? An ArcGIS Data Model working group

was initiated to help address these concerns and to support the marine community in making

this important transition.


A key advantage of an ArcGIS data model is that it should help users to take fuller advantage

of the most advanced manipulation and analysis capabilities of ArcGIS, particularly the ability

to capture the behavior of real-world objects in a geodatabase, and the support of more

complex rules that can be built into the geodatabase. For users, an ArcGIS data model

provides a basic template for implementing GIS projects (i.e., inputting, formatting,

geoprocessing, and sharing data, creating maps, performing analyses, etc.); for developers, it

provides a basic framework for writing program code and maintaining applications. And while

ArcGIS data models do not create formal data standards, they do promote existing ones, which

should help to simplify the integration of data at various jurisdictional levels (i.e., local,

state/provincial, national, global).

The ArcGIS Marine Data Model represents a new approach to spatial modeling in a way that

promotes better integration of many important features of the ocean realm, both natural and

manmade. The goal is to provide more accurate representations of location and spatial extent,

along with a means for conducting more complex spatial analyses of the data. The model also

considers how marine and coastal data might be more effectively integrated in space and time,

particularly into the all-important 3rd and 4th dimensions. The data model, although still limited

to 2.5-D, includes "placeholders" meant to represent the fluidity of ocean data and processes.

Specific goals of the model include:

® Production of a common structure, a "geodatabase template", for assembling, managing,

and publishing marine data in ArcGIS.

1) For example, the model is specified in an industry-standard modeling notation called

the Unified Modeling Language (UML). And because UML code is easily converted to

an ArcGIS geodatabase, users can immediately begin populating the geodatabase,

rather than having to design it from scratch.

2) Users can produce, share, and exchange data in similar formats.


3) Unified approaches encourage development teams to extend and improve ArcGIS

software.

® Extending the power of marine GIS analyses by providing a framework for incorporating

behaviors in data, and dealing more effectively with scale dependencies

® Providing a mechanism for the implementation of data content standards, such as the

FGDC's Hydrography Data Content Standard for Inland and Coastal Waterways, critical for

the Coastal National Spatial Data Infrastructure.

® And perhaps in the final analysis, helping many users to really learn and understand

ArcGIS! For instance, in the core ArcGIS data model, arc-node topology can be used in

conjunction with other new and powerful data structures. Routes and regions are relegated

to feature classes. And relationships between tables can be preserved, maintained, and

easily managed.

Intended Audience and Scope of the Model

For the sake of discussion, "marine community" throughout this document refers to both deep

ocean and coastal GIS. In the past, a distinction was made because deep ocean and coastalGIS, as application domains and user communities developed fairly independently of each

other. This is not unlike how traditional oceanography departments in North America have oftengrouped together biological, chemical, physical, and geological studies of the ocean as

“oceanography science programs,” while creating a separate category for coastal studies,particularly if the emphasis is on coastal resource management. It may be fair to say that deep

ocean applications of GIS have traditionally been more in the realm of basic science, whereas

coastal applications, due in part to the intensity of human activities, have encompassed bothbasic and applied science, as well as policy and management. But this is fast changing, and

both subdomains collect similar data sets, and have common interests and needs in terms ofGIS implementation. In other words, the data sets are the same, regardless of how they are


used (for basic or applied science, for conservation, for education, for applied commercial use,

etc.), and as such an essential data model should be applicable to all. So an ArcGIS "Marine"

Data Model for the "marine community" should be useful for people applying GIS to the coasts,

estuaries, marginal seas, and/or the deep ocean; working as academic, government or militaryoceanographers, coastal resource managers and consultants, marine technologists, nautical

archaeologists, marine conservationists, marine and coastal geographers, fisheries managersand scientists, ocean explorers/mariners, etc.

Although the focus of the ArcGIS Data Model is on both the deep ocean and the coast--and it attempts to represent the essential elements for a broad range of marine andcoastal data types and processes--it cannot include a comprehensive catalog of objectsmeeting the needs of all user groups and applications. However, those elements that are

common to many marine GIS users have been identified, and are presented here. Forexample, the priority data themes of organizations such as the NOAA Coastal Services Center-

-bathymetry, shoreline, and marine cadastral boundaries--are certainly taken into account. Themodel is a starting point upon which to build on and leverage the experiences of a broader

range of practitioners; much broader, in fact, than the specialties of the initial Marine DataModel Working Group. It will also be desirable to understand what relationships may exist to

related data modeling efforts such as the ArcGIS Hydro, Biodiversity/Conservation, andParcels (e.g., for coastal land development). As Steve Grisé notes, designing a data model is

like designing a new minivan: once designed and built you still don't know how families willactually use it (there will be so many variations depending upon the family). So once a data

model is designed and initially implemented, then the many ways it will be used will be become

clearer, and it can be refined accordingly.


The authors encourage marine and coastal specialists, as well as other GIS professionals, to

engage in discussions on the use and application of this model through the online resources in

Davey Jones' Locker:

http://dusk.geo.orst.edu/djl/arcgis

The Process of Building a Data ModelA data model for marine applications will undoubtedly be complex because of the many varieduses of the data. And modern marine data sets are generated by an extremely varied array of

instruments and platforms, all with differing formats, resolutions, and sets of attributes (Figure1). Not only do a wide variety of data sources need to be dealt with, but a myriad of data

“structures” as well (e.g., tables of chemical concentration versus raster images of sea surfacetemperature versus gridded bathymetry versus four-dimensional data, etc.). It has become

increasingly obvious that a comprehensive data model is needed to support a much widerrange of marine objects, and that this is essential for advanced management, cartographic and

analytical tasks. The marine data model presented here endeavors to identify and organize

these objects.


Figure 1. The long-term ecosystem observatory instruments and platforms of the Rutgers UniversityCoastal Ocean Observation Lab, illustrating the varied sources of data available for marine GIS.

Data model design consists of four stages, increasing in abstraction as one goes from human-

orientation to implementation in a computer (Laurini and Thompson; Li, 2000):


1) external design (where the real world (Figure 1) is simplfied according to application

requirements).

2) conceptual design (the focus of this document - where a model is populated with spatial

objects and attributes in the form of entity-relation (ER) diagrams).

3) logical design (where ER diagrams are converted to some kind of schema, such as a

table).

4) physical or internal design (where the functions of actual hardware and software must be

considered for actual implementation of the model).

The first step in the data modeling process is to define the overall scope and content of themodel. From an external design standpoint, this involves the challenging task of identifying the

common, essential "things" that are modeled in most GIS projects within an application

domain. From a conceptual standpoint, it involves the creation of an analysis diagram, with theidentification of major thematic groups and an initial set of object classes within these groups.

The analysis diagram is therefore at the "conceptual design" stage in the data modelingprocess. In technical terms, an analysis diagram can be created by starting with the core

ArcGIS object classes and a set of named, real-world objects to be modeled. The creation ofthe conceptual data model often begins with a top-down approach, where the list of objects is

conceptually divided into thematic layers..

The key characteristic of these groups is that they share common properties and are part of alogical group of classes. For example, navigation features can be grouped together because

they are part of a connected set of data elements. After a basic grouping of objects is

established, one can begin to identify more specific similarities between objects. During the


process, new classes are identified and some classes are merged. The final result is a set of

ArcGIS object classes, an initial description of their attributes, and key relationships defined inan analysis diagram. Figure 2 shows a portion of the draft analysis diagram for the ArcGIS

Data Model in UML notation (to be described in more detail in the next section). In ArcGIS top-level object classes (gray boxes labeled either "Feature" or "Object") are generic object classes

provided by the software. In terms of types of classes, an abstract feature or object class(class name in italics) is a class that stores common attributes shared by the classes inheriting

from it. It does not have features or objects of its own. An object class (not shown in Figure 2)is a class represented as a table, in which each object has an ObjectID and Attributes, but no

spatial coordinates. A feature class (white boxes in Figure 2) is an object class that has spatialcoordinates. In terms of relationships, inheritance (indicated by a triangle) means that the

classes below inherit the properties and methods of the classes above them within the class

hierarchy. Multiplicity specifies how many objects can be associated with another object. Thenumber 1 signifies one and only one, whereas * signifies multiple associations.


Figure 2. UML notation of objects and classes, on the left generically, and on the right for a portion ofthe initial draft of the marine data model.

While building the conceptual model and defining the properties of each class, common

properties will begin to appear. For instance, it might be decided that all navigation featuresshould have an attribute for the official name of the expedition that they are associated with.

Rather than duplicating this property in all objects, a higher-order class (NavFeature in Figure2) is created to contain the common properties. This process ultimately results in a set of

intermediate, often abstract classes that model the system.

The creation of an analysis diagram is an iterative process that requires both top-down and

bottom-up analysis to define the structure of the object model. The objects and initial datamodel are built in UML and a schema is generated in ArcCatalog. The UML diagrams and

schema are at the "logical design" stage in the data modeling process. Fortunately the marinecommunity does not have to deal directly with UML (unless it really wants to!). Instead, users

may take advantage of an existing repository of CASE (computer aided software engineering)tools available in ArcGIS in order to generate their own schemas.

Final Data Model Content, Purpose and Use

At the final implementation phase (physical or internal design), four related elements are

produced for the marine community. in the production of four related elements:

1) an object-oriented ArcGIS Marine Data Model, specified in UML (via Visio software format),

that can be used in ArcGIS by most marine application development teams as a starting


point for structuring marine data. The physical UML is a detailed view of the design,

providing specifications of data types, relationships, and other details. This is the view ofthe database design that can be used to create an actual ArcGIS geodatabase. The

specific data needs of a given user may require modifications of, or extensions to, the basicdata model.

2) an easy-to-read poster (final analysis diagram) that presents the basic, conceptualstructure of the data model in UML. Project teams can use this to review the data model

with users and stakeholders.

3) several data sets that can be used to demonstrate the efficacy of the marine data model.

The data sets will be composed of public domain, marine data that may be freely used tosupport specific applications.

4) a final conceputal framework document, describing and explaining the data model,

demonstrating its use in ArcGIS, and providing examples of marine applications that usethe model. A data dictionary for the data and other reference material will also be provided.

These four elements serve to describe an initial set of essential marine objects identified by the

Marine Data Model Working Group. It will take several months of review and project work bythe working group, review team, and broader marine community to meet the challenge of

developing a good data model. It may be difficult for many organizations, particularly smallergroups and those without years of marine GIS experience, to understand the best way to

implement the data model. The goal of the model, however, as discussed earlier, is to make iteasier for people to implement successful projects so that their organizations can enjoy the

benefits of GIS.


In the end, we hope that a simple, yet powerful data model will emerge from our collective

experience. The final product will be freely available on ArcOnline(http://support.esri.com/datamodels) and Davey Jones Locker

(http://dusk.geo.orst.edu/djl/arcgis).

Data Model Description

Overview

The draft marine data model as expressed in the analysis diagram provides a logical grouping

of common themes, and within those major themes are logical groupings of severalgeodatabase classes or tables. The groupings also include a number of classes that indicate

specific data layers. Therefore, the analysis diagram provides a high-level overview of thethemes and products that could be used for a specific GIS project. The next three sections

briefly describe the broad themes of the data model, consisting of a conceptual frameworktheme, a core theme of four logical groupings or "packages", and a synthesis theme. And then

the discussion focuses on the core packages to describe in detail the object classes that existin each package, and the primary relationships between and among those object classes.

Conceptual FrameworkThe conceptual framework theme (Figure 3) focuses on the initial acquisition of marine data,and is thus concerned with the accurate sensing and collection of measurements from the

marine environment and the transformation of these measurements from raw to processed forGIS implementation.


Figure 3. Conceptual framework theme of the draft analysis diagram.

Here data collection is made in two ways: (1) short-term (2 weeks to 1 month) mobile entities,such as research cruises employing various instrument platforms, ROV deployments, or

submersible dives; or (2) long-term (1 year or more) fixed entities, such as hydrophones andvarious other types of moored instrumentation. For the mobile entities, data collection runs

gather in situ samples, casts, and tows of various types for future laboratory analysis. These


runs may be made at predefined sites, or along predefined transects or tracklines. For the fixed

entities, raw data are sent back to shore from the hydrophones or moorings for encryptionand/or processing. Marine observations from the mobile and fixed entities are made at points in

space and time and may have multiple assessments of the geophysical, geological, chemical,physical, and biological properties that exist in the marine environment. Each component of an

ocean observation group may have one to many assessments of data quality or error. In turn,one to many observation sets or types may arise from a particular ocean observation group.

These observation sets or types may be derived by a theoretical method or derived from asensor, created from a laboratory run, or derived by observing a process.

Figure 4. An extension of GIS features in the form of primary ESRI features and feature classes tobetter fit marine applications.


Figure 5. Common marine data types mapped to the abstract and feature classes of the ArcGIS marinedata model (draft of May, 2003).

Core PackagesThe conceptual framework feeds into the core of the ArcGIS marine model, which consists of 4

logical groupings of related object and feature classes. These groupings or “packages” hold

related or complementary sets of essential objects within the larger data model. A package ofobjects may be related by function or by type. The 4 marine packages are: Marine Features,

Marine Objects, Model Features, and Model Objects.


Figure 6. Core groupings or "packages" of objects and features within the data model (note that “MarineFeatures” should be in much larger font – not fixed before this went “to press” – sorry!)

Each package contains a set of object and feature classes and the relationships between those

classes. Each object class consists of a descriptive name and a set of attributes that define theobject. All marine object classes inherit properties from one of the basic object types that are

provided in ArcGIS. The forthcoming ArcGIS Marine Data Model book will describe in detail theobject and feature classes that exist in each of the core packages of the model, and the

primary relationships between and among those classes.


SynthesisA final component of the data model represents synthesis, analysis and interpretation resultingfrom the packages.

Figure 7. The concluding Synthesis, Analysis, Interpretation theme of the draft analysis diagram.

Marine Data Model Object Class GlossaryThe glossary will provide an introductory explanation of the classes being implemented in this

version of the ArcGIS Marine Data Model. This should provide enough information for somereasonable understanding of how any particular class could be used in an ArcGIS application.


It may be helpful to use the glossary in concert with the marine data types diagram (Figure 5).

The glossary will be expanded and finalized for the Marine Data Model book.

MARINE FEATURES: One of several types of abstract features that represents a plannedoperation or an entity in the marine environment. MarineFeaturescan have point, line, or polygon spatial representations. EachMarineFeature must have a MarineCode and a MarineID that isunique across the entire geodatabase. MarineFeature is usedextensively for creating relationships between features.The FeatureDataset containing feature classes for representingphysical maritime features.

Please refer to http://dusk.geo.orst.edu/djl/arcgis/docs.html for the most recentversion of the glossary (description of feature classes)

SAMPLE DATA

Generic Marine Data Sources

The table below (from Wright et al., 1997) is a data/function cross-reference matrix, wherefunction is essentially a particular subdiscipline of oceanography. The data/function matrix

shows a high-level classification of data for marine applications, the interdependence of dataand function, those functions or disciplines which create commonly required data, the

interdependence of certain functions (such as “Geology” and “Chemistry” ). It is particularlyuseful for pinpointing information generalities (i.e., data sets useful to more than one or all sub-

disciplines), which should in turn be reflected in the data model.


FUNCTION

PRIMARY DATA Geology Geophysics Chemistry/

Physics

Biology

Aerial Photography (Shallow) X X

Bathymetry - Multibeam X X X X

Bottom Pressure Recorder X X

Boundaries - marinecadastral

X X X X

Casts - CTD X

Casts - dissolved/particulate

X X

Casts - biology/macroplume X X

Current Meter Arrays X

EQ focal mechanisms X

EQ locations - terrestrial X

EQ locations - from T-phaseevents

X X

EQs - T-phase sourcelocation fixes

X X

Extensometer X X

Fish distribution X X

Flow fronts (lava) X X X

Gridlines X X X X

Habitat suitability indices X X X

Images - 35 mm, selected X X X

Images - ESC, selected X X X

Images - other raster


Images - Satellite X X

Images - Sidescan X X

Land Cover/Land Change(coastal)

X X

Locations - ESC shots X X X

Locations - Hydrothermalvents

X X X

Locations - 35 mm photo(photo-merge)

X X X

Locations - video frames,selected

X X X

Locations - marine mammals X

Markers X X X X

Miniature TemperatureRecorder

X X X X

Moorings X X X X

Overlays (logos, borders,interpretations)

X X X X

Samples - submersible rock,bio, water, or gas

X X X

Shoreline X X X X

Topography (coastal orisland)

X X X X

Tows - camera X X

Tows - camera -interpretations

X X

Tows - CTD X

Tows - Helium X

Tracks/nav points -submersible

X X X


Tracks/nav points - AUV X X X

Tracks/nav points - ROV X X X

Tracks/nav points - bathy orsidescan

X X

Transponders X X X X

Volcanic System Monitor X X

Sample Geodatabase Sources

A list of test geodatabases is provided at

http://support.esri.com/index.cfm?fa=downloads.dataModels.filteredGateway&dmid=21

and

http://dusk.geo.orst.edu/djl/arcgis/diag.html#data

Implementing the Model: Case Study Applications

A Preliminary Note About Prototyping a Design

ArcGIS provides tools to make it easy to move from a conceptual design to a physical design.Users should take advantage of this early in their project. For example, decisions about

subtyping classes are important for the implementation. If objects in a grouping have differentproperties to the point that they cannot be grouped together, then the object needs to be split

into two classes.

In general, objects should be lumped fewer classes wherever possible as this improves system

performance. In most projects, users need to be aggressive about reducing the number of


feature classes to ensure good performance. While subtyping decisions are not really a part of

the conceptual design process users should think about performance early in the project toensure that the design will work well in ArcGIS. Prototyping the design in a versioned

environment is easy to do with ArcGIS, and critical to a successful project. Case studies maybe downloaded from

http://support.esri.com/index.cfm?fa=downloads.dataModels.filteredGateway&dmid=21

and

http://dusk.geo.orst.edu/djl/arcgis/diag.html#data

A Note on Cross References to Existing StandardsThe ArcGIS Marine Data Model is a representation of the essential elements for a broad range

of marine and coastal data types and processes. It cannot include a comprehensive set of all

objects described in all applications, data structures, and standard processes. The model isintended as a tool to be used in support of the range of marine and coastal GIS specialists, and

provides a suggested base from which to build a marine-oriented geodatabase.

It is recognized, however, that many marine GIS users have substantial experience with asmaller set of marine models and with existing data and metadata standards. This section

provides a set of crosswalks – a set of relationships based on similarities – between theelements of these standards and the object and feature classes outlined in the ArcGIS Marine

Data Model. This section highlights the commonalities among data models and provides areference for the exchange of data between the data model and other standards.

Due to variations in the scope of the ArcGIS Marine Data Model and the individual standards,not every element of each standard will have a representation in the marine data model, and


objects described in the model may not be included in any particular standard. In some cases

there are more than one marine features that could correspond to a single element in a data ormetadata standard. Where this is the case, all possible matches are listed. In some cases,

elements in the data or metadata standards are defined within the basic functions of the GIS.These elements have no direct correlate in the ArcGIS Marine Data Model, but are implicit in its

use. In many cases, the definition of an element in a data or metadata standard will not matchprecisely the definition for an ArcGIS marine object. This is due in part to the many object

names that are defined several different ways by several groups of users. It is left to the user toadd specific attributes or behaviors to objects that will lead to the exact correspondences that

they may need for a specific application.

For starters, reserachers may be interested in creating crosswalks to the U.S. National

Hydrography Data Content Standard for Inland and Coastal Waterways (HDCS) and theInternational Hydrographic Organization's S57 Appendix A, "Object Catalog for Digital

Hydrographic Data" (IHO-S57). Note that there is an existing IHO S-57 ArcGIS data model fornautical charting (

ReferencesBaker, E.T. and G.A. Cannon, 1993. Long-term monitoring of hydrothermal heat flux using

moored temperature sensors, cleft segment, Juan de Fuca Ridge, Geophys. Res. Ltr.,20(17): 1855-1858.

Bartlett, D., 1993a. Space, time, chaos, and coastal GIS, International Cartographic

Conference. Internal Cartographic Conference, Cologne, Germany, pp. 539-551.


Bartlett, D.J., 1993b. Coastal zone applications of GIS: Overview. In St Martin, K. (Ed),

Explorations in Geographic Information Systems Technology Volume 3: Applications inCoastal Zone Research and Management. Clark Labs for Cartographic Technology and

Analysis Worcester, Massachusetts.

Bartlett, D.J., 2000. Working on the frontiers of science: Applying GIS to the coastal zone. In

Wright, D.J. and Bartlett, D.J., Marine and Coastal Geographical InformationSystems.Taylor & Francis, London, 11-24.

Cannon, G.A., D.J. Pashinski and T.J. Stanley, 1995. Fate of event hydrothermal plumes onthe Juan de Fuca Ridge, Geophys. Res. Ltr., 22(2): 163-166.

Chadwick, W.W., H.B. Milburn and R.W. Embley, 1995. Acoustic extensometer: Measuringmid-ocean spreading, Sea Technol., 36(4): 33-38.

Dziak, R.P., C.G. Fox and A.E. Schreiner, 1995. The june-july 1993 seismo-acoustic event at

coaxial segment, Juan de Fuca Ridge: Evidence for a lateral dike injection, Geophys. Res.Ltr., 22(2): 135-138.

Embley, R.W., W.W. Chadwick, Jr., I.R. Jonasson, D.A. Butterfield and E.T. Baker, 1995. Initialresults of the rapid response to the 1993 CoAxial event: Relationships between

hydrothermal and volcanic processes, Geophys. Res. Ltr., 22(2): 143-146.

ESRI, 2000. Multiuser Geographic Information Systems with ArcInfo 8, ESRI White Paper,

ESRI, Redlands, California, 50 pp.

Forestry Special Interest Group (FSIG), 2000. Forestry Data Model. ESRI, Redlands,

California, 31 pp., http://support.esri.com/datamodels

Fox, C.G., 1993. Five years of ground deformation monitoring on axial seamount using a

bottom pressure recorder, Geophys. Res. Ltr., 20(17): 1859-1862.


Fox, C.G. and S.R. Hammond, 1994. The vents program T-phase project and noaa's role in

ocean environmental research, Marine Technology Society Journal, 27(4): 70-73.

Goodchild, M.F., 2000. Foreword. In Wright, D.J. and Bartlett, D.J., Marine and CoastalGeographical Information Systems.Taylor & Francis, London, xv.

Laurini, R., and D. Thompson, 1992. Fundamentals of Spatial Information Systems, Academic

Press, San Diego, California, 680 pp.

Li, R., 2000. Data models for marine and coastal geographic information systems. In Wright,

D.J. and Bartlett, D.J., Marine and Coastal Geographical Information Systems.Taylor &Francis, London, 25-36.

Li, R. and N.K. Saxena, 1993. Development of an integrated marine geographic informationsystem, Mar. Geod., 16: 293-307.

Lockwood, M. and R. Li, 1995. Marine geographic information systems: What sets them apart?,

Mar. Geod., 18(3): 157-159.

Lupton, J.E., J.R. Delaney, H.P. Johnson and M.K. Tivey, 1985. Entrainment and vertical

transport of deep-ocean water by buoyant hydrothermal plumes, Nature, 316: 621-623.

Wright, D.J. and D.J. Bartlett (Editors), 2000. Marine and Coastal Geographical InformationSystems. Taylor & Francis, London, 320 pp.

Wright, D.J. and M.F. Goodchild, 1997. Data from the deep: Implications for the GIS

community, Int. J. Geog. Inf. Sci., 11(6): 523-528.

Wright, D.J., C.G. Fox and A.M. Bobbitt, 1997. A scientific information model for deepsea

mapping and sampling, Mar. Geod., 20(4): 367-379.

Zeiler, M., 1999. Modeling Our World: The ESRI Guide to Geodatabase Design, ESRI Press,

Redlands, California, 199 pp.


Appendices

List of Acronynms Commonly Used with Marine GIS Data Sets

ATV Advanced Tethered Vehicle (US Navy)

CM Current Meter. See Cannon et al. (1995)

CTD Conductivity-Temperature-Depth

CSC Coastal Services Center (NOAA)

DBMS Database Management System

DEM Digital Elevation Model

DLG Digital Line Graph

DOQ Digital Orthophoto Quadrangle

DRG Digital Raster Graphics

EEZ Exclusive Economic Zone

ENC Electronic Nautical (or Navigational) Charting

EQ Earthquake


ESC Electronic Still Camera

FGDC Federal Geographic Data Committee

GMT Generic Mapping Tools (http://gmt.soest.hawaii.edu/)

GPS Global Positioning System

HARU Hydrophone Acoustic Research Underwater (recently developed at NOAA-PMEL,Newport, OR)

IHO International Hydrographic Organization

LCLUC Land Cover Land Use Change

LIDAR LIght Detection And Ranging

MBARI Monterey Bay Aquarium Research Institute

MHW Mean High Water

MHHW Mean Higher High Water

MLLW Mean Lower Low Water

MMS Minerals Management Service


MPA Marine Protected Area

MSL Mean Sea Level

MTR Miniature Temperature Recorder. See Baker and Cannon (1993)

NOAA National Oceanic and Atmospheric Administration

NM Nautical Mile

NPS National Park Service

OCSLA Outer Continental Shelf Lands Act

PMEL Pacific Marine Environmental Laboratory (Newport, OR and Seattle, WA)

ROPOS Remotely-Operated Platform for Ocean Science (Fisheries and Oceans Canada).See Embley et al (1995)

ROV Remotely-Operated Vehicle

SOSUS SOund SUrveillance System (US Navy). See Fox and Hammond (1994)

T-Phase Tertiary-phase (seismically generated acoustic waves that propagate over greatdistances in the oceanic sound channel). See Dziak et al (1995) and Fox and Hammond(1994)

UML Unified Modeling Language


UNOLS University National Oceangraphic Laboratory System

USFW United States Fish & Wildlife

USGS United States Geological Survey

VSM Volcanic System Monitor See Fox (1993)

WOCE World Ocean Circulation Experiment. See Lupton et al (1985)

XTS Extensometer. See Chadwick et al (1995)

Overview of ArcGIS Object and Geodatabase Concepts

[ borrowed heavily from Parcels document and will be completely reworked for the Marine DataModel book]This section defines the ArcGIS geodatabase elements that are used in the marine data model.These concepts are described more fully in Modeling our World (Zeiler, 1999) and MultiuserGeographic Information Systems with ArcInfo 8 (ESRI, 2000), and are repeated here in termsof marine information.

Objects

An object represents a real world object, such as a fish habitat, an underwater volcano, or amarker buoy, and is stored as a row in a relational database table.

Objects in ArcGIS do not have a geographic representation, such as a table of marker buoynames or a list of habitat suitablity indices. A table of habitat suitability objects can beassociated to a set fish habitat features through a relationship class as shown in Figure ....


Features

Features are geographic objects that have a spatial location defined. More specifically, afeature is just like an object but it also has a geometry or shape column in the relationaldatabase table for the object. Through inheritance a feature has all of the methods of the objectclass, but it also has more methods. One way to think of this is that a feature is a special kindof object with additional capabilities.

For example, ...

Simple feature classes contain points, lines, polygons, or annotation without any topologicalrules between them. The geodatabase also has the concept of more sophisticated featureclasses, such as network features and topological features. Network features inherit from theNetworkFeature class and each feature class participates in a geometric network. As anexample, if water valves and mains are in the same geometric network, if we move the valvethe pipes will stretch, keeping their physical connection to the valves.

In the marine world ...

Feature Data Set

A feature data set is simply a collection of feature classes that share a common spatialreference. A spatial reference is part of the definition of the geometry field in the database. Asan example, a set of coastal land parcels stored in NAD27, UTM Zone 5 could not be in thesame feature data set as Public Land Survey System features stored in geographiclatitude/longitude coordinates. Topological feature classes are bound within a topology graphthat manages the feature classes in an integrated topological unit. You may choose to organizefeature classes in multiple feature data sets, but related topological feature classes must becontained within the same feature data set so that topological relationships are not broken dueto minor differences in mathematical calculations between geometries in different spatialreferences.

Relationships

Three types of relationships can exist between objects or features: spatial, explicit andtopological. Spatial relationships are merely the spatial coincidence of features. For example,rather than storing which Tax District a coastal land parcel is located in as an attribute of theparcel, a spatial operator like “is inside of” can be used to determine which tax district theparcel falls within. These are capabilities inherent in a GIS that simplifies the process of datamaintenance and analysis over a basic relational database system. Sometimes, however, youwill need to maintain more specific information about related objects and features.


Explicit relationships are created between objects as a relationship class. One object serves asthe origin class and the other object is referred to as the destination class. These are similar tothe primary and foreign key relationships in relational databases; the geodatabase has its owninfrastructure for managing these relationships in a versioned database environment. ArcGISalso provides the ability for objects to message each other as part of the relationship definition.This provides programmers the ability to build sophisticated behavior into objects. In thisexplanation we have used the word object, but since features are a special kinds of objects,explicit relationships apply to any and all kinds of features in ArcGIS.

In this way, ArcGIS manages both the attributes and behavior of objects, and programmerswork in an object-component environment that is abstracted from the underlying physicaldatabase model and augmented by a programming framework of many interfaces andmethods. The geodatabase provides the object-relational mapping and manages the integrityof the data in the underlying database. Explicit relationships are one way to trigger behavior inthe system but you should be careful to select the smallest set of relationships possible andunderstand how relationships impact system behavior. More information on this topic can befound in Building a Geodatabase in your ArcGIS documentation set.

Examples of topological relationships are geometric networks and planar topologies. Asmentioned previously, geometric networks result in system behavior that ensures theconnectivity of a network data model. Planar topologies ensure that rules within and betweenfeature classes in a feature data set are enforced through topological graphs. One example ofthis is that ownership polygons are not allowed to overlap each other.

ArcGIS Marine Data Model - Dawn...

Documents

Transcript of ArcGIS Marine Data Model - Dawn...