Marine Data Modeling Working Group Meeting

October 4 & 5, 2001

ESRI, Redlands

Draft Agenda

Attending:

Joe Breman, ESRI

Simon Evans, ESRI

Steve Grise, ESRI

Pat Halpin, Duke

Jason Marshall, NOAA CSC

Eric Treml, Duke

Dawn Wright, OrSt

October 4

9:00 am ≠ 5 pm

(Person listed will facilitate discussion and do presentation if required)

(Lunch will be brought-in and breaks will be agreed upon as needed)

Welcome and Introductions ≠ Steve GrisÈ

ArcGIS Data Models ≠ Steve GrisÈ

∑ Background and overview

∑ Goals for meeting

Demonstration of a data model in action ≠ Steve GrisÈ

FGDC Ocean/Coastal Data Framework ≠ Jason Marshall

Thoughts on an Marine Data Model Template and User Domains ≠ Dawn Wright

Lunch

Thematic Groups ≠ Steve GrisÈ

∑ Definition

∑ Division of sub-working groups

∑ First consultation of sub-working groups

Recap of sub-working groups.

October 5

9:00 am ≠ 4:30 pm

4:30 pm - Tour of ESRI if wanted

(We will break for lunch)

Brief recap of yesterdayπs status

Sub ≠working groups continue

Review of åFirst Draft≤ of Marine Data Model

Follow-up tasks and action items with milestone agreements

Agree upon follow-up meetings/email discussion forum, etc.

Agree upon methods of sharing/vetting of Data Model with Ocean User Group.

Notes:

Pre- Meeting - Developing a Conceptual Model for ArcGIS Template

From: Steve Grise <sgrise@esri.com>

To: Jeanne Rebstock <jrebstock@esri.com>,

"'dawn@ncgia.ucsb.edu'"

<dawn@ncgia.ucsb.edu>

Cc: "'Cindy Fowler'" <Cindy.Fowler@noaa.gov>, "'phalpin'" <phalpin@duke.edu>,

Joe Breman <jbreman@esri.com>,

"'Anne Miglarese'" <Anne.Miglarese@noaa.gov>,

"'Tony Lavoi'" <tony.lavoi@noaa.gov>,

"'Dave Stein'" <Dave.Stein@noaa.gov>, Simon Evans <sevans@esri.com>

Subject: RE: Meeting in Redlands - dates and goals

Date: Mon, 13 Aug 2001 09:56:41 -0700

_____________________

The main goal of the meeting will be to provide a high-level concept for the

data model: is it one data model with major groups for coastal, bathymetry,

SIM, S-57, etc. or is it a series of related designs? How should we fit

these pieces together into a common, essential data model? And what should

the name be?

I think I should begin with introductions and an overview of the ArcGIS Data

Model program, outline what our goals should be, talk a bit about the

technical details, provide some ideas about how we can work together as a

design team, talk about what has to be developed, and discuss typical

schedules. This is probably about 2 hours.

Then I think it would be helpful for someone to talk for 30-60 minutes to

describe each of the candidate models, talk about the content, status, key

design issues, how this model might fit as a part of a broad ArcGIS Data

Model project.

At this point we can begin to shape the overall content and scope of the

model. It is important that we do this because it will guide the detailed

design effort. It is surprising how many of the details can change over time

but it is rare that the overall scope of the model will change. If we can

take a first cut at this at the end of the first day we will have made

significant progress.

On the second day we could review the discussion from day 1, see if there

are any new ideas for the conceptual model, and then move into a bit more

detail. Depending on the size of the group it usually works best if we take

the main thematic groups of the model and have some breakout sessions for

3-5 people to come up with an initial list of features/classes for each area

of the model. The groups can present the content to each other after 1-2

hours of this exercise. I am a bit vague on the time required because it's

hard to guess how many people and how many feature classes will be required.

We can work this out at the meeting and at least get a start on the exercise

so people understand what is required. You don't need to study uml or

anything before the meeting. I can take all of this material after the

meeting and assemble a first cut at the conceptual model.

At this point we would be ready to wrap things up with a discussion of the

practical steps involved in developing the model. We could also talk about

the spring meeting, UC goals, and roles and responsibilities.

Steve

Dawn Wright's Notes

ESRI Marine Data Model Team Meeting

Oct. 4-5 , 2001, Redlands, CA

Help w/standards - support some orderly development of procedures for how to do things

contour lines - attributes go with the line or z value?

- build a model that works well with ArcGIS (cross-platform, other software sure but wanted to do something that works well w/ArcGIS)

- so you really need to use the software to make progress, it's through using the software and working w/the data that breakthroughs and new ways of doing things come

ArcGIS data models

-facilitate a PROCESS with the user community - review feedback (2 months of real work and 2 years of explaining it to people to get it implemented)

- a lot depends of what's actually happening in the user community

- producers and users of geographic info. haven't talked to each other, in totally different organizations, etc. - ESRI has found that this has helped producers and consumers do new things, prod think more about PUBLISHING their data w/this structure with input from the users

- 3rd leg is business partners, people who want to build applications, value added data sets

- build a dB design template that works well with ArcGIS

- share model on ArcOnline - ESRI doesn't want to commercially profit from the work of user communities

- - build on existing standards, not a new standards exercise

Facilitate user community feedback process

How to manage User expectations

Confirm this is not a finished product and wont address all needs at this stage

Kernel of potential

Bussiness Partner and User review

User Feedback integration

- believers in standards but they have to come from the user community, not them - just a practical template to help folks implement the standards

data model levels

reality --> conceptual model --> logical model --> physical model -->

increases in abstraction, goes from human-oriented to computer-oriented

trying to model whole is daunting

birds can fly and planes can fly so they must have a common ancestor, but birds have 2 legs and humans have 2 legs, so...

hardest part is developing big boxes, sets of thematic groups - putting content in boxes is fairly easy

analysis diagram is conceptual model, UML is logical model (can use same logical model to produce schema in SQLserver, Oracle, etc.)

Pilot and do work at any early stage to test at different stages of modeling process - try w/real data

- there is no absolute answer other than does it work with your data on your hardware platform

- numbers of feature classes is key- like FGDC model, tons of feature classes with similar attributes, so it's a good idea to reduce those b/c each feature class is a separate table - performance issue with software and usability side too - don't want to have to open a menu and try to choose from a list of 100

data may be same regardless of how you are using it, for basic science, for conservation, for education, for applied commercial uses, etc. - so an essential data model is applicable to all - design a new minivan but don't know families will really use the van

- when it gets implemented that's when we find out and can refine

contents of data model

- book, which is a ref. for the data model w/ sample data sets

- data model reference will probably be on the web as a pdf

- Modeling Our World volume 2 by Zeiller may be the way to publish future data model efforts

- interest from ESRI Press in an ocean data model book like the hydro book

Model Definition

- focus required in each model - are we doing coasts or oceans or both (hydro does surface water but NOT groundwater for instance)

- build on people's experience and understand relationships to different data and related modeling efforts such as hydro (or parcel model for coastal land development) - don't try to have the model do absolutely everything

- make it simple -- a starting point for project teams

Doing a Model with ArcGIS

- different from Arc 7.2 and AV 3

- ArcGIS is built up from separate components, and rules can be built into the database (e.g., "these things can never go on top of these things")

- we're just raising the bar a bit - object, feature, network feature, they can look at real world entities first and not have to worry about system components

- data model first, don't worry about behavior - we don't attempt to model complex behavior

------

Pat's Question

how to deal w/scale dependency in an ocean model? - deal w/them separately and get specific and then try to group together at higher levels - coastline for Chesapeake Bay vs. entire N. America

Simon - we're also limited in our 3-D ability to model fluidity of ocean data

how to organize GIS data so that you turn things on and off at certain space and time scale

time on y axis, space on x axis

- have to be careful not to overload UML with infinite modes of representation - UML is good for documenting design w/purpose towards final design - it' a notation for design, a blueprint, drawers in a chest - have to think about final map products and how you are going to do the analysis

People come w/diff expectations for a data model - have to be clear what the focus is, realizing that not all groups will be represented - but the trick is to find linkages between expectations

**common structure to publish data which helps others to produce data in that similar approach

Eric - diff w/ocean data models - others are regulated by industry or legal framework, natural environment is not straightforward

- first order is to produce template that can be used with software, 2nd order is to spur development teams to extend the software

**we have to be specific about what the model does and does not address

ArcApp discussion - core capabilities that people need in an area - ArcParcel? ArcOcean? - doesn't make sense to build 24 different extensions - but take right parts and build it into core software for everyone - dynamic segmentation is classic example (it's a transportation functionality but it's there for everyone)

Joe - also use data model to teach community about advanced capabilities that already exist that they may not know about

ESRI oOcean folks really don't have their own division - they are spread among environmental mgmt., defense. Ocean is not it's own huge division

what the need is, what we're doing today, what will need to be done tomorrow - we need to outline objectives and assumptions outright (as with Forestry data model)

Steps:

1 - thematic groups - boxes

2 - feature classes - things in the boxes

3 - preliminary, simple analysis diagrams

Demo by Steve w/S57 data, obj oriented data format for ENC, the "fuel" for ECDIS

relationship between pt. feature and annotation, for ex., so annotation moves w/feature

shared edit tool - vertices, nodes edited and moved at same time

what relationships need to be modeled in DB - most relations are spatial so don't need - thinking about actually using the inherent spatial rela. and relying on that - explicit relationships may not add much (like building a road between 2 places where there is no traffic)

personal geodatabase - like bunch of shapefiles in one dB along with annotations, feature relationships

national elevation dataset (60 Gb) - image easily incorporated into ArcMap - Geography Network lets you have it as a client

real world (measurement, sensor and survey) v

basic (map) data (base data)

data model/format

data product

analysis

product/research

mgmt/understanding

- all cycles back to and ripples through each stage

- we care about interpretation of data more than anything else

- is it the basic modeling of how we do measurements or results that we do with measurements.

