NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Roy, Thanks for the thought provoking reply. Just one quick point of clarification -- from my point of view. I didn't mean to imply that we should try to harmonize all the various protocols and specifications. What I was trying to get across is that we should lay it all out on the table and assess what each has to offer for dealing with the sort of data collections our community has to offer. It may end up that we need some of each, but my own tendency is to clarify our own CF-netCDF world for the CDM data types see where the result of that exercise fits into the OGC world. At the moment -- for me anyway -- the OGC documents that have the clearest conceptual description of what we deal with is the Observations and Measurements of the Sensor Web Enablement suite. The word feature is overused there for sure, but at least there is a distinction drawn between the "feature of interest" and "sampling features." And there is a special place for most of our collections as that very special class of feature called a "coverage." The ideas in the two O & M documents really help me make sense of the feature/coverage issues. And the focus is very much on the user view of the "patient" rather than on the monitoring devices. But I digress from the main point that we don't necessarily have to harmonize all the protocols for our datasets. Maybe we just pick one and make sure it evolves to fit our needs. -- Ben On Tue, Sep 16, 2008 at 8:23 PM, Roy Mendelssohn <Roy.Mendelssohn@xxxxxxxx>wrote:
Hi Ben: I haven't had a chance to stir up a pot for awhile, so I couldn't resist on this one. Less on the abstract representation of coverages (sorry too old and too dumb, can barely understand word one of those things- I am still trying to grapple with the discussion from a couple of years ago that everything is a "feature", which implies if everything is then there is no discrimination power to the term and therefore has no functional meaning), but more on the idea that SOS, WFS, and the CDM say, for in situ data are all just different ways of representing the data. I would argue that they are not, and that there is a fundamental important difference. First, though this is a little glib, I don't think WFS has the data model for ocean observations, and most of what I have seen just shove the data into some WFS structure because you can. So I want to focus on SOS (SWE) and CDM. To my mind, SOS is a step backwards, because it puts the focus on the sensor, rather than on the ocean. For most of the GALEON community the focus is on the ocean, and in this case the 4D (5D if we count forecast time) ocean. I am not at all convinced, given some recent emails about WMS that I had, and some recent WCS decisions, that the OGC community understands nor is ready to embrace a 4-D ocean. Let me give an analogy. When an operation is going on in an operating room, there are all sorts of sensors connecting to the patient. yes, it is important, at times, to get the metadata for the sensor, in order to check it and calibrate and the like. But during the operation the key piece of information is the state of the patient, as can be put together from the different sensors, not the state of the sensors. SOS gives us the latter, while I would say GALEON's main concern is the state of the ocean, that is the former. The closest I have seen on the OGC world to the latter is CSML. Unfortunately, NOAA IOOS, at least as of now, did not decide to go with CSML. I would say rather than trying to harmonize apples and oranges, a failed enterprise from the start, let's work on harmonizing where the world view and data model share an underlying common viewpoint. -Roy putting on his asbestos jacket :-)
galeon archives: