GEOSS Banner

4.3.2: TRMM Precipitation Data with GMU


4.3.2.1 Step 1: Case 1: How to install GMU WCS package?

4.3.2.2 Step 2: Case 2: How to configure GMU WCS to support TRMM data?

4.3.2.3 Step 3: Case 3: How to extend GMU WCS to support other data type?

4.3.2.4 Step 4: Case 4: How to register GMU WCS to GEOSS CSR system?

 

<<Prev T.O.C Next>>

4.3.2.1 Case 1: How to install GMU WCS package?

Step 1: Access the open-source GMU WCS package directory through the following link (no password or authorization required):
http://geobrain.laits.gmu.edu/ows8/wcseo/code/
Select the latest version and save it to local machine. Currently only “gmu_eowcs_v0.1.tar.gz” is released, the following version will be posted once the OGC designed and released new extension for Earth Observation Application Profile.
After the download operation, uncompress the package (.tar.gz) with proper software. Three folders are contained in GMU WCS package, as the following figure shown.

source_code_tree.JPG

Step 2: Install a software development tools for C/C++ programming language. On most platforms, Eclipse CDT will be working, Microsoft visual studio is recommended on Windows platform.
Step 3: Install the required libraries to developing server. Generally GDAL library, HDF-EOS library, HDF4 and HDF5 library are required to handle most NASA data granule. Proj.4 library are also needed to re-project the coverage. In order to serve NetCDF data, netcdf library is also required to install. The following command is an example used to compile GDAL library:

./configure --prefix=/opt/local --enable-debug --with-png=internal --with-libtiff=internal --with-geotiff=internal --with-jpeg=internal --with-gif=internal --with-libz=internal --with-hdf4=/opt/local --with-hdf5=/opt/local --with-netcdf=/opt/local --with-expat=/opt/local --with-jasper=/opt/local --with-xerces=/opt/local --without-pam --with-threads --with-curl=/opt/local/bin/curl-config --with-geos=/opt/local/bin/geos-config --with-static-proj4=/opt/local


After install GDAL, the user could test it with “gdalinfo” utility command to parse one TRMM data.
Step 4: Create two projects for GMU WCS, one is WCS20lib, the other is WCS20. Copy the source code to its related project. Suppose the developing platform in Fedora 12 Operating System.
(1) Compile WCS20lib library. The path to header file and library path should be configured correctly in WCS20lib project. (2) Copy the generated WCS20lib library file (such as wcs20lib.a), which under the “Release” and “Debug” directory, to the directory “/usr/local/lib”. And then in order to generate index to archive for WCS20lib, run the following command:

ranlib /usr/local/lib/wcs20lib.a


(3) Compile WCS20 project. Please configure the path of required libraries are set up correctly. If everything goes well, an executable file will be generated under the “Release” and “Debug” folder of WCS20 project.

4.3.2.2 Case 2: How to configure GMU WCS to support TRMM data?

Step 1: Modify the template files under “conf” folder accordingly. In order to improve the performance of GMU WCS, the spatial and temporal information are parsed and recorded in related template file through pro-processing. The contents for each template file are explained as follows:
(1) Contents.xml: provides the basic information about served Dataset and DatasetSeries coverage, which will be displayed if the user request GetCapabilities operation. Sample XML segment are followed.

