Conceptual Overview of ArcMarine:
The ArcGIS Marine Data Model
Dawn Wright, Oregon State University
Pat Halpin, Duke University
Michael Blongewicz, DHI
Joe Breman and Steve Grisé, ESRI
Juergen Schulz-Ohlberg, BSH
Federal Maritime & Hydrographic Agency of Germany
GIS Training for Marine Resource Managers, Monterey
June 15, 2005
dusk.geo.orst.edu/djl/arcgis 1
Session Topics
• General DM Design and Process
• Conceptual Overview of ArcMarine
– Break, questions/discussion
• Paulo’s ArcMarine Demo & Geodatabase
Exercise
• Final Questions/Discussion
2
Graphic by ESRI
Representing the Real World
GIS Data Model
Description and
Representation
Operational GIS
Analysis and
Presentation
People
Interpretation and
Explanation
Real World
3
4
Figure courtesy of Anne Lucas, U. of Bergen, Norway
Marine Data
Collection
Image courtesy of PISCO, OrSt
5
6
Image courtesy of the Neptune Project, www.neptune.washington.edu, University of Washington Center for Environmental Visualization
Image courtesy of the Neptune Project, www.neptune.washington.edu, University of Washington Center for Environmental Visualization
7
Image courtesy of MBARI,
www.mbari.org/mars
8
A Georelational to a Geodatabase Model
• coverage and shapefile data structures
– homogenous collections of points, lines, and
polygons with generic, 1- and 2-dimensional
"behavior"
• can’t distinguish behaviors
– Point for a marker buoy, same as point for OBS
• “smart features” in a geodatabase
– lighthouse must be on land, marine mammal siting
must be in ocean
9
“Object-Oriented” Data Modeling
• Objects in the real world
– Natural rules and relationships
•
•
•
•
Rivers flow downstream
Roads handle levels of traffic
MPA polys respect use regulations
How to build this intelligence into data
structures?
10
“Smarter” Data Structures
• Arc 7 coverage
– geometric information not stored in database
• Arc 8/Arc 9 geodatabase
– stores geometric information as "shape" attribute
• closer to how we actually think about
geographic features
• Identity, Inheritance, Encapsulation (Behavior)
11
Microsoft COM
( Component Object Model )
• Microsoft standard for re-usable software
components
– Build software from parts, not from scratch
– Makes software easier to write and reuse
– Provides widest choice in services, tools, languages, and
applications
– Controls, tools, and server components
– Geographic objects and software objects
• e.g., Word and Excel
12
ArcGIS and Microsoft COM
• 2,000+ reusable software objects
• Programmable in Visual Basic for Applications
(VBA) and Python
• Visual language for representing a data model
– Data modeling with Unified Modeling Language
(UML)
13
ArcGIS “Custom” Data Models
support.esri.com/datamodels
14
ArcGIS “Custom” Data Models
• Basemap
• Administrative
Boundaries
• Utilities
• Parcels
• Transportation
• Imagery
etc ...
• Conservation/Biodiv
• Hydro
• Groundwater Hydro
• Forestry
• Geology
• Petroleum
• Marine
• IHO-S57
• Atmospheric
etc ...
15
Purpose of ArcMarine
• basic template for implementing marine GIS
projects
– input, formatting, geoprocessing, creating maps,
performing analyses
– simplify project implementation
• basic framework for writing program code and
maintaining applications
– development of tools for the community
• promote networking and data sharing through
established standards
16
Why? (cont.)
• Learning, understanding the Geodatabase!
• 2-way educational process: users & ESRI
• Bear DM in mind when collecting data
• The geodatabase
– Not going away
– Coverages, shapefiles not around forever
17
Implementation Process
Draft
Conceptual Design
Draft
Logical Design
Prototype
Design Engineering
Updated
Conceptual Design
Updated
Logical Design
Pilot Project
Database Engineering
Updated
Conceptual Design
•
•
•
•
Updated
Logical Design
Production
Data model template – few weeks to months
Mature data model – up to few years
Deployment/Rollout
Since Oct 2001, 3 workshops, 3 ESRI UC sessions
More info at dusk.geo.orst.edu/djl/arcgis/about.html
18
Graphic by ESRI
Modeling Process
Real World
Objects and Relationships
Physical Model
Database Schema
Database/Project Rules
Conceptual Model
Sketches, Flow Diagrams, etc
Logical Model
Diagram in CASE Tool
ArcCatalog Tools
19
Image modified from original
by P. Halpin, Duke
Design Strategy
20
Steps in Data Modeling
(1) Model the user's view of data
– what are the basic features needed to solve the
problem?
Bathymetry
Marine mammal movement
Sidescan sonar/Backscatter
Atmospheric influences
Shoreline
Sea state
Marine boundaries (e.g., MPAs)
Wave activity
Geophysical time series
Sea surface temperature
Sub-bottom profiling
Salinity
Magnetics
Sensor calibration data
Gravity
Current meters
Seismics
Density
Sediment transport
etc. ...
etc. ...
Image by Joe Breman, ESRI
21
Wright et al., 1995
NOAA PMEL
22
Steve Grisé, ESRI
Users’s View
of Data
23
Pat Halpin, Duke
(2) Select the
geographic
representation
(points, lines,
areas, rasters,
TINs, etc.)
24
25
ArcMarine Thematic Layers
26
ArcMarine Thematic Layers
27
Steps in Data Modeling (cont.)
(3) Define objects and relationships
– draw a UML diagram
(4) Match to geodatabase elements
– specify relationships, “behaviors”
(5) Organize geodatabase structure
28
29
InstantaneousPoint (ex: CTD)
Michael Blongewicz
X
InstantaneousPoints
MarineID
1
2
3
MarineCode
AAA
BBB
CCC
SeriesID
1
1
1
IPointType
1
1
1
RecordedTime
05/04/58 12:00 00
05/04/58 12:30 00
05/04/58 13:00 00
TimeStamp
Y
Measurement
MeasureID
1
2
3
4
5
MarineID
1
1
1
2
2
ZLoc
-0.8
-1.5
-3.5
-0.8
-1.5
Xloc
Yloc
ServiceTrip
SeviceDesc
Measurement
MeasuringDevice
MeasuringDevice
MDeviceID
1
2
3
4
5
Name
Bob
Poncho
Juanita
Mia
Anita
MeasuredType
MTypeID
VarName
1
2
3
4
5
Type
VarDesc
MeasurementID
1
1
1
2
2
VarUnits
Oranges
Bananas
Cubic cm
Rocks
Limes
Z
MDeviceID
1
1
2
2
3
MeasuredData
MDeviceID
1
1
1
1
1
East
12.1
11.3
9.3
14.0
7.3
North
10.8
12.5
-3.5
15.1
12.0
Speed
8.6
7.9
7.5
3.9
9.1
Direction
121
220
130
234
115
30
31
Graphic by ESRI
and finally
ProjectOrganize
Design Methodology
Create
Design
Template
Design
USE that Gdb!
Manage Using
ArcCatalog
Data
Dictionary
Report
Geodatabase Extract Tool
Geometry
Project
Analysis and
Design
Curve
Polycurve
Path
1..*
Complex edge feature class
Polyline
Ring
Road
Polygon
1..*
Field name
UML
Representation
XMI/
Repository
Template Model with
Schema Wizard
Data type
OBJECTID_1
OID
Shape
Yes
Single
Yes
Integer
Yes
ROAD_WORK_ID
Integer
Yes
OBJECTID
Integer
Yes
ENABLED
Integer
Yes
ROADNUMBER
Integer
Yes
ROADNAME
String
Yes
SOURCEYEAR
Integer
Yes
SOURCE
String
Yes
ACCESSSTATUS
String
Yes
PLANNEDCLASS
String
Yes
RECORDEDLE
String
Yes
SURFACE
String
Yes
Horizontal
Reference Datum
Source Map Scale
Number
Data Collection
Date
Coordinate Data
Source
Location
Comments Text
Vertical Measure
Vertical Collection
Method
Vertical Accuracy
Measure
Vertical Reference
Datum
Verification
Method
0
0
254
0
254
20
20
30
20
Yes
Single
Yes
120
0
0
0
Shape_Length
Double
Yes
0
0
Subtypes of Road
Geodatabase
Element Definition
The system identifier used by the
geodatabase to uniquely identify
the Reference Point.
The decimal representation of the
latitude of the Reference Point.
The decimal representation of the
longitude of the Reference Point.
The accuracy value as a range (+/-)
of the latitude and/or longitude.
The code and associated name
that represents the geometric
entity represented by the
Reference Point.
The code and associated method
that represents the method used to
determine the latitude and
longitude coordinates for the
Reference Point on earth.
The code and associated name
that represents the reference
datum used in determining latitude
and longitude coordinates.
The number that represents the
proportional distance on the
ground for one unit of measure on
the map or photo.
The calendar date (dd-mm-yyyy)
when data were collected.
The code and associated name
that represents the party
responsible for providing the
latitude and longitude coordinates.
The text that provides additional
information about the Reference
Point.
The measure of elevation (i.e. the
altitude), in meters, above or below
a reference datum.
The code and associated text that
describes the method used to
collect the vertical measure of a
Reference Point.
The measure of the accuracy used
to collect the vertical measure (i.e.
the altitude) of a Reference Point.
The code and associated name
that represents the reference
datum to determine the vertical
measure.
The code and associated text that
describes the process used to
verify the latitude and longitude
Horizontal
Collection Method
0
0
120
SUBTYPE
120
List of defined default values and domains for subtypes in this class
Subtype
Description
Field name
Default value
Domain
Primary
ENABLED
1
EnabledDomain
130
Secondary
ENABLED
1
EnabledDomain
160
Abandoned
ENABLED
1
EnabledDomain
170
Obliterated
ENABLED
1
EnabledDomain
Data Elements—Reference Point Feature Class
Data Element
Reference Point ID
Longitude
Measure
Horizontal
Accuracy Measure
Geometric Type
0
0
EnabledDomain
Integer
Subtype field
Table 4:
0
1
SUBTYPE
Default subtype
Latitude Measure
Precision Scale Length
Domain
SHAPE_LENG
Subtype
Code
I.
Allow Default
nulls value
Geometry
LENGTH
ROAD_WORK_
Element
Type
Example
Unique ID
Numeric
Numeric
49.1234, 50.10
112.23456, 135.98
Alphanumeric
+/- 10, +/- 25
Reference
Table (Domain)
001 = point
Reference
Table (Domain)
001 = Address
Matching, 012 =
GPS data
collection
Reference
Table (Domain)
001 = North
American Datum
1927
Reference
Table (Domain)
1:10,000, 1:100,000
Date
17/04/1999
Reference
Table (Domain)
001 = Alabama, 082
= EPA
Headquarters
Alphanumeric
Reference
Table (Domain)
+/- 5, +/- 10
Reference
Table (Domain)
001 = GPS, 010 =
Benchmark
Alphanumeric
Reference
Table (Domain)
001 = North
America Vertical
Datum of 1988
Reference
Table (Domain)
007 = verified to
map features, 010
= unknown
Reuse Existing Designs and/or
Create Tables/Feature Classes
Refine
Design
Load Data
I.
Table 4:
Data Elements—Reference Point Feature Class
Data Element
Element Definition
Reference Point ID
The system identifier used by the
geodatabase to uniquely identify
the Reference Point.
The decimal representation of the
latitude of the Reference Point.
The decimal representation of the
longitude of the Reference Point.
The accuracy value as a range (+/-)
of the latitude and/or longitude.
The code and associated name
that represents the geometric
entity represented by the
Reference Point.
The code and associated method
that represents the method used to
determine the latitude and
longitude coordinates for the
Reference Point on earth.
The code and associated name
that represents the reference
datum used in determining latitude
and longitude coordinates.
The number that represents the
proportional distance on the
ground for one unit of measure on
the map or photo.
The calendar date (dd-mm-yyyy)
when data were collected.
The code and associated name
that represents the party
responsible for providing the
latitude and longitude coordinates.
The text that provides additional
information about the Reference
Point.
The measure of elevation (i.e. the
altitude), in meters, above or below
a reference datum.
The code and associated text that
describes the method used to
collect the vertical measure of a
Reference Point.
The measure of the accuracy used
to collect the vertical measure (i.e.
the altitude) of a Reference Point.
The code and associated name
that represents the reference
datum to determine the vertical
measure.
The code and associated text that
describes the process used to
verify the latitude and longitude
Latitude Measure
Longitude
Measure
Horizontal
Accuracy Measure
Geometric Type
Horizontal
Collection Method
Horizontal
Reference Datum
Source Map Scale
Number
Data Collection
Date
Coordinate Data
Source
Location
Comments Text
Vertical Measure
Vertical Collection
Method
Vertical Accuracy
Measure
Vertical Reference
Datum
Verification
Method
Element
Type
Example
Unique ID
Numeric
Numeric
49.1234, 50.10
112.23456, 135.98
Alphanumeric
+/- 10, +/- 25
Reference
Table (Domain)
001 = point
Reference
Table (Domain)
001 = Address
Matching, 012 =
GPS data
collection
Reference
Table (Domain)
001 = North
American Datum
1927
Reference
Table (Domain)
1:10,000, 1:100,000
Date
17/04/1999
Reference
Table (Domain)
001 = Alabama, 082
= EPA
Headquarters
Alphanumeric
Reference
Table (Domain)
+/- 5, +/- 10
Reference
Table (Domain)
001 = GPS, 010 =
Benchmark
Alphanumeric
Reference
Table (Domain)
001 = North
America Vertical
Datum of 1988
Reference
Table (Domain)
007 = verified to
map features, 010
= unknown
Import and export
XML Schema 9.0
32
Implications (1)
Inputting & Formatting Data
 Starting point, a gdb template
 Provides common data structures
 Allows control of required data fields from
