www.geoinformatics.com

� Hydro Special � ERDAS Interview �Acquisition Sensors

�Mapping Cultural Heritage Underwater � Arc Marine Data Model

M a g a z i n e f o r S u r v e y i n g , M a p p i n g & G I S P r o f e s s i o n a l s April/May 2008 Volume 11

3

Process and Product

The Arc Marine Data ModelOver the past few years ESRI, with a significant amount of user community input, has been engaged in the exercise of

building “industry-specific” data models for ArcGIS. A new marine data model (Arc Marine) has been developed for those

who apply GIS to the coasts, estuaries, marginal seas, and/or the deep ocean. This article provides an overview of the

activities that led to the release of the data model and accompanying reference book (‘Arc Marine: GIS for a Blue Planet’),

with an invitation for those interested to participate in the continued refinement and improvement of Arc Marine via the

preparation of additional use cases.

By Dawn J. Wright

One of the most important lessons to belearned from collective experience in theapplication domain of marine GIS, both published and unpublished, is the impor-tance of rigorous data modeling beforeattemp ting to implement a GIS database.Indeed, data models lie at the very heart ofGIS, as they determine the ways in whichreal-world phenomena may best be repre-sented in digital form. With regard to ESRIproducts, many marine and coastal practi-tioners and organizations have invested inthe coverage data model. Although this haslargely been successful, coverages haveimportant shortcomings. For example, features are aggregated into homogenouscollections of points, lines, and polygonswith generic, 1- and 2-dimensional “behav-

ior.” And there is no way to distinguishbetween behaviors within feature classes:e.g., the behavior of point representing amarker buoy is identical to that of a pointrepresenting a pulsing transponder; thebehavior of a line representing a road isidentical to the behavior of a line represent-ing a dynamic shoreline.

In ESRI’s recent object-oriented data modelcalled the geodatabase, GIS features are“smarter”, i.e., they can be endowed withreal-world behaviors for individual objectswithin the same categories, and any sort ofrelationship may be defined among them.This has wonderful implications for marineand coastal applications, but importantquestions and concerns were still expressed

at the outset of the Arc Marine initiative in2001. Given the existing investment, howand when should one make the transitionto object-oriented data model and datastructure (e.g., the geodatabase in ArcGIS)?How well are marine application domainrequirements currently met in object-orienteddata structures such as the geodatabasestructure? What are the potential benefits?For users, any of the ArcGIS data modelsprovide a basic template for implementingGIS projects (i.e., inputting, formatting, geo-processing, and sharing data, creating maps,performing analyses, etc.), thereby helpingto simplify and standardize the integrationof data at various jurisdictional levels (i.e.,local, state/provincial, national, global). Fordevelopers, they provide a basic framework

36

Art ic le

April/May 2008

Figure 1. Graphic depicting the various modes ofmarine data collection. Modified and reproduced by

permission of the Partnership for InterdisciplinaryStudies of Coastal Oceans, www.piscoweb.org.

for writing program code and maintainingapplications. As such, the specific goals thatdrove the development of Arc Marine fromthe outset were:• Production of a common structure, a “geo-

database template”, for assembling, man-aging, and publishing marine data inArcGIS. 1. For example, the model is specified in

an industry-standard modeling nota-tion called the Unified ModelingLanguage (UML). And because UMLcode is easily converted to an ArcGISgeodatabase, users can immediatelybegin populating the geodatabase,rather than having to design it fromscratch.

2. Users can produce, share, andexchange data in similar formats.

3. Unified approaches encourage deve -lopment teams to extend and improveArcGIS software.

• Extending the power of marine GIS analy-ses by providing a framework for incorpo-rating rules and behaviors in data, anddealing more effectively with scale depen-dencies.

• In the final analysis, aiding users in afuller understanding of object-orientedArcGIS, particularly if making a transitionfrom the use of shapefiles and coverages.For instance, in the core ArcGIS datamodel, arc-node topology can be used inconjunction with other new and powerfuldata structures. Routes and regions arerelegated to feature classes. And relation-ships between tables can be preserved,

with regard to the ESRI geodatabase. WithESRI’s great success in fostering a grassroots,user community approach to building cus-tomized data models for various applications,the working group was eager to accept theiradvice and consultation on how best to navi-gate from start to finish. This is illustrated inFigure 2 & 3.

The author served as project manager and,along with Pat Halpin of Duke University, asdiscipline/domain technical leads. Disci pline/domain technical leads are deeply immersedin the subject matter, and are typically leaders in implementing GIS projects withinthat discipline. They provide technical leader-ship in the user community in order to helppeople understand what is being worked onand how it is relevant to their organization orresearch group. The discipline/domain techni-cal leads need to understand the disciplinewell enough to talk about the big issues: i.e.,current and evolving federal standards, typicalprojects, what should be important featuresin the data model design, etc. They are alsothe design partners of the ArcGIS technicallead.

Michael Blongewicz of DHI Water &Environment served as the ArcGIS technicallead. He developed and maintained the UMLdiagrams throughout the life of the project,and in collaboration with the discipline/domainleads, facilitated the technical design andreviews of the model, intimately understan -ding all of the technical issues involved, andable to explain the rationale behind modelingdecisions.

Steve Grisé and then Joe Breman served thecritical role of the industry manager/disci -plinary experts from ESRI, balancing the per-spectives of data producers, data users, andbusiness partners within the marine commu-nity, while providing crucial input on the datamodel design and implementation. They alsocollaborated with discipline/domain leads toorganize meetings and workshops, ensuringthat key players were from within ESRI were

maintained, and more efficiently managed.It should be noted that, although Arc Marinewas designed to be instantiated as a geo-database in ArcGIS, its UML diagrams couldbe used to generate schema for other GISpackages or for other data managementsolutions. For instance, Arc Marine’s UML hasbeen converted to an XML/GML (eXtensible/Geography Markup Language) schema, aswell as to an ontology in OWL (WebOntology Language) that can be browsed intools such as Protégé. Protégé is a free,open source ontology editor used to con-struct domain models and knowledge-basedapplications that can be used in taxonomiesand classifications, database schemas out-side of GIS, and semantic web services(http://protege.stanford.edu).

The Process of Building a Data ModelA marine data model working group was ini-tiated in 2001 to begin designing the datamodel and to address the concerns above

Latest News? Visit www.geoinformatics.com

Art ic le

37April/May 2008

Figure 2. The Arc Marine development process from the standpoint of the core working group but also a broader community of external reviewers, partners, use case testers.

Figure 3. The development process presented from the standpoint of the core working group only, where the technical lead and the domain experts work together on the conceptual and logical designs.

The entire process took six years.

informed and involved.Over the course of the model’s developmentfrom 2001 to 2007 (Figure 2 + 3, and sidebarof dusk.geo.orst.edu/djl/arcgis/about.html),there were three 2-day workshops hosted atESRI headquarters, and at ESRI InternationalUser Conferences (UCs) from 2003-2007:three technical workshops, one paper ses-sion, and several presentations at marinespecial interest group meetings. This culmi-nated in the publication of ‘Arc Marine: GIS

for a Blue Planet’, which was released at the2007 ESRI UC.

Scope of Arc MarineAlthough the focus of Arc Marine is on boththe deep ocean and the coast - and itattempts to represent the essential elementsfor a broad range of marine and coastal datatypes and processes - it cannot include a comprehensive catalogue of objects meeting the needs of all user groups and

applications. However, those elements thatare common to many marine GIS users havebeen identified to make the core as exhaus-tive and generic as possible. Therefore, themodel is a starting point upon which tobuild on and leverage the experiences of abroader range of practitioners. Practitionersmay take the core, generic data model andadd their own attributes, tables and rela-tionships to suit their specific applicationneeds (Figure 4). The generic core of themodel should be left intact so that developers can code additional softwaretools based on the core that take advantageof the known entities in the database. Forexample, if certain attributes are removedfrom core feature classes or tables, newsoftware tools (such as DHI’s Time SeriesManager) will not work properly.

A data model for marine applications willundoubtedly be complex because of themany varied uses of the data. And modernmarine data sets are generated by anextremely varied array of instruments andplatforms, all with differing formats, resolutions, and sets of attributes (Figure 5).Not only do a wide variety of data sourcesneed to be dealt with, but a myriad of data “structures” as well (e.g., tables ofchemical concentration versus raster imagesof sea surface temperature versus gridded

38

Art ic le

April/May 2008

Figure 4. Design strategy for Arc Marine where the core is as exhaustive, temporally dynamic, and generic as possible, but can be customized by various user groups (such as marine animal

tracking or benthic habitat mapping) for use within their specific enterprise.

Figure 5. A typical lifecycle in the creation of a customized ArcGIS data model. Modified and reproduced by permission of ESRI.

bathymetry versus four-dimensional data,etc.). It has become increasingly obviousthat a comprehensive data model is neededto support a much wider range of marineobjects, and that this is essential foradvanced management, cartographic andanalytical tasks. Arc Marine seeks to identify and organize these objects.

Design StagesData model design consists of at least threestages, increasing in abstraction as one goesfrom human-orientation to implementationin a computer:1. conceptual design (where the real world

is simplified according to applicationrequirements, and an initial model is populated with spatial objects andattributes in the form of entity-relation(ER) diagrams)

2. logical design (where ER diagrams areconverted to some kind of schema, suchas a table)

3. physical or internal design (where thefunctions of actual hardware and soft ware must be considered for actualimplementation of the model, in the caseof ArcGIS as a geodatabase repository,which can then be populated with theuser’s data)

attributes. All marine feature and objectclasses inherit properties from one of thebasic feature and object types that are pro-vided in ArcGIS. The major groupings holdrelated or complementary sets of essentialfeature classes and objects within the larg-er data model, related by function or type.Arc Marine groupings include: Marine Points.Marine Lines, Marine Areas, Time Series &Measurements, and Mesh (used for storingthe results of numerical modeling of marinephenomena, particularly finite element modeling).

With UML in hand, a user may participate inthe physical design stage by taking advan-tage of an existing collection of CASE (com-puter aided software engineering) tools inArcGIS in order to generate their ownschema. For example, an empty geo-database can be created in ArcCatalog, andthe Schema Wizard used to translate to onlythose portions of the UML that are neededfor a particular project to an XMI (XMLInterchange) template or *.mdb repository.This in turn allows the user to populate thatgeodatabase with their own data for use ina specific GIS project, with all the necessaryfeature classes, attributes, and relationshipsfrom the data model intact.

The first stage in the data modeling processis to define the overall scope and contentof the model. From an external designstandpoint, this involves the challengingtask of identifying the common, essential“things” that are modeled in most GIS pro-jects within an application domain. From aconceptual standpoint, it involves the creation of an analysis or in the case of ArcMarine, a “common marine data types” dia-gram (Figure 6), with the identification ofmajor thematic groups and an initial set ofobject classes within these groups. The com-mon marine data types diagram was there-fore at the “conceptual design” stage in thedata modeling process for Arc Marine, andwas created and refined at the first two userworkshops hosted at ESRI headquarters inRedlands, California.

Moving to the logical design stage, the com-mon themes from the common marine datatypes provided the major feature and objectclasses, and relationships that were definedin UML (e.g., Figure 7). These were organizedinto major groupings containing a set of fea-ture classes and supporting object classes,with the relationships between those clas -ses. Each feature and object class consistsof a descriptive name and a set of defining

Latest News? Visit www.geoinformatics.com

Art ic le

39April/May 2008

Figure 6. Common data types of Arc Marine from which feature classes, object classes, and relationships were eventually derived for the UML, and ultimately the geodatabase repository. A larger version of this diagram may be downloaded from dusk.geo.orst.edu/djl/arcgis/diag.html.

Conclusion: Final Data ModelContent, Purpose and UseThe model has now reached initial maturitywith the following products available to theinternational marine community:1. A final reference book, ‘Arc Marine: GIS for

a Blue Planet’, and companion web siteat dusk.geo.orst.edu/djl/arcgis describingand explaining the data model, demon-strating its implementation in ArcGIS, andproviding thirteen use cases of variousmarine applications (along with featureand object class glossaries, lessonslearned and helpful tips/tricks). The rela -ted items below are all available on thecompanion web site.

2. The Arc Marine data model itself, specifiedin UML (via Microsoft Visio software) andfurther as an XMI (XML Interchange) tem-plate or *.mdb geodatabase file, that canbe used by most marine application devel-opment teams as a starting point for struc-turing marine data. The physical UML is adetailed view of the design, providingspecifications of data types, relationships,and other details. The specific data needsof a given user may require modificationsof, or extensions to, the basic data model.

3. A large reference poster that presents thebasic, conceptual structure of the datamodel in UML. Project teams can use thisto review the data model with users andstakeholders.

4. An Arc Marine tutorial for new users, avail-able on the companion web site.

modeling efforts such as Arc Hydro, the S-57 Data Model (for electonic nauticalcharting), the Atmospheric Data Model, and,even the ArcGIS Parcels Data Model forcoastal land development. Once a datamodel is designed and initially implemen -ted, then the many ways it will be used willbe become clearer, and it can be refinedaccordingly.

Dr. Wright is professor of geography and

oceanography at Oregon State University. She has for

many years been interested in solving problems

related to the management and spatial analysis of

oceanographic data, with an emphasis on

application issues for GIS.

Visit her Home Page at: dusk.geo.orst.edu

Davey Jones’ Locker Lab – dusk.geo.orst.edu/djl

Main Arc Marine Web Site –

dusk.geo.orst.edu/djl/arcgis

Acknowledgements: The author gratefully acknow -

ledges her collaborators on Arc Marine, Michael

Blongewicz, Pat Halpin, and Joe Breman, as well as

Steve Grisé and Simon Evans of ESRI, and

international and case study team listed at

dusk.geo.orst.edu/djl/arcgis/people.html, all of whom

are deeply thanked for providing helpful guidance,

critique, and, at times, good humor, in creating

a successful data model.

5. Several case study data sets that can beused to demonstrate the efficacy of themarine data model. The data sets will becomposed of public domain, marine datathat may be freely used to support spe-cific applications. Current case studydatabases and descriptive informationare available on the companion web site.Helpful tools accompany some of thecase studies (e.g., tools to import various data sets into Arc Marine, tomanage and analyze time series data, tovisualize data).

The user community is now invited to fur-ther refine this model by preparing additio -nal applications of Arc Marine using their owndata sets in order to test its viability andusability. For instance, the reference book features use cases in seabed mapping andcharacterization, marine animal tracking, sediment transport and shoreline evolution,coastal planning, coral reef monitoring andhabitat analysis, water column chemistry,numerical modeling of physical oceano -graphic parameters, and more. But the prepa-ration of additional use case in these andother areas (e.g., ocean fisheries, marinepipelines, marine protected area design,species population viability, etc. are welcomeand may be coordinated into additional ESRIUC sessions or addenda to the reference book.

It is also useful to understand what rela-tionships may exist to related ArcGIS data

Latest News? Visit www.geoinformatics.com

Art ic le

41April/May 2008

Figure 7. A diagram representing a fragment of UML from Arc Marine, showing the connectivity between data collected on a Cruise to a track and multiple surveys whichmay be conducted with any number of vehicles or instruments within said cruise.