(June 2003) ArcGIS Data Models. ArcGIS Marine Data Model Reference

Transcription

1 ArcGIS Marine Data Model Reference ArcGIS Marine Data Model (June 2003) Dawn J. Wright, Oregon State U. Patrick N. Halpin, Duke U. Michael Blongewicz, DHI Steve Grisé, ESRI Redlands Joe Breman, ESRI Redlands This document provides an overview of the ArcGIS Marine Data Model. This model focuses on important features of the ocean realm, both natural and manmade, with a view towards the many applications of marine GIS data. ArcGIS Data Models

2 TABLE OF CONTENTS Acknowledgements... 4 Introduction... 5 Why a Marine Data Model?... 6 Intended Audience and Scope of the Model... 8 The Process of Building a Data Model Final Data Model Content, Purpose and Use Data Model Description Overview Conceptual Framework Core Packages Synthesis Marine Data Model Object Class Glossary SAMPLE DATA Generic Marine Data Sources Sample Geodatabase Sources Implementing the Model: Case Study Applications A Preliminary Note About Prototyping a Design A Note on Cross References to Existing Standards References List of Acronynms Commonly Used with Marine GIS Data Sets Overview of ArcGIS Object and Geodatabase Concepts Objects Features Feature Data Set Relationships ArcGIS Marine Data Model

3 ArcGIS Marine Data Model 3

4 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 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. 4 ArcGIS Marine Data Model

5 Introduction Just as fish adapted to the terrestrial environment by evolving into amphibians, so GIS must adapt 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 automate the 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 from applications 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-based applications, 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 increased commercial, academic, and political interest in coastal regions, oceans, and marginal seas have spurred fundamental improvements in the toolbox of GIS, while extending the methodological framework for marine applications. Many challenges remain, such as addressing the multiple dimensionality and dynamism of oceanographic data, handling the temporal 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 their relative 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). ArcGIS Marine Data Model 5

6 Why a Marine Data Model? As noted by Bartlett (2000), one of the most important lessons to be learned from collective experience 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, many marine 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 polygons with 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 marker buoy 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 individual objects 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 and concerns 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. 6 ArcGIS Marine Data Model

7 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. ArcGIS Marine Data Model 7

8 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 coastal GIS, as application domains and user communities developed fairly independently of each other. This is not unlike how traditional oceanography departments in North America have often grouped 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 both basic 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 of GIS implementation. In other words, the data sets are the same, regardless of how they are 8 ArcGIS Marine Data Model

9 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 military oceanographers, coastal resource managers and consultants, marine technologists, nautical archaeologists, marine conservationists, marine and coastal geographers, fisheries managers and 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 and coastal data types and processes--it cannot include a comprehensive catalog of objects meeting 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. For example, the priority data themes of organizations such as the NOAA Coastal Services Center- -bathymetry, shoreline, and marine cadastral boundaries--are certainly taken into account. The model 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 Data Model 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, and Parcels (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 will actually 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. ArcGIS Marine Data Model 9

10 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: The Process of Building a Data Model A data model for marine applications will undoubtedly be complex because of the many varied uses 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 (Figure 1). 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 surface temperature versus gridded bathymetry versus four-dimensional data, etc.). It has become increasingly obvious that a comprehensive data model is needed to support a much wider range 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. 10 ArcGIS Marine Data Model

11 Figure 1. The long-term ecosystem observatory instruments and platforms of the Rutgers University Coastal 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 humanorientation to implementation in a computer (Laurini and Thompson; Li, 2000): ArcGIS Marine Data Model 11

12 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 the model. 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 the identification 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 modeling process. 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 of the 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 a logical 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 12 ArcGIS Marine Data Model

13 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 in an 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 toplevel 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 spatial coordinates. 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. The number 1 signifies one and only one, whereas * signifies multiple associations. ArcGIS Marine Data Model 13

14 Figure 2. UML notation of objects and classes, on the left generically, and on the right for a portion of the 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 features should 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 Figure 2) 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 data model 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 marine community 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 14 ArcGIS Marine Data Model

15 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 of the 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 basic data model. 2) an easy-to-read poster (final analysis diagram) that presents the basic, conceptual structure 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 to support 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 use the 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 by the 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 smaller groups 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 it easier for people to implement successful projects so that their organizations can enjoy the benefits of GIS. ArcGIS Marine Data Model 15