st1\:*{behavior:url(#ieooui) }

<wcs:Contents>

<wcs:CoverageSummary>

<wcs:CoverageId>MOD13C1.A2007145.005.hdf</wcs:CoverageId>

<wcs:CoverageSubtype>RectifiedDataset</wcs:CoverageSubtype>

</wcs:CoverageSummary>

<wcseo:DatasetSeriesSummary>

<wcseo:DatasetSeriesId>Global_MODIS_vegetation_indices_2010_16_Days_NDVI</wcseo:DatasetSeriesId>

<ows:WGS84BoundingBox>

<ows:LowerCorner>-180 -90</ows:LowerCorner>

<ows:UpperCorner>180 90</ows:UpperCorner>

</ows:WGS84BoundingBox>

<gml:TimePeriod>

<gml:beginPosition>2010-09-14T00:00:00Z</gml:beginPosition>

<gml:endPosition>2010-10-31T23:59:59Z</gml:endPosition>

</gml:TimePeriod>

</wcseo:DatasetSeriesSummary>

</wcs:Contents>

(2) dataset.xml: provide the detailed information for the Dataset coverage to-be-served. XML segment are followed.

 

st1\:*{behavior:url(#ieooui) }

<Datasets>

<Dataset>

<name>TRMM_Daily_Accumulated_Precipitation_Year_2000</name>

<path>/TRMM_3B42_daily.2000.hdf</path>

<coverageID>TRMM:TRMM_3B42_daily.2000.hdf:Daily</coverageID>

<west>-180.0</west>

<east>180.0</east>

<south>-50.0</south>

<north>50.0</north>

<beginTime>2000-06-01T00:00:00Z</beginTime>

<endTime>2000-12-31T23:59:59Z</endTime>

</Dataset>

[...]

</Datasets>

 The "name" element is used to present the coverage identifier to user, which can be assigned a meaningful name.
The "path" element is used to indicate the path for the coverage.
The "coverageID" element is used to maintain an internal coverage identifier, GMU WCS will call the proper data processing class by this internal identifier.
The "west", "east", "south" and "north" elements are used to indicate the spatial extent of the coverage. Please remember that those coordinates use WGS84 Lat/Lon coordinate system.
The "beginTime" and "endTime" are used to indicate the temporal range, which adopts the format "yyyy-MM-ddTHH:mm:ssZ".
(3) datasetSeries.xml: provide the detailed information for the DatasetSeries coverage to-be-served. Sample XML segment are followed.

st1\:*{behavior:url(#ieooui) }

<WCSEODatasetSeries>

<DatasetSeries>

<DatasetSeriesId>TRMM_Daily_Accumulated_Precipitation_Year_2000_To_2010</DatasetSeriesId>

<Datasets>

<Dataset>

<name>TRMM_Daily_Accumulated_Precipitation_Year_2000</name>

<path>/TRMM_3B42_daily.2000.hdf</path>

<coverageID>TRMM:/TRMM_3B42_daily.2000.hdf:Daily</coverageID>

<west>-180.0</west>

<east>180.0</east>

<south>-50.0</south>

<north>50.0</north>

<beginTime>2000-06-01T00:00:00Z</beginTime>

<endTime>2000-12-31T23:59:59Z</endTime>

</Dataset>

[...]

</Datasets>

[...]

</DatasetSeries>

</WCSEODatasetSeries>

 The "DatasetSeriesId" element is used to present the DatasetSeries coverage identifier to user, which also can be assigned a meaningful name.
Please notice that one "DatasetSeries" element could contain multiple "Datasets", and one "WCSEODatasetSeries" element also could contain multiple "DatasetSeries" in one configuration file.
(4) ServiceProvider.xml: provides the service provider contact information. The WCS developer should modify this part accordingly.
(5) ServiceIdentification.xml: provides the service identifier and related keywords and used profiles. The WCS developer should change the service identifier.
(6) OperationsMetadata.xml: provdes the metadata for WCS operation. The WCS developer should change the WCS access URL accordingly.

Step 2: Create a new file under the same directory as WCS executable, with the extension name “.conf”, such as “wcseo.conf”. This WCS configuration file contains the following items.

Parameter name

Contents

CAPABILITIES_HEAD_FILE_PATH

The path of capabilities XML head document

CAPABILITIES_SEVICEIDENTIFICATION_FILE_PATH

The path of WCS service identification XML document

CAPABILITIES_SEVICEPROVIDER_FILE_PATH

The path of service provider XML document

CAPABILITIES_OPERATIONSMETADA_FILE_PATH

The path of WCS operation metadata XML document

CAPABILITIES_CONTENTS_FILE_PATH

The path of WCS coverage contents XML document

SERVICE_ACCESS_URL

The access URL for released WCS

DATASET_CONFIGRATION_FILE_PATH

The path of Dataset coverage configuration files, multiple path could be separated with comma

STITCHED_MOSAIC_CONFIGRATION_FILE_PATH

The path of Mosaic coverage configuration files (NOT supported in this version)

DATASET_SERIES_CONFIGRATION_FILE_PATH

The path of DatasetSeries coverage configuration files, multiple path could be separated with comma

ISO_19115_METADATA_TEMPLATE_PATH

The path of ISO 19115 metadata template, which will be used to describe WCS output file

TRANSACTION_DATA_DIRECTORY

The directory for storing the transaction data (NOT supported in this version)

TEMPORARY_OUTPUT_DIRECTORY

Temporary directory for intermediate and output data

OUTPUT_PREFIX_URL

The URL prefix corresponding to temporary directory, which could be set in Apache’s configuration file

WCS_LOGFILE_PATH

The path of WCS log file

GDAL_WARP_PATH

The path of gdalwarp, which is used to warp the dataset based on user specified request (WILL be discarded in next version)

 

Step 3: Deploy the WCS executable file and its corresponding configuration file to Apache HTTP server. Start the Apache server and issue a GetCapabilities operation to validate everything goes well. If the capabilities document could be returned correctly, select one coverage and build a GetCoverage request with proper parameters, send it to WCS server, it the result return correctly, which stands for GMU WCS have been configured and deployed well. 
The following web page contains the information about how to specify WCS parameters in details.

 

4.3.2.3 Case 3: How to extend GMU WCS to support other data type?

Step 1: Install GMU WCS and configure it correctly based on use case 1 and use case 2.
Step 2: Extend a new class from AbstractDataset class in WCS20lib package, and fulfill the following methods:
    virtual CPLErr SetMetaDataList(GDALDataset* );
    virtual CPLErr SetNativeCRS();
    virtual CPLErr SetGeoTransform();
    virtual CPLErr SetGDALDataset(const int isSimple=0);
    virtual CPLErr InitialDataset(const int isSimple=0);
The description for each dataset could be found at:

Step 3: Modify “wcstdsinc.h” in WCS20lib package, add the header file name.
Step 4: Compile the WCS20lib project, copy the generated WCS20lib library file to the directory “/usr/local/lib”, and the following command again:

ranlib /usr/local/wcs20lib.a

Step 5: Modify the method “WCSTCreateDataset” in “WCS_T.cpp” file in WCS20 package, based on the coverage identifier indicator, to instantiate an AbstractDataset object.
Step 6: Compile the WCS20 project, and get the executable WCS file under Debug/Release directory. Copy the generated executable file into the cgi-bin directory of Apache HTTP server.
Step 7: Create the configuration file for the dataset or dataset series need to be served, and modify the wcs.conf accordingly.
Step 8: Run GetCapabilities request to test.

4.3.2.4 Case 4: How to register GMU WCS to GEOSS CSR system?

Step 1: Access GEOSS CSR portal through the following link
http://www.geossregistries.info/

geoss_csr_index.JPG

As shown in above figure, select [Registration] menu and go to registration page.  

Step 2: Log in with register user account, or create an account through the following link

https://geossregistries.info/geosspu...r_register.htm

geoss_csr_user_account.JPG

Please remember that the user name is case-sensitive. GEO affiliation list contains member country, participating organization and observer group. If you did not belong to any of those items, please select “Not a GEO member or Participating Organization” option. Finish the required fields and click [Register] button.

Step 3: Go to GEOSS Registry Publication Portal, screenshot is followed.

geoss_csr_publication_portal.JPG

By clicking the [Contribute Earth Observation (EO) Resources to GEOSS] button, the page will be redirected to GEOSS Resource Registration page. 

geoss_csr_resource_registration.JPG

Specify the resource category to “Service Interfaces” from the dropdown list on the top of this page. Fill in the left part, which include service name, description, and service access URL, contact information, service spatial and temporal information, and standards related information. 
(1) Basic Information: enable the user to fill in the basic information about the WCS to be registered, which include resource name, abbreviation and description.

geoss_csr_resource_affiliation.JPG

CSR also provide a tree structure of GEO affiliation of the contributing organization, which is a multiple choice list, the user should select the proper nodes and click the [Select this GEO Affiliation] button.
(2) Resource Contact Information: Enable the owner of WCS to specify contact information. The user could assign other person as the contactor.
(3) Societal Benefit Areas: Enable the user to select the SBA from nine checkboxes. It's a multiple choice selection. Details about those SBAs are available on GEOSS web site:
http://www.earthobservations.org/geoss.shtml
(4) Resource Availability: Enable users to specify the resource availability. Three single choice options are provided.
(5) GEOSS Data-Core: Enable users to specify GEOSS Data-Core attributes. Four multiple choices are provided, as follows:

  • 1) GEOSS Data-Core(geossDataCore): The GEOSS Data Collection of Open Resources for Everyone is a distributed pool of documented datasets, contributed by the GEO community on the basis of full and open exchange (at no more than the cost of reproduction and distribution) and unrestricted access. The GEOSS Data-CORE is intended to address GEO societal Benefit Areas. The requirement from a data provider of user registration and/or attribution of the data source should not in itself be considered a restriction.
  • 2) User registration (geossUserRegistration): The process by which a data user registers at a data provider's site in order to gain future access to the data provided. Future access requires a login that is authenticated against the information provided during user registration.
  • 3) Attribution (geossAttribution): The process of using metadata to allow data users to become aware of the source of the data being accessed and used, and to provide appropriate identification or citation.
  • 4) No monetary charge (geossNoMonetaryCharge): at no more than the cost of reproduction and distribution (The cost that a data provider incurs in order to make a single request for data possible.  This is typically meant to cover situations where physical media are used to store the data, and postal and parcel services are used to ship and deliver the data to the recipient that had requested it.  These costs are not typically meant to be used to cover data available online. Additionally, these costs are not meant to include cost recovery for creating an infrastructure that makes the data available).

(6) Ontology Reference: CSR adopts GEOSS Earth Observation Vocabulary (version 1.0), which provides 11 major categories to describe the resource to-be-registered.  The user should select the proper items from this multiple choice list.
(7) Standards/Special Arrangements Reference Information: Enable the user to select the     classification information and supportive information from two lists. They’re multiple choice list.
After finish the service registration forms, notice there is one check box on the bottom of this page, if checked this box and click [Register the Resource], you’re sending out a “Request for Approval” to GEOSS CSR record review working group.

geoss_csr_publication_approval.JPG

Step 3: After the registration, the user will receive a confirmation email about this resource. As to the approve status, CSR team will contact with the owner of this resource if by email if they’re have some concerns. If there is no concern about the registered resource, an approval confirmation email will be sent to the user 
Step 4: CSR also provide the search, modify and delete functionality for the registered resource.

 

 

 

<<Prev T.O.C Next>>

Tag
none

Files (0)

 
You must login to post a comment.