Difference between revisions of "Desired Characteristics of Air Quality Data Systems"

From Earth Science Information Partners (ESIP)
Line 64: Line 64:
  
 
'''Principles:'''
 
'''Principles:'''
Diversity of tools and applications.  This is important to assure a robust system; it appeals to specific users, and provides flexibility.   
+
* Diversity of tools and applications.  This is important to assure a robust system; it appeals to specific users, and provides flexibility.   
 
* to provide flexibility, the system should place a premium on modularity and portable development.   
 
* to provide flexibility, the system should place a premium on modularity and portable development.   
 
* visualization and data provided to end user should have scientific credibility, including information on levels of quality and a document change of custody and data source.     
 
* visualization and data provided to end user should have scientific credibility, including information on levels of quality and a document change of custody and data source.     

Revision as of 22:45, March 10, 2008

Back to < Community Air Quality Data Systems Strategy

Desired Characteristics of Air Quality Data Systems

Chapter text here.


Comments from Data Summit Workshop

Group A2: Enabling Data Access

Data system capabilities. These five information capabilities reflect the breakout’s sense of the capabilities that are foundational to enabling data access that either don’t exist or can be improved upon. An improved ‘system’ would:

  1. Making access to data the standard expectation for government funded data;
  2. Increase access to orphan or gray data ;
  3. Include new classes of data such as model outputs;
  4. Provide easy access to relevant archived/versioned data;
  5. Be robust and stable to so that application developers and their funders would be confident in relying on such a system, even though they do not own it; and
  6. Be consistently described

Principles:

  • The system would assume that information is always accessible when data owners define appropriate, and ownership and stewardship responsibilities are established. This would include versioned and archived information.
  • The system will enable user feedback in all parts of Data Value Chain and be consistently described.
  • The system and its participants will adhere to a community defined and governed suite of standards/conventions.

Community Actions:

  • clarify ownership and stewardship responsibilities,
  • must assure that when data is accessed credit is received when credit is due, ,
  • work as a community to define the expectation of data accessibility by type of data.
  • establishing a standard mechanisms for data discovery and description
  • identifying what in the system can and should be standardized.
  • Learn from the experience of partner who have been working these areas ahead of us.

Group B2: Data Processing and Integration

Data system capabilities. Group B2 discussed data processing and integration. Group B2 identified three priority information capabilities:

  1. Providing value-added functionality including filtering, aggregation, transformation, fusion, and Pre and Post processing QA/QC
  2. Enabling Feedback on version changes, measures on performance from community and automated value added services (see above), and communication of assessments for suitability for use.
  3. Establishing standard protocols for data and service access. Starting point for these standards are those adopted by the OpenGIS and GEOSS, including: Web Coverage Services (WCS); Web Feature Services (WFS); Web Map Service (WMS)

Principles:

  • Provide adequate information to end-user application developers to allow appropriate development;
  • Provide knowledge and insight in post processing and analysis;
  • Accommodate Metadata demands;
  • Have reliable and robust value added services; and
  • Be stably governed including service level agreements where necessary.

Community Actions:

  • Inreach and outreach. Inreach by increasing visibility within partner agencies, specifically mentioned was EPA. Outreach would include providing ‘layman’ explanations and working to relate/link the efforts of this community to parallel groups and projects.
  • importance of continuing this process including implementing a governance mechanism to convene the community in a fashion that allows decision making.
  • Identification and execution of a pilot, candidates included remounting capabilities of the Health Effects Institute or establishing a CAP for an specific AQ event class

C2: Visualization / Analysis

Data system capabilities.Group C2 had the responsibility for visualization and analysis and brainstormed a long list of desired capabilities.

  1. Multiplatform support (flexibility)—ability for user to use with many systems
  2. Standards-based spatial and temporal capability
  3. Ability to aggregate by user, including multiscale
  4. Display and communication of uncertainty
  5. Sufficient description/annotations of visualization (e.g., units, scales
  6. Capabilities for interpolation (spatially & temporally)
  7. Multiple options for visualization (e.g., multiple ways for interpolation, including no interpolation)
  8. Recommended default with other options for more advanced users
  9. Tiered capabilities
  10. Consistent Color
  11. Ability to interface/export/translate between standard systems (e.g., Google)
  12. Ability to discover
  13. Means to support a defined need or user group
  14. Include multiple data types & forms – ground, satellite, models and able to work with multiple scales
  15. Multiple Output Forms (e.g., PNG, MPEG, KML/KMZ, Excel, PPT)

Principles:

  • Diversity of tools and applications. This is important to assure a robust system; it appeals to specific users, and provides flexibility.
  • to provide flexibility, the system should place a premium on modularity and portable development.
  • visualization and data provided to end user should have scientific credibility, including information on levels of quality and a document change of custody and data source.
  • to help end users, visualization & analysis products must include interpretation and help files. This is, in part, accomplished by assuring that the ‘system’ knows its users and how they want the information. This type of interface with users could help with defining user requirements, building community, enabling feedback (up and down stream).
  • visualized at appropriate spatial and temporal scales for analysis.

Community Actions:

  • Owners of systems should make services available outside firewall and put WMS/WCS standards in place (e.g., datafed, GIOVANNI).
  • Tool providers need to ask for & include lineage of data (be explicit in presentation). Existing systems should make their info available as web services.
  • EPA, NOAA, NASA, CDC should develop interagency agreement to define commitment to the process.
  • community must convene to develop guidance for metadata for end users (i.e., idiots guide for metadata”).
  • community must continue to engage end users through outreach, pilots, requirements development, and by linking end/users back to data generators. As part of this outreach, the community should consider an end-user panel/advisory group.
  • To energize the community and especially the federal contingency, partners should enact/reenergize/update interagency MOUs and begin briefings within agencies including successful examples/models and an inventory/evaluation of existing systems.

Related Links