NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Ron. I agree. I don't think we have a big rift here and I certainly wasn't trying to create one nor imply that there was one. My comments in earlier emails were to try to clarify for myself and perhaps others that we need to try to understand that we are often talking about data and semantics on several layers (oh God, here he goes on another long rant): (Level 1) Pure Observation: Only time coverage is considered. There is the concept that observations are really in their purest form just time-dependent measurements regardless of the dynamics or lack of dynamics of the sensor system, and regardless of the sampling pattern. In this concept, geometries are not yet considered, but might be implied or derivable from understanding the sensor system characteristics (e.g. dynamics, sampling pattern, sampling rate, etc). There are at this point perhaps several different geometries that might be considered relevant depending on what one wants to do with the observations. This is the approach that many of us have typically tried to remain at in SWE. Observations are strictly time-based measurements, SensorML can describe the system such that various geometries (including geospatial) can be derived, and SOS should only allow subsetting on time and property axes. Any spatial subsetting in SOS should only involve determining which sensors might be relevant (particularly for in-situ stations) but subsetting an actual coverage in SOS should be beyond scope of the SOS. That's why I typically refer to SWE services as "low-level". (Level 2) Various other coverages are considered. In this concept, various coverage domain could be defined as suitable for a particular set of Observations. Obviously, geospatial coverage is one of those (e.g. points, lines, grids, polygons, images, etc), but there could also be other domains such spectral/frequency, species, size, etc. These possible coverages fall out of or are implied by the nature of the sampling, the dynamics of the system, or the characteristics of the sensor. But typically, there is a decision, and possibly a set of calculations, that wemake to put the observations into a specific coverage domain.
This is where taking time-tagged GPS pure observations and deciding to represent it as a line geometry happens. This is where one derives a sensors footprint or a georectified image based on the dynamics and scanning characteristics of a remote sensor. Although I am fully aware that WFS and WCS perhaps can and have supported Level 1 observations, I believe that it is in the Level 2 concept that these have traditional excelled, whereas the SWE encodings and services have specifically been geared toward Level 1. Level 2 observations might involve geometries but are still not necessarily graphical representations. (Level 3) Graphical Representation / Portrayal. OGC has been wise in appreciating during the design of GML, WFS, and WCS, that is important to keep data content standards independent of graphic content standards. Level 3 gets into the portrayal of an observation (i.e. the graphical view). In other words, take that aircraft path, make it a line deifned by these points, color the line blue, and make it 3 pixels wide. Or better yet, make the color of the line at any point depend on the concentration of ozone measured along the path and use this particular color map. Take this temperature observation and display it in big yellow letters at this location. This is the level that VPL, KML, and Collada are best suited for. It is important to understand that this is a very important level, but that at this point we are no longer interacting with the actual observations but a graphical representation of the data. This is also where technologies like OGC's Style Layer Description (SLD) language play an important role because they provide us a way to describe the mapping from Level 1 or 2 to Level 3. The important message of this long rant is that all levels are important, but that it is VERY important that when we design standards or semantics or when we converse on specific data types or services, that we understand atwhich of these levels we are dealing or desiring to deal.
By the way, this is a thread that is weaving around in various forms on the Galeon, SWE-WG, and SensorML forums. For that reason, I have just cc'd the other 2 groups (sorry about the blanket and redundant coverage folks). Thanks. Mike Botts -------------------------------------------------------- Mike Botts, Ph.D. mike.botts@xxxxxxx Principal Research Scientist http://vast.uah.eduNSSTC University of Alabama in Huntsville (256) 961-7760
Huntsville, AL 35899 USA (256) 652-0165 cell --------------------------------------------------------
-----Original Message-----From: Ron Lake [mailto:rlake@xxxxxxxxxxxxx] Sent: Thursday, March 13, 2008 4:20 PMTo: Mike Botts; Woolf, A (Andrew); Gerry Creager; Unidata GALEON Subject: RE: [galeon] Fwd: CDM feature and point types docs Hi, I don't think anyone is arguing about the merit of point, profile etc geometries - maybe more the hierarchy of the semantics. These things seem to me to ALL be observations or collections of observations. IS their disagreement on that? I don't think anyone is trying to tell anyone how to think about the world - but we are seeking to develop the appropriate abstractions in a manner that can generalize across multiple domains. Marine and atmospheric scientists are by no means the only group of people who make measurements that are associated with points in space, points along tracks etc. I think the "rift" here is less deep than you think. Ron
galeon archives: