Hi all,
First, in response to Steve's question, I obviously oversimplified the O & M concepts to
make my points. The feature of interest covers a wide range of entities -- depending on the
particular data user who is interested in the feature. All the items in the gazetteer list
you provide are features of interest to someone studying those entities or phenomena. In
fact there is a concept known as the "proximate feature of interest" in the case of
observations and it is basically the area near the sensor. So that's the feature of interest
to those involved more directly with the measurements. But, as Ron points out, for some data
users, their feature of interest might not even exist at the time some sensors are deployed,
e.g,, Hurricane Katrina or the Storm of the Century. (You'll need an event gazetteer for
those.)
_From our community's perspective however, a key point is that many of the features of interest
have properties such as temperature and pressure that vary continuously within the feature of
interest. Our observations and forecasts can be thought of as O & M "sampling
features," that is, they are estimates of the properties of the feature at a specific set of
points in space (although sometimes a proxy for a spatial dimension is used) and time. These
sampling features and especially collections of them (which is what we most often serve) are
valid coverages -- both in the realm or ISO 19123 and in O & M.
As Wenli points out, the current WCS definition of a coverage is much more
restrictive. In the case of WCS, the sampling points must be at regular intervals
along each spatial axis. This just means that the current WCS only deals with a
subset of coverages as defined by ISO 19123. But I firmly believe that, when we
talk about collections of datasets, the Scientific Data Types of the Unidata
Common Data Model and the Scientfic Feature Types of CSML are standard coverages
according to both ISO and O & M.
This leads us to the area where we have to work hard to eliminate some of the
fuzziness Steve alludes to. For datasets in our own community, the Coordinate
Reference System (CRS) information in particular has to be made much more
explicit, so that we can clearly specify where in space the observation points
reside. That is not a simple exercise for many of our data collections: take
the case of a collection of ground-based radar volume scans for example. To me
this is the crucial area where the CF conventions have to be enhanced for each
of the scientific data types.
This is particularly disconcerting for me because it means that I'm finally
going to have to figure out what the heck a CRS is. So, if I'm quiet for a
while, you'll know why.
But, all kidding aside, I am convinced that this is the next important area for
us to address. The conceptual framework is there in the standards, but we have
a substantial task ahead of us to fill in the detail in the conventions and in
the access protocols -- whether we end up expanding the coverage types in WCS
or augmenting one of the other protocols.
-- Ben
On Tue, Oct 7, 2008 at 12:58 PM, Steve Hankin <Steven.C.Hankin@xxxxxxxx>wrote:
Not to join the discussion in its essence, but a digression to share an
experience regarding the application of "Feature of Interest". In the NOAA
IOOS efforts (i.e. in the context of the coastal oceans) to define an XML
application schema suitable for SOS this topic came up. Agreement on what
the "Feature of Interest" was became elusive in some cases, because the
scope of interest by the final user of the data is often ambiguous. If we
place a mooring in the shelf region off Fudge Point, Hartstine Island,
Washington, in Case Inlet in southern Puget Sound is the feature of interest
- Fudge Point shelf?
- Hartstine Island beaches?
- Case Inlet?
- South Puget Sound?
- Puget Sound?
- US NorthWest Pacific Coast
If there is a clear guideline on how to blend ones gazetteer with the
"Feature of Interest" to resolve this ambiguity, our folks in IOOS didn't
find it. Might this be another example where the continuous nature of the
medium (ocean or atmosphere), renders otherwise straightforward GIS concepts
fuzzy?
- Steve