16 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 ( and Davey Jones Locker ( 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 several geodatabase 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 the themes 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 framework theme, 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 exist in each package, and the primary relationships between and among those object classes. Conceptual Framework The 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 for GIS implementation. 16 ArcGIS Marine Data Model

17 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 and various 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 ArcGIS Marine Data Model 17

18 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 encryption and/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 a sensor, 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 to better fit marine applications. 18 ArcGIS Marine Data Model

19 Figure 5. Common marine data types mapped to the abstract and feature classes of the ArcGIS marine data model (draft of May, 2003). Core Packages The 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 of objects may be related by function or by type. The 4 marine packages are: Marine Features, Marine Objects, Model Features, and Model Objects. ArcGIS Marine Data Model 19

20 Figure 6. Core groupings or "packages" of objects and features within the data model (note that Marine Features 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 the object. 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 the object and feature classes that exist in each of the core packages of the model, and the primary relationships between and among those classes. 20 ArcGIS Marine Data Model

21 Synthesis A final component of the data model represents synthesis, analysis and interpretation resulting from the packages. Figure 7. The concluding Synthesis, Analysis, Interpretation theme of the draft analysis diagram. Marine Data Model Object Class Glossary The 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 some reasonable understanding of how any particular class could be used in an ArcGIS application. ArcGIS Marine Data Model 21

22 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 planned operation or an entity in the marine environment. MarineFeatures can have point, line, or polygon spatial representations. Each MarineFeature must have a MarineCode and a MarineID that is unique across the entire geodatabase. MarineFeature is used extensively for creating relationships between features.the Feature Dataset containing feature classes for representing physical maritime features. Please refer to for the most recent version 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, where function is essentially a particular subdiscipline of oceanography. The data/function matrix shows a high-level classification of data for marine applications, the interdependence of data and function, those functions or disciplines which create commonly required data, the interdependence of certain functions (such as Geology and Chemistry ). It is particularly useful for pinpointing information generalities (i.e., data sets useful to more than one or all subdisciplines), which should in turn be reflected in the data model. 22 ArcGIS Marine Data Model

23 FUNCTION PRIMARY DATA Geology Geophysics Chemistry/ Biology Physics Aerial Photography (Shallow) Bathymetry - Multibeam Bottom Pressure Recorder Boundaries - marine cadastral Casts - CTD Casts - dissolved/ particulate Casts - biology/macroplume Current Meter Arrays EQ focal mechanisms EQ locations - terrestrial EQ locations - from T-phase events EQs - T-phase source location fixes Extensometer Fish distribution Flow fronts (lava) Gridlines Habitat suitability indices Images - 35 mm, selected Images - ESC, selected Images - other raster ArcGIS Marine Data Model 23

24 Images - Satellite Images - Sidescan Land Cover/Land Change (coastal) Locations - ESC shots Locations - Hydrothermal vents Locations - 35 mm photo (photo-merge) Locations - video frames, selected Locations - marine mammals Markers Miniature Temperature Recorder Moorings Overlays (logos, borders, interpretations) Samples - submersible rock, bio, water, or gas Shoreline Topography (coastal or island) Tows - camera Tows - camera - interpretations Tows - CTD Tows - Helium Tracks/nav points - submersible 24 ArcGIS Marine Data Model

25 Tracks/nav points - AUV Tracks/nav points - ROV Tracks/nav points - bathy or sidescan Transponders Volcanic System Monitor Sample Geodatabase Sources A list of test geodatabases is provided at and 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 different properties 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 ArcGIS Marine Data Model 25

26 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 to ensure 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 may be downloaded from and A Note on Cross References to Existing Standards The 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 is intended 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 a smaller 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 the elements 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 a reference 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 26 ArcGIS Marine Data Model

27 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 or metadata 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 match precisely 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 to add 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 the International 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 for nautical charting ( References Baker, E.T. and G.A. Cannon, Long-term monitoring of hydrothermal heat flux using moored temperature sensors, cleft segment, Juan de Fuca Ridge, Geophys. Res. Ltr., 20(17): Bartlett, D., 1993a. Space, time, chaos, and coastal GIS, International Cartographic Conference. Internal Cartographic Conference, Cologne, Germany, pp ArcGIS Marine Data Model 27

28 Bartlett, D.J., 1993b. Coastal zone applications of GIS: Overview. In St Martin, K. (Ed), Explorations in Geographic Information Systems Technology Volume 3: Applications in Coastal Zone Research and Management. Clark Labs for Cartographic Technology and Analysis Worcester, Massachusetts. Bartlett, D.J., Working on the frontiers of science: Applying GIS to the coastal zone. In Wright, D.J. and Bartlett, D.J., Marine and Coastal Geographical Information Systems.Taylor & Francis, London, Cannon, G.A., D.J. Pashinski and T.J. Stanley, Fate of event hydrothermal plumes on the Juan de Fuca Ridge, Geophys. Res. Ltr., 22(2): Chadwick, W.W., H.B. Milburn and R.W. Embley, Acoustic extensometer: Measuring mid-ocean spreading, Sea Technol., 36(4): Dziak, R.P., C.G. Fox and A.E. Schreiner, 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): Embley, R.W., W.W. Chadwick, Jr., I.R. Jonasson, D.A. Butterfield and E.T. Baker, Initial results of the rapid response to the 1993 CoAxial event: Relationships between hydrothermal and volcanic processes, Geophys. Res. Ltr., 22(2): ESRI, Multiuser Geographic Information Systems with ArcInfo 8, ESRI White Paper, ESRI, Redlands, California, 50 pp. Forestry Special Interest Group (FSIG), Forestry Data Model. ESRI, Redlands, California, 31 pp., Fox, C.G., Five years of ground deformation monitoring on axial seamount using a bottom pressure recorder, Geophys. Res. Ltr., 20(17): ArcGIS Marine Data Model

29 Fox, C.G. and S.R. Hammond, The vents program T-phase project and noaa's role in ocean environmental research, Marine Technology Society Journal, 27(4): Goodchild, M.F., Foreword. In Wright, D.J. and Bartlett, D.J., Marine and Coastal Geographical Information Systems.Taylor & Francis, London, xv. Laurini, R., and D. Thompson, Fundamentals of Spatial Information Systems, Academic Press, San Diego, California, 680 pp. Li, R., 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, Li, R. and N.K. Saxena, Development of an integrated marine geographic information system, Mar. Geod., 16: Lockwood, M. and R. Li, Marine geographic information systems: What sets them apart?, Mar. Geod., 18(3): Lupton, J.E., J.R. Delaney, H.P. Johnson and M.K. Tivey, Entrainment and vertical transport of deep-ocean water by buoyant hydrothermal plumes, Nature, 316: Wright, D.J. and D.J. Bartlett (Editors), Marine and Coastal Geographical Information Systems. Taylor & Francis, London, 320 pp. Wright, D.J. and M.F. Goodchild, Data from the deep: Implications for the GIS community, Int. J. Geog. Inf. Sci., 11(6): Wright, D.J., C.G. Fox and A.M. Bobbitt, A scientific information model for deepsea mapping and sampling, Mar. Geod., 20(4): Zeiler, M., Modeling Our World: The ESRI Guide to Geodatabase Design, ESRI Press, Redlands, California, 199 pp. ArcGIS Marine Data Model 29

30 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 30 ArcGIS Marine Data Model

31 ESC Electronic Still Camera FGDC Federal Geographic Data Committee GMT Generic Mapping Tools ( 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 ArcGIS Marine Data Model 31

32 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 great distances in the oceanic sound channel). See Dziak et al (1995) and Fox and Hammond (1994) UML Unified Modeling Language 32 ArcGIS Marine Data Model

33 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) TS 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 Data Model 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 Multiuser Geographic Information Systems with ArcInfo 8 (ESRI, 2000), and are repeated here in terms of marine information. Objects An object represents a real world object, such as a fish habitat, an underwater volcano, or a marker 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 buoy names or a list of habitat suitablity indices. A table of habitat suitability objects can be associated to a set fish habitat features through a relationship class as shown in Figure... ArcGIS Marine Data Model 33

34 Features Features are geographic objects that have a spatial location defined. More specifically, a feature is just like an object but it also has a geometry or shape column in the relational database table for the object. Through inheritance a feature has all of the methods of the object class, but it also has more methods. One way to think of this is that a feature is a special kind of object with additional capabilities. For example,... Simple feature classes contain points, lines, polygons, or annotation without any topological rules between them. The geodatabase also has the concept of more sophisticated feature classes, such as network features and topological features. Network features inherit from the NetworkFeature class and each feature class participates in a geometric network. As an example, if water valves and mains are in the same geometric network, if we move the valve the 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 spatial reference. A spatial reference is part of the definition of the geometry field in the database. As an example, a set of coastal land parcels stored in NAD27, UTM Zone 5 could not be in the same feature data set as Public Land Survey System features stored in geographic latitude/longitude coordinates. Topological feature classes are bound within a topology graph that manages the feature classes in an integrated topological unit. You may choose to organize feature classes in multiple feature data sets, but related topological feature classes must be contained within the same feature data set so that topological relationships are not broken due to minor differences in mathematical calculations between geometries in different spatial references. Relationships Three types of relationships can exist between objects or features: spatial, explicit and topological. 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 the parcel, a spatial operator like is inside of can be used to determine which tax district the parcel falls within. These are capabilities inherent in a GIS that simplifies the process of data maintenance and analysis over a basic relational database system. Sometimes, however, you will need to maintain more specific information about related objects and features. 34 ArcGIS Marine Data Model

35 Explicit relationships are created between objects as a relationship class. One object serves as the origin class and the other object is referred to as the destination class. These are similar to the primary and foreign key relationships in relational databases; the geodatabase has its own infrastructure for managing these relationships in a versioned database environment. ArcGIS also 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 this explanation 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 programmers work in an object-component environment that is abstracted from the underlying physical database model and augmented by a programming framework of many interfaces and methods. The geodatabase provides the object-relational mapping and manages the integrity of the data in the underlying database. Explicit relationships are one way to trigger behavior in the system but you should be careful to select the smallest set of relationships possible and understand how relationships impact system behavior. More information on this topic can be found in Building a Geodatabase in your ArcGIS documentation set. Examples of topological relationships are geometric networks and planar topologies. As mentioned previously, geometric networks result in system behavior that ensures the connectivity of a network data model. Planar topologies ensure that rules within and between feature classes in a feature data set are enforced through topological graphs. One example of this is that ownership polygons are not allowed to overlap each other. ArcGIS Marine Data Model 35