CUAHSI Observations Data Model

Wed Jan 3 19:56:56 MST 2007

Hi all,

One important point I should clarify.  In my original message, I
referred to "classic examples of stovepipe foundations" for data
systems.  I hope it is clear that I did not intend any perjorative
connotation for the "stovepipe" in this context.  Quite the contrary,
I think it's important to have tailored data systems that effectively
and efficiently serve their primary user community.  The key then is
to develop standards-based interoperability connections among the
community data systems so they can be made useful to other
communities..  To do that, we need to understand the stovepiple
systems we are connecting.  That was my motivation.

-- Ben

On 1/3/07, Simon.Cox at csiro.au <Simon.Cox at csiro.au> wrote:
>
>
> Probably the key difference between the OGC SWE and conventional earth
> observations approaches is that SWE is based on the Observations and
> Measurements (O&M) model, which ties observed values to a _feature_ rather
> than a location.
>
> The reasoning behind this follows more or less directly from the General
> Feature Model (GFM) as described in the OGC Abstract Model, and also in ISO
> 19101 and ISO 19109.
> In the GFM the "feature" is the central (meta-)concept, carrying all
> characteristics of the domain of discourse.
> In contrast, geometric objects (points, lines, polygons, etc) are
> abstractions that may describe some aspects of a feature (e.g. location,
> shape) but are *not* features in their own right.
> ISO 19107 (the "Spatial Schema") makes it clear that a geometry may only
> carry spatial of geometric properties.
>
> As an example in plain language, a *point* does not have a
> temperature/pressure/chemistry, etc, the *material at a point* does!
>
> In the O&M model this all is explicit, through the so-called "feature of
> interest" which is the feature instance whose properties are under
> observation.
> Note, however, that it is often important to distinguish between the
> "proximate" feature of interest (pixel/scene, station, sounding, well,
> transect etc) and the "ultimate" or "project" feature of interest (ground
> cover, water body, aquifer, rock unit, atmosphere, etc).
> The former usually embody the sampling strategy, while the latter embody
> domain semantics.
>
> In conventional earth-observation science, the existence of a sampling
> feature is often elided: its position used as a proxy.
> This is also followed through in the ISO "Coverages" model, which assigns
> properties by location.
> There is an implicit "feature" encompassing the entire coverage domain, with
> the coverage range describing the distribution of the property value within
> the bounds of this feature.
> This implicit feature, if described at all, is in the coverage "metadata"
> somewhere.
> This is all fine in practice, and because O&M describes a *conceptual* model
> there are many potentially conformant serializations or implementations.
> The OGC SWE suite of standards are relatively explicit about it.
> But IMHO the key point is to recognise that there *is* a feature of
> interest, not just points, lines and polygons.
>
> Simon
>
>
>
>
>  ________________________________
>  From: owner-galeon at unidata.ucar.edu [mailto:owner-galeon at unidata.ucar.edu]
> On Behalf Of Rudolf Husar
> Sent: Thursday, 4 January 2007 3:44 AM
> To: Ben at unidata.ucar.edu
> Cc: THREDDS community; Unidata GALEON; David Tarboton; Unidata Techies; Olga
> Wilhelmi; Jennifer Boehnert
> Subject: Re: CUAHSI Observations Data Model
>
>
>
> oops .. sorry
>
> Hi Ben, David, All,
>
> Thank you for bringing the hydrology data modeling effort to our attention.
> I can offer a few thoughts on this data model harmonization issue.
>
> - In dealing with air quality point monitoring data, both practice and
> theory has shown that the relational data model proposed by CUAHSI is a
> robust way of encoding monitoring data. In fact virtually all AQ monitoring
> data are being managed through Relational DMS, in SQL servers. A typical
> (actual) AQ data schema is in slide 2.
>
> - The relational model is suitable to encode and to respond to typical OGC
> queries for data (WCS), station description (WFS), sensor description (SOS)
> etc. Some ideas on this are noted in slide 3.
>
> - For web service-based data access, it should not matter how the data are
> encoded and managed, as long as they respond to the service query.
>
> - In this view, a key in harmonizing between the two (or five) data models
> is in the service return payload format. netCDF?, XLS, CSV, whatever is
> appropriate for the particular client (community).
>
> -  So, connecting the pipes is a matter of using different data format
> adopters. For the GALEON experiments, for example, we have formatted the
> monitoring data as a 1 dim netCDF-CF data structure.
>
> We are very much looking forward comparing notes on this topic and also
> experimenting with implementation in GALEON 2.
>
>
> Thanks, Rudy
>
> Rudolf B. Husar, Professor and Director
> Center for Air Pollution Impact and Trend Analysis (CAPITA),
> Washington University,
> 1 Brookings Drive, Box 1124
> St. Louis, MO 63130
> 314 935 6099
>
> On 1/3/07, Ben Domenico <bendomenico at gmail.com> wrote:
> >
> > Hi all,
> >
> > The US hydrology community represented by CUAHSI  (Consortium of
> > Universities for the Advancement of Hydrologic Sciences, Inc.) HIS
> > (Hydrologic Information System) has drafted a document called "CUAHSI
> > Community Observations Data Model Working Design Specifications."
> > These design specifications are targetted at a relational database for
> > hydrologic point datasets that are collected at distributed hydrologic
> > observatories.  David Tarboton welcomes input from the THREDDS and OGC
> > communities, so I'm forwarding his message which has pointers to the
> > draft specifications and a questionnaire.
> >
> > I am struck by the fact that the THREDDS group is developing storage
> > and access systems for the same sort of point/station observations via
> > our traditional netCDF approach
> >
> >
> http://www.unidata.ucar.edu/software/netcdf-java/formats/UnidataObsConvention.html
> >
> > and the OGC Sensor Web Enablement (SWE) initiative addresses many of
> > the same data access issues from the perspective of standards-based
> > interfaces.
> >
> > http://www.opengeospatial.org/pt/06-046r2
> >
> > So we have two discipline-oriented communities of practice developing
> > very different approaches to data storage and access issues for
> > datasets that have many common characteristics and a group working
> > with evolving international standards in the same general area.  If
> > you look at the diagram in "The Middle Ground" section of
> >
> >
> http://www.unidata.ucar.edu/projects/THREDDS/GALEON/Phase2Connections/FeaturesFilesScientificDataModels.htm
> >
> > these projects are classic examples of the stovepipe foundations and
> > -- hopefully -- the conduit pipe between them.
> >
> >
> > I thought each group should at least be aware of the work of the others.
> >
> > In addition, if any of you have input for David Tarboton, he welcomes
> > it before January 31st and has specific requests for feedback in the
> > questionnaire that he points to.
> >
> > David Tarboton <dtarb at cc.usu.edu>
> >
> > Thanks.
> > -- Ben
> >
> > ---------- Forwarded message ----------
> > From: David Tarboton <dtarb at cc.usu.edu>
> > Date: Dec 17, 2006 10:50 AM
> > Subject: CUAHSI Observations Data Model
> > To: Ben Domenico < bendomenico at gmail.com>
> > Cc: david Maidment <maidment at mail.utexas.edu>, rhooper at cuahsi.org
> >
> >
> > Ben,
> >
> > The document, "CUAHSI Community Observations Data Model Working
> > Design Specifications",
> > (http://www.cuahsi.org/his/docs/ODM4-20061026.pdf )
> presents the
> > current design for the integrated hydrologic observations database
> > that is proposed for the CUAHSI Hydrologic Information System
> > (HIS).  We are soliciting comments on this design to ensure that we
> > have a data model for observations that is simple, usable, and meets
> > the needs of hydrologic observatories and the CUAHSI
> > community.  There is much in common between what CUAHSI is doing in
> > Hydrology and what UNIDATA is doing in atmospheric science.  I am
> > sending this to you so that you may be aware of this work and provide
> > comments and suggestions on this design?  I have prepared a
> > questionnaire to guide your review
> > (
> http://www.cuahsi.org/his/docs/ODMOpenCommentQuestions.pdf),
> > although you should not feel constrained by this and should feel free
> > to provide feedback in whatever form you think is most
> > appropriate.  We would like to receive comments by January 31,
> > 2007.  We appreciate you taking the time to help with this.
> >
> > Thank you,
> >
> > David
> >
> >
> >
> -----------------------------------------------------------------
> > David Tarboton
> > Professor, Civil and Environmental Engineering
> > Utah Water Research Laboratory
> > Utah State University, Logan UT 84322-4110
> > Ph: (435) 797 3172        Fax: (435) 797 1185
> > Email:  dtarb at cc.usu.edu
> http://www.engineering.usu.edu/dtarb
> > Learn about the USU Water Initiative:  http://water.usu.edu/
> >
> -----------------------------------------------------------------
> >
> >
> ==============================================================================
> > To unsubscribe galeon, visit:
> > http://www.unidata.ucar.edu/mailing-list-delete-form.html
> >
> ==============================================================================
> >
> >
>
>
>
>

==============================================================================
To unsubscribe thredds, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================