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.
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)
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
swath - data model which gives content/ contextual representation
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?