collection through analysis phases
Pat Halpin, Duke
33
DHI TimeSeries Manager
Arc Atmosphere
Arc Hydro
MIKE 21
MIKE GIS
Data Access Bridges
MIKE 11
TimeSeries Manager
ArcGIS
Arc Marine
Geodatabase
dfs0
MIKE Basin
34
Implications (2)
Data models linked to geoprocessing models
• One package for data and process workflow…
New tools provide rapid prototyping for a project
35
Pat Halpin, Duke
Implications (3)
Data Sharing
 Within / Between Projects
 Internet Map Services (Geography Network, NSDI, OBIS…)
 Internet Map Services: data conflation tools
Data Type:
Tools/Protocols:
vector data
XML
raster data
DODS
metadata
Z39.50
FGDC
Distributed Generic
Distributed Oceanographic
Information Retrieval Data System
map
WMS
Web Mapping
Services
36
ArcMarine is Ongoing
• Case studies , tool development
– Interested participants via web site
~300 people, 32 countries
• Approaching final UML - feature classes, attributes,
rules/behaviors
• 2005 ESRI UC technical workshop
– 2006 ESRI Press book
• Agency “buy-in”
• Publicizing and publishing
• Tie-in w/ other model efforts
37
More information
dusk.geo.orst.edu/djl/arcgis
inc. downloads, tutorial
support.esri.com/datamodels
38