Property:Discussion

From Earth Science Information Partners (ESIP)
Showing 11 pages using this property.
U
(http://www.usgeo.gov/docs/nto/Air_Quality_NTO_2006-0925.pdf) 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.  +
E
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.  +
D
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.  +
E
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.  +
C
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.  +
I
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
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  +
E
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.  +
N
I