Difference between revisions of "WCS Outline"

Latest revision as of 11:39, September 8, 2010

General Description of Atmospheric Model Evaluation Network (AMEN)

Drawing from the GEO Work Plan (Task DA-09-02d)Task

Demonstrate the use of web services to compare global and regional atmospheric models (including atmospheric chemistry/air quality models). Apply to a variety of Earth observations from distributed archives using standardized approaches to evaluate and improve model performance. Draw upon and contribute to the work of the Task Force on Hemispheric Transport of Air Pollution under the Convention on Long-range Transboundary Air Pollution, the IGAC-SPARC Atmospheric Chemistry and Climate Initiative, AeroCOM, and the Air Quality Model Evaluation International Initiative.

HTAP Data Network Pilot

Explain TF HTAP, participating nodes http://wiki.esipfed.org/index.php/HTAP_GEOSS

The GEOSS air quality community and its projects has promoted the use of CF-netCDF as the binary incoming of data both for storage as well as for transmission of AQ-relevant data between servers and clients. The CF-netCDF data standard and the OGS WCS, WFS and WMS data access protocols constitutes a complete package for establishing a network of interoperable data finders, servers and clients.

The network Common Data Form (netCDF) binary data encoding standard

The NetCDF (network Common Data Form) can be used to store and communicate multidimensional data, such as arising from Earth Observations and models. The NetCDF data model is particularly well suited for storing related arrays containing atmospheric and oceanic data and models. Climate and Forecast Metadata Conventions (CF) are used in conjunction with NetCDF as a means of specifying the semantic information. The semantic metadata is conveyed internally within the NetCDF datasets which makes NetCDF is self documenting. This means that it can associate various physical quantities (such as location, pressure and temperature) with spatio-temporal locations (such as points at specific latitudes, longitudes, vertical levels, and times).

This standard has been formally recognized by US Government NASA and NOAA standards bodies. Recently, UCAR has introduced NetCDF as a candidate OGC standard to encourage broader international use and greater interoperability among clients and servers interchanging data in binary form. This is the initial step in a longer-term plan for establishing CF-netCDF as an OGC standard for binary encoding. This will enable standard delivery of data in binary form via several OGC service interface standards, including the OGC Web Coverage Service (WCS), Web Feature Service (WFS), and Sensor Observation Service (SOS) Interface Standards.

For the past two decades, with the help of the U.S. National Science Foundation, netCDF was maintained and actively supported by the University Corportion for Atmospheric Research (UCAR) . NetCDF is a set of software libraries and machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data. NetCDF has a strong and user community Unidata is supported by the U.S. National Science Foundation for the past 25 years.

       Explain TF HTAP, participating nodes
        http://wiki.esipfed.org/index.php/HTAP_GEOSS
       uFIND Interface
       ufind/facets - http://datafedwiki.wustl.edu/images/0/04/IGARSS_InternationalAQCommunity.ppt
       http://wiki.esipfed.org/index.php/HTAP_Report,_Sub-Chap._6_-_Data/Info_System

Development and Conventions and Standards

WCS

Web Coverage Service (WCS) Implementation Specification.OGC 07-067r5

A WCS provides access to potentially detailed and rich sets of geospatial information, in forms that are useful for client-side rendering, multi-valued coverages, and input into scientific models and other clients. The WCS may be compared to the OGC Web Map Service (WMS) and the Web Feature Service (WFS); like them it allows clients to choose portions of a server's information holdings based on spatial constraints and other criteria. Unlike the WMS [OGC 06-042], which portrays spatial data to return static maps (rendered as pictures by the server), the Web Coverage Service provides available data together with their detailed descriptions; defines a rich syntax for requests against these data; and returns data with its original semantics (instead of pictures) which may be interpreted, extrapolated, etc. – and not just portrayed. Unlike WFS [OGC 04-094], which returns discrete geospatial features, the Web Coverage Service returns coverages representing space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties.

