- 1 Use Cases for Ontology Development
- 1.1 Example
- 1.2 Note re measurement platforms/techniques
- 1.3 Airborne Dust Detection in MODIS Imagery using Data Mining Services
- 1.4 Atmospheric Science Mission use case
- 1.5 Ice use case
- 1.6 Aerosol Search Use Case
- 1.7 Longitude-Time Use Case
- 1.8 Patterns of spatial transformation
- 1.9 Extract sub-sets of files
- 1.10 Ocean Data Postprocessing use case
- 1.11 Spherical Harmonic use case
- 1.12 Long-Term Global-Scale Climate Analysis use case
- 2 Other
Use Cases for Ontology Development
The ESIP Solutions Use Case template is [here]
Use case: find and display in the same projection and coordinate system, sea surface temperature and land surface temperature from a global climate model.
Note re measurement platforms/techniques
Many of the earlier use cases have captured products of satellite systems, but could also be supplied with products from airborne systems (airplanes, balloons, etc.). While these airborne applications have not been captured in detail yet in the use cases, they are very analogous to the products and results from underwater AUVs (for planes) and drifters (for balloons).
In a similar vein, although animals intuitively have many characteristics of potential interest, it is argued that each of those concepts can be mapped to analogous concepts for man-made platforms like cars or AUVs (autonomous underwater vehicles).
Airborne Dust Detection in MODIS Imagery using Data Mining Services
Background: Growth of plankton in remote ocean locations is limited by the availability of iron. Dust storm from arid and semi arid regions transport dust containing iron to remote ocean locations, which spur the growth of plankton. Phytoplankton accounts for more than half of the global photosynthetic activity; they act as an important sink of atmospheric carbon dioxide and thus have the potential to impact climate. Emission of Dimethly Sulfide (DMS) is another pathway through which plankton affects climate. DMS emissions increases cloud condensation nuclei (CCN) present in the relatively clean marine atmosphere, altering the microphysical nature of marine stratus. Increase in CCN results in more but smaller size cloud droplets in marine stratus thereby increasing cloud albedo and creating a cooling effect. In order to explore connections between iron fertilization via dust storms and plankton growth, algorithms that accurately detect dust storms in satellite imagery are required. NASA’s Moderate Resolution Imaging Spectroradiometer (MODIS) provides global data with the correct spectral properties for dust storm detection. Unfortunately, there are no well accepted dust storm detection algorithms or methodologies for this data set. Different researchers have devised different dust indices along the lines of Normalized Difference Vegetation Index (NDVI)and suggest different threshold values. Data mining techniques such as unsupervised classifiers can be used for this detection. Unsupervised classification techniques such as clustering not only provide the ability to automatically group pixels in different classes but also determine the appropriate thresholds.
Use case: Find appropriate MODIS data with airborne dust, preprocess the data, select the 'optimal' clustering algorithm and apply the algorithm.
Atmospheric Science Mission use case
Brian: Atmospheric retrieval and validation. Compare temperature profile retrieval from AIRS and find space time match-ups between GPS occultation and AIRS temperature profile.
Bruce: Level 2g - Create a plot of direct comparison of MODIS NDVI as a timeseries for a year with the vegetative index from a flux tower.
Bruce to add narrative.
Ice use case
Ruth: Compare what atmospheric forcing component should be doing with what the sea ice motion is doing ; involves buoy, point data, and rem-sens. like Bruce's so we will proceed with the MODIS and generalize
Aerosol Search Use Case
Locate the access points for aerosol data or services that would be useful and usable for characterizing the extent of the ash cloud plume from the 2 May 2008 Chaiten volcanic eruption. Useful data are those that have information that can be brought to bear on the problem; usable data are those that are available in a form that can be used in my analysis framework.
Target products would include such items as:
- MODIS L2 Aerosol product, Terra and Aqua
- MODIS L3 Aerosol product, Terra and Aqua
- MERIS Aerosol product
- GOCART Aerosol model
- CALIPSO Aerosol classification
- OMI L2 Aerosol index
- OMI L3 Aerosol index
- AIRS Brightness Temperature difference (ch ? - ch ??)
- MISR L2 Aerosol(?)
- Experimental CALIPSO aerosol sub-classification
- GOES Image with analyst's assessment of ash extent
- Hysplit model run
Target services could include:
- OGC WCS or WMS access
- OPeNDAP access
- On-the-fly virtual products
- On-demand model runs
Factors that go into the usefulness include:
- observation vs. model
- type of measurement (e.g., radiance, aerosol index, AOT/AOD, ...)
- method of measurement (e.g., infrared, visible, UV)
- source of measurement (instrument or model)
- processing algorithm
- horizontal resolution
- temporal resolution
- temporal "alignment" (e.g., averaged vs. synoptic vs. temporal progression, different types of data days)
- data product or service maturity (e.g., operational, validated research, provisional research, experimental)
Factors that go into usability include:
- data format
- spatial reference system (swath, grid; type of grid)
- access means (protocol; synchronous vs. asynchronous; machine-accessible or not...)
- access restrictions
--Clynnes 21:23, 8 January 2009 (EST)
Longitude-Time Use Case
This case refers to a 2-D or 3-D slice of a larger dimensional space. The data are represented on a regular grid, but the dimensions are hybrid space-time. In the simplest case, the two dimensions might be longitude and time with values corresponding to a fixed latitude and altitude values. In the more complicated longitude-time case, the latitudes and/or altitudes correspond to averaged values.
Patterns of spatial transformation
Space-time matchup between points and satellite swath data or any gridded data (model or level 3 from instrument retrieval)
Grid to grid
Point to grid - Tile (part of a grid) to point
Point to swath
Swath to swath
Swath to grid
Moving point to ANY
Extract sub-sets of files
Extract data from a file (or set of files) using a geographic region selection. This can involve L3 (grid) or L2 (swath) types. Need to know underlying representations so that an operation can extract the relevant information. Anytime we come to a service operation, we will name it along with IOPs.
E.g. Orbiting satellite (need period and inclination angle for satellite), L2 swath width (in km from center of orbit from NADIR), how does single orbit ma[p to a granule file? sometimes a granule file = one orbit, sometime it is 1/2 orbit, sometimes someother fraction, e.g. can be greater than 1
Granules - modeling the full detail.... (OCO has 6-16 granules per orbit). Spatial coverage - have tied this to notion of granule. Agree on meaning of granule (satellite, can vary between satellites).
at L2 some of these inhomogenieties are removed. grid but can be regular or spacecraft coordinate
- capture different between science and engineering data (types)
swath - data model which gives content/ contextual representation
- type of a grid (asserted by Rob) - satellite L2 representation - can be 1D, 2D hor, 2D ver, 3D vol (2D hor U 2D ver)
- sampling frequency (temporal)
- starting location and time
- repeat cycle (after x time, repeats, uniquely defined at some spatial and time location, e.g. equator crossing, zero time for period),
- footprint - area for which a common data value is used to represent a spatial coverage (shape and area - planar?)
- can footprint be 'volumetric' - depending on instrument (leave for later)
- bin - size and shape - go into a swath
- spot - raw spatial coverage by instrument - single value is recorded (corrections may be made after a level of processing)
- swath = grid of spots (data-structure-sense) Chris
- each element in a swath is a bin (Rob)?
- relation between spot/bin/footprint/ grid
- spot -> averaging spots into a regular pattern (aggregation based on spatial proximity) - deals with irregularities of spots (L0)
- bin (regular) - square or rectangular (L1)
- grid - regular collection of bins, ordered accordingly to spatial contiguity, aggregation may still occur (L2, 3, 4)
- swath is a grid in spacecraft coordinate system
- refer to John's
- mowing the lawn - a series of discrete measurements is cast into a visual representation which is usually termed as a swath (extending over a spatial and temporal extent)
- not many uses of the term swath, used more as common term rather than referring to something in an actual data product
- irregular grid (still a regular collection but not regularly spaced)
- strong relation (computational) between measurement scheme and eventual data product
- spot may never be seen (is a 'point' or maybe a 'line' but no recorded spatial coverage)
- bin is related to computation on measurement type and is usually not recorded as a product
- grid is the usual product
- capture another orbital characteristic - include notion of ascending and descending (calibration and error estimates are often associated with transitions between ascending and descending
granule - tied to format (smallest element of the what is being captures that is being inventoried, e.g. in ECHO). granules have some unique identifier (e.g. granule_id). gives structural representation.
orbit details are properties of the platform (cf. MMI in-situ with other RS platform)
swath width is property of the instrument
satellite drift - as a correction - belongs to platform and is used on by the service (not data product)
locational accuracy (moving or not) - georeferencing - associated with data product, represent error and accuracy (+/-), important for error propagation
other platform properties that are relevant (from John Graybeal)
- location, depth, surface floating (i.e. vertical correction, fixed or degrees of freedom), orientation, autonomous vehicle coordinates - which includes a computation (cf. satellite orbit and correction), platforms on platforms, sensors on sensor - systems (follow chain of association to get actual properties, e.g. location), multiple sensor considerations (e.g. two sensors, e.g. which sensor was used, e.g. primary versus backup),
- path that is followed in any one dimension is not straightforward, 3-d irreg vol, 2-d irregular plane, sometimes is captured with data and othertimes is computed afterwards - design decision per sensor and/or platform, design will also include dependencies which can be determined both before and after data is collected
- temporal - at a given frequency or on command, regular or irregular (massively, arbitrary), can be event triggered (human or otherwise)
Link to event ontology (often connections between events and data collections and analysis aspects)
- log files, annotations, ancillary data - messaging and actions, related to data, always time related? or are there spatial examples (e.g. South Atlantic Anomoly).
- maybe spatial re-location based on feature (c.f. event) may depend less on time or does not care about time (e.g. biologic, wave, eruption cloud, ....) - what elements can be associated from a feature ontology?
Ocean Data Postprocessing use case
Use case: Kick off post-processing of a collection of datasets from an oceangoing experiment, according to the instrument type, data record types, and deployed characteristics of each instrument. (Note: 'instrument' in this context means component that is capable of collecting data and reporting it in digital form. It may be as small as a single sensor, and it may or may not be deployed on another platform or component.) Use information about the parameter type, measurement path through the water, and other relevant characteristics, to determine what kind of post-processing to perform.
Spherical Harmonic use case
Some datasets have the independent variables transformed from space and/or time to spatial and time scale, respectively. A common method to store global climate data is to transform longitude and latitude into longitude and latitude scale, and the resulting numerical coefficient values are known as spherical harmonics.
Long-Term Global-Scale Climate Analysis use case
Hook: Multi-year El Niño-Southern Oscillation (ENSO) Analysis as performed by Eric Fetzer for NASA Energy and Water Cycle Study (NEWS). Most A-Train data sets are long enough (and scientifically mature enough) to characterize annual and ENSO cycles. This analysis is often neglected in the search for long-term trends. Want to look at mean annual cycle, and interannual variability. Get global-scale coverage of Level 2 AIRS data for water vapor. Perform average of measurement values over a calendar month for one year (e.g. 20021201-20021231) and another year (e.g. 20031201-20031231). Compare the two monthly means to find any change in water vapor patterns over potential El Nino-La Nina transition.
notes for Peter
underlying representations of data
format of ..?
data models within the format, within each file there are different structures
hypers have plots, content within the images
independent and dependent variables (services ontology mentions this, a little class modeling in there)
averaging of level 2 data can remove monthly variations, a monthly means product that is level 3, to compare global scale trends (can add this to the wiki as separate use case)
some 'swath' definitions in marine use
sonar mapping: akin to satellite observations
ship measurements: path through the water, either of the ship or as sampled by in-situ and/or remote sensors
AUV measurements: path through the water of the platform
post-processing: a visualized 2D or 3D section of the water (usually constructed after the fact from measurements (usually irregular) within that section)