Pat - add fields to dB to signify 3- and 4-D even though we are still in 2.5-D (e.g., heat sum for coral bleaching) (ArcInfo network for larval dispersal over artificial reefs - needed hydrodynamic model results from Matlab analysis to feed into AI network -the impedance)

* initially users might wonder how do we assemble data using the data model and then they might realize, well, we should manage our data this way, and publish it this way

don't leave out the FISHERIES community and MILITARY

- marine mammal community, oil, defense, submarine cable hard to bring in

- we can tie into a new historic preservation model, conservation (terrestrial and marine)

opportunity to get people to provide feedback

--------

Why do the ArcGIS data model for boundaries, shoreline, bathy?

- so we can evaluate how good is current content

-extend concept of shoreline - agreement on

- geodatabase templates to empower people to look at those guidelines and help them to build their databases

- organize and structure in a uniform format to get at it

* framework for putting in behaviors to take GIS analyses one step further

Pat - one main overarching model and then app specific sub-modules?

-------

"marine_datatype.gif" shows structure of marine data types from a scientific information measurement standpoint

(Joe: for the first line under interpolated Surfaces in place of ≥gridding of≤

≥Kriging of≤äor perhaps both?)

second part of this is "fixed reference" from pp. 1-37 of FGDC Shoreline Standard (w/ ties to S-57)

will model have an NSDI focus? GSDI focus? Etc. - need to get a group together of lead representatives from these group to talk about how different semantic pieces fit together

Jason's general point: how will the data models interchange? Steve: technically via ArcGIS but semantic links will be problematic. Need tie-ins, cross-communication

Example, biodiversity with physical oceanography, the conservation model with the marine model

Pat: Coastal Zone Management is an application that serves as a perfect example of how multiple data models might be needed. CZM involves utilities, parcels, transportation, ocean. And what about scalability of models?

NOTES FROM WHITEBOARD:

Thematic Groups that we came up with:

From Jason's presentation ...

- Atmospheric conditions

- Marine boundaries*

- Hydrographic features

- Water chemistry

- Marine biology

- Shoreline*

- Topo-Bathy*

- Geology

- Hydro-physics (currents and circulation)

- Water column data

From Dawn's presentation ...

- Marine Boundaries

- Bathymetry

- Other Underway Geophysical - time, position, sidescan, magnetics, gravity, seismics

- Derived grids

- Standard supporting data - sea state, XBT, CTD, sea surface temperature and salinity, and derived sound velocity profile (SVP), as well as calibration data for each sensor

- Images

- Locations of observations - Submersible, ROV, Tracklines/Nav points

From California Marine Mapping User Group Meeting - data types needed for pilot research on California marine protected areas

(list must be for answering a specific scientific question or hypothesis - and that will inform the resolution of data needed)

- bathymetry

- marine plants

- substrate types

- substrate relief

- coastline

- species distribution abundance

- phys oceanography (water temp)

- terrestrial land-use and watersheds

- agency jurisdictions & regulations

- marine human use

- biogeographic regions (diff. from species distrib)

- water quality and turbidity

- land topography

- toxicology

- source input (e.g., sewage outfalls)

- catch data

- derivative habitat layer

- historic data

- existing study sites

- socioeconomic

From Pat and Eric ...

Conservation

- fisheris

- fed/state DNR

-- MarineBio/Observatioins (species, biodiversity unit)

-- Managed areas (natural or human/legal)

- distribution

- biomass

- historic distribution

"analy.gif" - Steve's whiteboard draft of analysis diagrams

For module 2

Source_Date

Record_Date

Start_Date

End_Date

This may be redundant, but I am pretty certain this is how it went down in the model

Other ArcGIS capabilities to exploit:

- extrusion of points in ArcScene

- horiz/vert slices of grids - stacks of grids

- ability to lay grids on their side and pretend that's the xy view? (x,z - swapping z's for y's)

TEST DATA TYPES for draft of model

- Physical oceanography (currents) - Joe? Dawn?

- Ocean basemap / nav chart (S57) - Jason or Simon

- Ocean floor (bathymetry - Dawn can also add deep-towed vehicle observations (points)

- Marine mammal - Pat/Eric

- MPA (managed areas) - Pat/Eric

--------

Draft 1

- analysis diagram

- UML

- map doc

- sample dB

- conceptual framework doc

-- broad fields of study, how user community fits together and here is what we are focused on (20-30 pp. max) - circles back analysis diagram and UML

b/c true 3-D ~~does not exist~~ tools not yet developed

2.5 D vs. 4-D - we are trying to incorporate a place for the data while we are in expectation of tools to come

- - just us trying to speak for the community

Clear acknowledgement of our partial user group representation in the creation of this model

could segway to call for feedback and review

Pat's marine/coastal GIS seminar this spring can help to test data

1st week Nov. for conceptual framework document

- Group meeting, date location, etc.

- Draft2

- mini projects

- UC presentation

**give them dates to consider in February and April, for a workshop in Redlands???

use Forestry as a model

- Pat will take lead on looking at crossovers on conservation side w/conservation/biodiversity

object doesn't have an xy, feature does

(Joe: Great Notes Dawn!)