NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Roy, For now, let's just say that I understand your animal track scenario better now, but I'll put off an attempt to explain it in terms of my use cases. The more important issue that we agree on the starting point. In fact, my use cases were intended to illustrate the main data types in the CDM and CSML. The one nuance that I've added is that we explicitly consider collections of these data types. We often serve and request such space-time collections of point data, station data, trajectory data, etc. But, if you look at my use cases, I think you'll see pure point data (lightning), station data, profiles, radar radials, trajectories and gridded data. (I left out swath, but a representative swath case can be added.) Those encompass most of the data types in CSML and CDM. I am convinced there are a lot of OGC people who very much want to work with us on making such data collections available via standard interfaces.. My use cases are an attempt to get illustrate the types of data we work with. As I see it, the next important step is for us to come up with CF conventions for these data types. Then my view is that we can work within the OGC and ISO to establish these CF-netCDF as standard encodings for coverages. It won't all happen at once, but the conceptual framework is there; what remains to be done is to work to get each data type through the process -- one at a time if necessary or in parallel if different groups work on different data types. I think we are in basic agreement about the next steps. Maybe a phone call next week would be a better way to clarify our thoughts about a plan for getting where we want to be in the longer term. -- Ben On Sat, Oct 11, 2008 at 12:19 PM, Roy Mendelssohn <Roy.Mendelssohn@xxxxxxxx>wrote:
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
galeon archives: