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@xxxxxxxx <Simon.Cox@xxxxxxxx> 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@xxxxxxxxxxxxxxxx [mailto:owner-galeon@xxxxxxxxxxxxxxxx]
On Behalf Of Rudolf Husar
Sent: Thursday, 4 January 2007 3:44 AM
To: Ben@xxxxxxxxxxxxxxxx
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@xxxxxxxxx> 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@xxxxxxxxxx>
>
> Thanks.
> -- Ben
>
> ---------- Forwarded message ----------
> From: David Tarboton <dtarb@xxxxxxxxxx>
> Date: Dec 17, 2006 10:50 AM
> Subject: CUAHSI Observations Data Model
> To: Ben Domenico < bendomenico@xxxxxxxxx>
> Cc: david Maidment <maidment@xxxxxxxxxxxxxxx>, rhooper@xxxxxxxxxx
>
>
> 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@xxxxxxxxxx
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
==============================================================================
