Candidate Focus Areas for ESIP AQ WG
< Air Quality Community Summer 2009 Meeting
To add a Candidate Focus Area for AQ, enter the Focus Area title below; if a page with that name already exists, you will be sent to a form to edit that page.
A. Planning/Communication Focus Areas
Title: Commission 6-8 “use cases” for key Air Quality Data Procesing/Analysis Value Chains
Discussion: Two use cases were discussed during the meeting as an experiment to see if working through the “data value chain” at a “moderate” level of detail could help identify/clarify gaps/opportunities for collaboration and investment. The exercise was rushed, and did not include participation from “real users” but produced significant discussion and helped identify/validate many of the candidate topics identified in this list, including this proposal (#10). The proposal is for a more formal commissioning of 6-8 of these cases, done right, with 2-3 being done by January
Candidate Product: Activity would produce two kinds of products:
- Process of conducting the use case explorations and documentation would produce new shared understanding among the focus/customer groups used, and the workgroup itself in overseeing and assimilating the results---this could help greatly in the task of refining what we meant by “AQ information infrastructure”
- Hard products would be one or more reports on the 6-8 use cases, conducted in sufficient detail to identify both general and specific opportunities/investment areas—ideally these would include specific data, data services or applications that could be commissioned immediately. These cases could validate/inform many of the other focus areas identified here.
- Commission 2-3 use cases to be completed before January. Candidate use cases include: HTAP, NO2, and AQ forecasting. AQ Workgroup members are asked to provide suggestions to L Friedl for suggestions on use cases and available expertise to conduct these cases.
- Note these cases would likely re-identify/refine nearly every item on this WG list.
- Note these cases would likely re-identify/refine nearly every item on this WG list.
Title: Update the “AQ Near-Term Opportunities” Report
The NTO report provided a good framework for areas of interest. Proposal is to use this framework to help identify accomplishments and gaps, and communicate those to ourselves and others. Most of the topics identified in the WG meeting list represents restatements or extensions of topics in the NTO report.
Candidate Product: Updated Report NTO Report
Near-Term Action/Product: ? Scan of NTO report and mapping to current and proposed activities/products?
B. Improving AQ Information Infrastructure
Title: Configure and document a standard approach to access “all” surface monitoring data through common interfaces.
Discussion: The focus area of surface monitoring data was offered a tractable domain. This would include a description of what data resources are available, and establishment of a common interface to this data. Note this idea was then expanded upon in the next proposed focus area.
Title: Document AQ community conventions/practices for WCS as a generic data access protocol.
Discussion: Many WG members are currently publishing data using various implementations of WCSs as a generic data access protocol. These variations include conventions in service/layer naming, return payload formats, and “extensions” of the WCS standard arguments, many members now have experience with the pro/cons of these various approaches and this learning can be shared. We assume WCS will be one of the community’s de facto standards for a while. This activity would elicit, discuss and document some current/best practices of how AQ WCS are mounted towards the goal of easing and improving the interoperability of current and future implementations.
Candidate Product: ?
Near-Term Action/Product: List of implemented WCSs with discussion of conventions/extensions employed.
Title: Establish a practical minimum core set of descriptors for the AQ community, to be used in our various resource catalogs.
Discussion: Development and experimentation with resource registries continue. A key missing component of this infrastructure however is a practical common set of descriptor for this communities key resources (e.g. ground based observations, satellite data, model data, and the related intermediate products and services). While there are likely to be ongoing debates and developments about the preferred super-set of such descriptors, this area focuses on establishing a core minimum which would be used to demonstrate/evaluate utility of such registries beyond the individual Agency registrations and/or the limited cross-Agency pilots conducted to date.
Candidate Product: Documentation and demonstrations of a core descriptor set.
Title: Explore a standardized template/package for common AQ data for CMAQ/other model ingest
Discussion: WG members had extensive discussions about the complexities, costs and ideosnycracities of preparing data for CMAQ model ingest. Case study exercises also highlighted this step in the value chain as a potential area of improvement. Could improved collaboration and documented practices improve the performance and efficiency of our AQ modeling? Group estimated that there are on the order of 20 groups in the US performing similar modeling using similar (in some cases identical) base data and implementing similar data manipulation processes. However the future of modeling evolves (e.g. more people running CMAQ, and/or “modeling as a service” run in fewer places) there was agreement that we will first need to improve and establish conventions for this step in the process. In the “preferred future” for the AQ community, there is less effort, and more consistency/transparency in preparing data for model ingest.
Candidate Product: AQ “data package” definition and documentation.
Near-Term Action/Product: Commission a scoping document to characterize this issue better, by:
- Identifying/documenting the common base data and the key processing issues associated with each;
- Assess feasibility of developing/describing useful convention/templates for these.
- Propose straw outline for a common template/package if doing so appears feasible.
Title: Explore standard interface, conventions and/or platform for inter-comparison tools for observational, remote sensing and modeling data.
Discussion: Participants discussed improving support for observational, satellite and model output inter-comparison as a potential piece of common infrastructure. This could be as a set of common conventions, requirements, software and/or services. Current practice is often a “build it ourselves” approach. Several related candidate products were identified: a) requirements statement to identify common desired functionality of such a tool for AQ users, b) definition/conventions of a common “model output” format which, along with existing/improved format conventions for the observational and satellite data would allow greater portability between data and tools, c) an “inter-comparison tool API which would support development of services and clients for this functionality, and d) exploration of actually developing general purpose software and/or services for such a tool. Note that these first two products (requirements and standard model output formats) are seen as valuable because they inform existing tool developers about community interests in the near term.
- requirements statement to identify common desired functionality
- definition/conventions of a common “model output”
- an “inter-comparison tool API
- common software and/or services built as part of the common infrastructure
Near-Term Action/Product: Scoping document with outline of functional requirements and feasibility/utility check on development of common model output format.
Title: Improving our infrastructure for transparency, “feedback” and collaboration on AQ resources
Discussion: This area captures a several of very related ideas centering on improving the “soft” infrastructure for AQ collaboration that did not receive a significant discussion. Some of these could be “promoted” to their own focus areas as a way of moving them forward.
- Improve upstream feedback loops in the AQ data flows especially for model developers and application developers. Use Web 2.0 approaches to do this, for example, by capturing user experience/feedback on various resources similar to “customer reviews” and “seller reputation tracking” on e-commerce sites.
- Establish Common Collaborative Space/Portal Where Related Resources Can Be Exposed, Discussed and Collaborated Upon.
C. Additional “Tactical” Focus Area Suggestions
Title: Identify Additional Data That Could (with system improvements) Routinely Provided to AQ Forecasters
Title: Identify new/additional outputs from AirNow (EPA) and new/different subsets/griddings data from GIOVANNI
Title: NASA and EPA: Explore Google Enterprise Earth/API based data publishing/consumption