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.
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.
________________________________ From: address@hidden [mailto:address@hidden On Behalf Of Rudolf Husar Sent: Thursday, 4 January 2007 3:44 AM To: address@hidden 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.
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 <address@hidden> 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 <address@hidden> > > Thanks. > -- Ben > > ---------- Forwarded message ---------- > From: David Tarboton <address@hidden> > Date: Dec 17, 2006 10:50 AM > Subject: CUAHSI Observations Data Model > To: Ben Domenico < address@hidden> > Cc: david Maidment <address@hidden>, address@hidden > > > 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: address@hidden 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 ===============================================================================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.