The Web Coverage Service provides three operations: GetCapabilities, DescribeCoverage, and GetCoverage. The GetCapabilities operation returns an XML document describing the service and brief descriptions of the coverages that clients may request. Clients would generally run the GetCapabilities operation and cache its result for use throughout a session, or reuse it for multiple sessions. When the GetCapabilities operation does not return such descriptions, then equivalent information must be available from a separate source, such as an image catalog.

The DescribeCoverage operation lets clients request a full description of one or more coverages served by a particular WCS server. The server responds with an XML document that fully describes the identified coverages.

The GetCoverage operation is normally run after GetCapabilities and DescribeCoverage operation responses have shown what requests are allowed and what data are available. The GetCoverage operation returns a coverage (that is, values or properties of a set of geographic locations), encoded in a well-known coverage format. Its syntax and semantics bear some resemblance to the WMS GetMap and WFS GetFeature requests, but several extensions support the retrieval of coverages rather than static maps or discrete features.

WCS Introduction

1 Scope This document specifies how a Web Coverage Service (WCS) describes and delivers multi-dimensional coverage data over the World Wide Web. This version of the Web Coverage Service is limited to describing and requesting grid (or "simple‖) coverages. Grid coverages have a domain comprised of regularly spaced locations along 0, 1, 2, or 3 axes of a spatial coordinate reference system. Their domain may also have a time dimension, which may be regularly or irregularly spaced. A coverage defines, at each location in the domain, a set of fields that may be scalar-valued (such as elevation), or vector-valued (such as brightness values in different parts of the electromagnetic spectrum). These fields (and their values) are known as the range of the coverage. The WCS interface, while limited in this version to regular grid coverages, is designed to extend in future versions to other coverage types defined in OGC Abstract Specification Topic 6, "The Coverage Type" [OGC 00-106].

@@ Line 33: / Line 33: @@
 == Development and Conventions and Standards ==
-===Development of CF Naming Convention and CF Consistency Tools===
+=== WCS ===
+Web Coverage Service (WCS) Implementation Specification.OGC 07-067r5
+A WCS provides access to potentially detailed and rich sets of geospatial information, in forms that are useful for client-side rendering, multi-valued coverages, and input into scientific models and other clients. The WCS may be compared to the OGC Web Map Service (WMS) and the Web Feature Service (WFS); like them it allows clients to choose portions of a server's information holdings based on spatial constraints and other criteria. Unlike the WMS [OGC 06-042], which portrays spatial data to return static maps (rendered as pictures by the server), the Web Coverage Service provides available data together with their detailed descriptions; defines a rich syntax for requests against these data; and returns data with its original semantics (instead of pictures) which may be interpreted, extrapolated, etc. – and not just portrayed. Unlike WFS [OGC 04-094], which returns discrete geospatial features, the Web Coverage Service returns coverages representing space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties.
+The Web Coverage Service provides three operations: GetCapabilities, DescribeCoverage, and GetCoverage. The GetCapabilities operation returns an XML document describing the service and brief descriptions of the coverages that clients may request. Clients would generally run the GetCapabilities operation and cache its result for use throughout a session, or reuse it for multiple sessions. When the GetCapabilities operation does not return such descriptions, then equivalent information must be available from a separate source, such as an image catalog.
+The DescribeCoverage operation lets clients request a full description of one or more coverages served by a particular WCS server. The server responds with an XML document that fully describes the identified coverages.
-* [http://www-pcmdi.llnl.gov/cf CF Convention] | [http://www-pcmdi.llnl.gov/cf/documents/cf_standard_names/ CF Standard Names] | [[Air Quality/Chemistry Naming Conventions| CF Chemistry Names]]
+The GetCoverage operation is normally run after GetCapabilities and DescribeCoverage operation responses have shown what requests are allowed and what data are available. The GetCoverage operation returns a coverage (that is, values or properties of a set of geographic locations), encoded in a well-known coverage format. Its syntax and semantics bear some resemblance to the WMS GetMap and WFS GetFeature requests, but several extensions support the retrieval of coverages rather than static maps or discrete features.
-* [http://datafedwiki.wustl.edu/index.php/2007-12-15_AGU_Presentation_Web_2.0 AGU Web 2.0]
-* [http://cf-pcmdi.llnl.gov/documents/cf-standard-names/about About CF Standard Names ]
+[[WCS General Intro| WCS Introduction]]
-===[[WCS General Intro| WCS Introduction]]===
 * [http://datafedwiki.wustl.edu/index.php/2006-01-11_Data_Flow_%26_Interoperability_in_DataFed_Service-based_AQ_Analysis_System slides for screencast]
 * [http://datafedwiki.wustl.edu/index.php/2006-03-14_WG_on_HTAP-Relevant_IT_Techniques,_Tools_and_Philosophies:_DataFed_Experience_and_Perspectives HTAP/WCS Slides]
-== WCS Server Software for Grid and Point Data ==
-==== [[WCS Server StationPoint Data]] ====
+Scope
+This document specifies how a Web Coverage Service (WCS) describes and delivers multi-dimensional coverage data over the World Wide Web. This version of the Web Coverage Service is limited to describing and requesting grid (or "simple‖) coverages. Grid coverages have a domain comprised of regularly spaced locations along 0, 1, 2, or 3 axes of a spatial coordinate reference system. Their domain may also have a time dimension, which may be regularly or irregularly spaced. A coverage defines, at each location in the domain, a set of fields that may be scalar-valued (such as elevation), or vector-valued (such as brightness values in different parts of the electromagnetic spectrum). These fields (and their values) are known as the range of the coverage.
+The WCS interface, while limited in this version to regular grid coverages, is designed to extend in future versions to other coverage types defined in OGC Abstract Specification Topic 6, "The Coverage Type" [OGC 00-106].
-====[[WCS Server Cube Data]] ====
+===Development of CF Naming Convention and CF Consistency Tools===
-====[[WCS Mediators and Clients|Mediators]] ====
-==Keating 2009: ==
+* [http://www-pcmdi.llnl.gov/cf CF Convention] | [http://www-pcmdi.llnl.gov/cf/documents/cf_standard_names/ CF Standard Names] | [[Air Quality/Chemistry Naming Conventions| CF Chemistry Names]]
-===Questions from the GEOCAPE Science Traceability Matrix===
+* [http://datafedwiki.wustl.edu/index.php/2007-12-15_AGU_Presentation_Web_2.0 AGU Web 2.0]
-* What are the emissions of gases and aerosols important for air quality and what are the processes controlling these emissions?
-* How do atmospheric transport, chemical evolution, and deposition determine tropospheric composition over scales ranging from urban to continental?
-* How do we improve air quality forecast and assessment models?
-* How do changes in air quality drive climate forcing on a continental scale?
-* How does intercontinental transport affect air quality?
-===Learning more from EOS, Applying lessons to GEOCAPE ===
+* [http://cf-pcmdi.llnl.gov/documents/cf-standard-names/about About CF Standard Names ]
-* The Air Quality Community is just starting to embrace the use of observations from EOS instruments (due in large part to the work of the NASA Air Quality Applications program).
-* As the AQ Community begins to build the infrastructure and capacity to use this information, it is based on the current suite of EOS instruments and datasets – what continuity will there be with GEO-CAPE?
-* The AQ Community consists of a wide spectrum of users with different needs and different capabilities to access and use the data.
-* What lessons can be learned from the current applications of EOS data products regarding data availability, data coverage, data formats, data accessibility, and data
-quality?
-===Proposed Workshop Series on Satellite Observations in Air Quality Management ===
-* Engage a broader air quality management community: States, Academics, Private Sector Stakeholders
-* Opportunity for two-way communication between Air Quality and Satellite Communities
-* Not just about GEO-CAPE, but also about what can be done with the current stream of satellite observations.
-* Beginning of a longer-term process that we hope will continue as the mission develops and comes to fruition
-===GEOSS: A Technical Initiative ===
-GEOSS is built around a minimal central clearinghouse and other components of a Common Infrastructure. This GCI is not to house data or tools for using data – it is used to enable
-users to find that data.
-GEOSS registries are flexible enough to work with ‘any’ observation, so metadata will be less than needed for many users.
-Community catalogs and portals are response this a to need for a richer access point, tuned for a particular user community.
+== WCS Server Software for Grid and Point Data ==
-GEOSS is about decision support. The GCI won’t provide that. It is set up as a base for service oriented architecture which will in turn improve decision support.
+==== [[WCS Server StationPoint Data]] ====
-Architecture Implementation Pilot Output
+====[[WCS Server Cube Data]] ====
-AIP charge: produce ‘persistent exemplars’ to develop GEOSS
-Air Quality The AIP AQ work group is building an AQ community infrastructure to compliment the GCI
+====[[WCS Mediators and Clients|Mediators]] ====
-===Atmospheric Model Evaluation Network ===
-* Task DA-09-02d under Data Integration & Analysis
-** Use web services to compare global, regional models, including AQ models.
-** Apply various observations from distributed archives to evaluate & improve models.
-* Related international activities:
-** LRTAP Task Force on Hemispheric Transport of Air Pollution (TF HTAP)
-** IGAC-SPARC Atmospheric Chemistry & Climate initiative
-** AeroCom: International aerosol model - data comparison
-** Air Quality Model Evaluation International Initiative (AQMEII)
-*Related AMI activities:
-** Integration and Evaluation of Global Emissions Inventories in the NEISGEI Framework (06-66)
-** Remote Sensing Information Gateway (RSIG)
-** HTAP Data Network Pilot
-=== Future for EPA GEO Air Theme: Developing an Air Quality Cyberinfrastructure “Consortium” ===
-* Need a team capable of linking and extending the existing elements of the air quality information system to create a stable cyberinfrastructure (hardware, software, standards, organizations, …).
-* Expertise needed in
-** air quality forecasting and public information
-** air quality assessment or “re-analysis”
-** air quality model evaluation and intercomparison
-** emissions inventory development and evaluation
-** fire and smoke management
-** cyberinfrastructure development
-* Some Possible Tasks for the Consortium
-* Air Quality Information System Wiki
-** Identify functions, strengths, weaknesses of, and relationships between existing air quality information systems
-** Develop consensus guidelines
-* Air Quality Data Network Development
-** Establish a community data and service catalogue specific for air quality information, establish exchange standards for creating connections between existing elements of
-the air quality information system of systems, and implement such connections.
-* Air Quality Assessment Tools
-** Processing, visualization, and analytical tools for air quality assessment, or “reanalysis,” in which multiple types of observations and/or model estimates (drawn from across the air quality data network described above) are integrated to best describe the state of the atmosphere at a given point and time.
-* Air Quality Model Evaluation Tools
-** Tools that will enable modelers to compare regional and global model outputs in standard formats to a variety of types of observational data (drawn from across the air quality data network) and to perform standard tests and diagnostics.
-* Emissions Information and Tools
-** Building upon NEISGEI, EMF, and related systems.
-* Outreach and Coordination
-** Organize meetings and other outreach efforts to educate and communicate with the broader air quality management and research community
-===Opportunities for Constructive Engagement ===
-* EPA Working on Satellite Constructive Engagement Group Observations for Air Quality Management (and the NASA GEOCAPE Science and Air Quality Application Teams)
+== Clients Nodes and User Interfaces  ==
-* NARSTO Workshop Series on Use of Satellite Observations in Air Quality Management
+=== FZ Juelich ===
-* EPA Cyberinfrastructure for Air Quality Management (CyAir)
+=== DataFed ===
-* GEO Air Quality Community of Practice and the ESIP Air Quality Cluster
+=== NASA Giovanni ===