Air Quality Information System and GEOSS: India Air Quality and CATHALAC Applications

From Earth Science Information Partners (ESIP)

A Concept Proposal contains necessarily the following information to support the evaluation:

  1. project team leader’s name and contact information;
  2. implementing organizations and partners;
  3. initial description of project concept, including description of the decision or problem needing improvement and the application of Earth observations, data, or model products;
  4. intended beneficiaries and anticipated benefits and improvements;
  5. anticipated duration of project; and
  6. level of experience with Earth observations and type of assistance requested (if any).

These Concept Proposals are intended as a way to minimize initial efforts of project teams so that only projects of interest will prepare Full Proposals. However, the Concept Proposals need to contain sufficient information to enable the review panels’ evaluation and GEO support to the projects.

This section describes the main objectives of the project. It describes the proposed activities, technical approach, and methodology to apply Earth observations to improve the decision making. It describes efforts to transition results and ensure the sustained use of the Earth observations after the completion of the project.

CFP supports projects connecting the parts of this diagram to demonstrate societal benefits from Earth observations and GEOSS.
GEOSSUIC Diagram.png


Special focus on projects helping end users apply Earth observations, especially users in developing countries


Problem

Air quality data is normally created by a data provider for a particular mandated end user. The format of the data is specific to the use and the metadata that describe the data are focused on a certain application. More and more, the GEOSS idea is growing that ‘a single problem requires many datasets and a single dataset can serve many applications’ (Zhao, 2006). In order to access a dataset providers need to be able to publish and users need to be able to find and bind to a dataset of interest. Standardized data access services allow interoperability in binding to a dataset. However, the first two parts of publishing and finding a data access service are still problematic. In particular: (1) How does one describe the data access service so that it can be discovered by users? (2) Where does one publish their data access service so that it can be found?

FaninFanoutAQ.png

Architecture Implementation and Reuse

PUBLISH-FIND-BIND FLOW THROUGH GCI

Publish: Initially it was thought that if one “published” data on the web in any format that was enough for sharing. Then it became obvious that if you wanted to integrate datasets that standard data access formats were useful and publication meant that one exposed a standard data access service available on the web. Through the Pilot it became apparent that just exposing the data access service with a GetCapabilities document doesn’t provide enough metadata for discovery and additional standard metadata needs to be published by the provider or distributor for discovery of the service, so the AQ metadata record and AQ Community Catalog was created.

The services we initially registered for the Pilot are OGC WMS and WCS services and they have a GetCapabilities document which has some metadata information included and can be mapped to ISO 19115 fields (Nativi, 2008). To further improve the use of GetCapabilities documents for metadata creation, we organized our data access services by dataset, so that the general metadata information was dataset specific and the coverages were each dataset parameter. Only a handful of additional fields are needed to create a valid metadata record and these can be hard coded or entered at the time or registration.

Figure X. shows the flow of metadata. Starting with the service provider, the GetCapabilities document is used to create an ISO 19115 metadata record for the data access service. The xml document is saved into the community catalog. The community catalog is registered as a component in the GEOSS Component and Service Registry (CSR). The GEOSS Clearinghouses query the GEOSS CSR for catalogs and then harvest the catalogs for their metadata records, ending the metadata publishing process.


PublishFindBind.png
Figure X. Publish-Find-Bind process for data access services from service provider to service user


Find: In order to find the data access services in the clearinghouse one has to know what to search for. The clearinghouse queryable fields and metadata fields were mapped in a crosswalk to clarify how information was extracted from the harvested metadata records. The key queries we have been interested in so far are for finding our own records, through the parent identifier and searching for services by type and keyword.

The ESRI and USGS clearinghouses expose a search API which has enabled the AQ group to create a more customized search interfaces. One example interface that we have set up is using the USGS API and searching full text in order to find WMS or WCS services (Ref link).

Bind: Once the user has found the dataset of interest the next step is to bind to the dataset (Fig. 2) and display the data access service through the tool of choice. Each service is described in the metadata record with its GetCapabilities URL. Through preliminary testing with WMS services, the Compusult Clearinghouse is able to bind to the GetCapabilities URL found in the metadata record and display a WMS instance of the map.

Application in India

Application for CATHALAC