Hi Ben:
Assume the simpler case for the second scenario. I have gridded data
at depth, and I want all the data in the top 200 meters for a given
bounding box and parameter. The animal case is not quite the
equivalent of the sensor - for the sensor it is a single sensor whose
track I am storing. For the animal, I have a vector of is locations
and depth, and say I have a 4-D dataset on a grid, I now want to
tunnel through that dataset to find out the environment based on
another set of data, not the data that a sensor on the animal
detected. The animal sensor only gives position/depth.
Neither of these are synoptic nor a single time series from one
sensor - and I think it is very important to include these in the use
cases because our experience to date is these types of data extracts
have not really been in the OGC radar and for which extracts are
either impossible or else extremely complex.
The one exception to this is CSML, which I like for the very reasons
that the features types align well with both how users of the data
think of the data and how they use the data. And the CDM is good for
the very same reasons, and to beat a dead horse, the two are very
close. This is the very reason why I have argued to make the
crosswalk between CDM and CSML be the main activity, and then use
whatever services CSML ends up using, rather than to constantly try
and convince a very large body that all the scientists that use the
data perhaps have reasons for thinking about the data they way they
do, rather than the way OGC says we must (and remember I am actually
a research scientist, and I still access and use large quantity of
data in analyses - these are not theoretical discussions to me, but
ones that affect my day to day ability to do my work). I believe
Andrew Woolf made a similar comment awhile back (it was actually
worded much more strongly but I will leave it to Andrew to decide if
he wants to repeat it).
Thanks,
-Roy
On Oct 11, 2008, at 11:01 AM, Ben Domenico wrote:
Hi Roy,
You make very good points. In my effort to keep the use cases
brief, I did not make it clear that the intention was for each one
to represent a particular category or type of data.
So to take your cases, if I understand the animal track environment
example, I am guessing you are talking about an animal (perhaps a
dolphin) that is instrumented to monitor some properties of its
environment as it travels, . In my list, that would be an ocean
equivalent of the trajectory case that's represented by the aircraft-
borne observations. My thought is that, if we agree on a set of
conventions for representing such trajectories, we can use it for
observations along dolphin tracks, aircraft tracks, ship tracks,
etc. One additional note is that, in all my cases, I emphasize that
we should be prepared to address collections of such observations as
well as individual ones. So I will find a way to make it clear that
my proposed use cases are intended to be representative and and
could be used for other cases that involve similar data types.
Regarding the other case you mention of comparing present conditions
with long term trends in a particular area, my idea is that those
are just different space-time bounding boxes for the data
collections in the region you are interested in. If you are talking
about using observations from moored buoys in this case, it fits
nicely with my proposed case for obtaining the station obs in the
region around Paris. If you include CTD ocean soundings, it's
equivalent to the Paris use case that includes atmospheric balloon
soundings.
You say you can deal with these cases in the netCDF/OPeNDAP world.
My question is, if I define a region of interest in the ocean and a
set of time bounds (short or long term) and then ask for all the
observations from instrumented dolphins, what are the CF conventions
that describe the netCDF that I get back? More specifically, how do
I figure out where and when all those observations were taken?
I would ask the same question regarding the station data in the
upwelling region case you mention. What are the CF conventions that
provide the information needed to figure out where and when the
station (or buoy) data points were observed?
Those are exactly the kinds of conventions John Caron is working on
and where I think we need some consensus. If we come to agreement
on those CF conventions, then we can propose the resulting CF-netCDF
as a standard coverage encoding as a means of connecting our work
with the formal standards community.. But, if you think we already
have an explicit way to deal with these cases in the netCDF/OPeNDAP
world, please let me know. Maybe there's a way to short cut the
multi-step process I had envisioned.
On the other hand, my next task is to revise my use cases to
indicate that, while they are written as specific cases, they are
intended to be representative of a family of cases for each of the
data types. Hopefully I can do that without getting too wordy.
-- Ben