George Mason University (GMU) Center for Spatial ...csiss.gmu.edu/cesir/pdf/gmu_wcs_v2.pdf · George Mason University (GMU) Center for Spatial Information Science and Systems Organization

George Mason University (GMU) Center for Spatial Information Science and Systems

Organization (CSISS)

4400 University Drive, MSN 6E1

George Mason University Fairfax, VA 22030, USA

Telephone: +1-703-993-6114 Facsimile: +1-703-993-6127

Tutorial for Hosting Tropical Rainfall Measuring Mission (TRMM) data with

GMU CSISS Open-source OGC Web Coverage Service

Business POC Name: Liping Di Technical POC Name: Liping Di

Business POC email: [email protected] Technical POC email: [email protected]

Business POC phone: 703-993-6114 Technical POC phone: 703-993-6114

mailto:[email protected]

Content

1 GEOSS Introduction ..........................................................................................................................1 1.1 Overview of GEOSS.......................................................................................................................1 2 Introduction to the topic.....................................................................................................................3 2.1 Discussion of tutorial use................................................................................................................3 2.2 How interoperability is improved through WCS ............................................................................3 2.2.1 Gridded coverages interoperability problem................................................................................3 2.2.1.1 Coverage data model.................................................................................................................5 2.2.1.1.1 Domain Set ............................................................................................................................6 2.2.1.1.2 Range type .............................................................................................................................6 2.2.1.1.3 Range set................................................................................................................................7 2.2.1.2 Earth Observation Coverage type .............................................................................................7 2.2.1.2 Trimming a coverage ................................................................................................................8 2.2.1.3 Resampling a coverage .............................................................................................................8 2.2.1.4 Slice a coverage ........................................................................................................................8 2.2.2 The OGC-WCS Service interoperable interface ..........................................................................8 2.2.2.1 GetCapabilities Operation.........................................................................................................8 2.2.3.1.1 GetCapabilities request ..........................................................................................................8 2.2.3.1.2 GetCapabilities response......................................................................................................10 2.2.2.2 DescribeCoverage Operation ..................................................................................................10 2.2.2.2.1 DescribeCoverage Request ..................................................................................................10 2.2.2.2.2 DescribeCoverage Response................................................................................................11 2.2.2.3 DescribeEOCoverageSet Operation........................................................................................12 2.2.2.3.1 DescribeEOCoverageSet Request........................................................................................12 2.2.2.3.2 DescribeEOCoverageSet Response .....................................................................................13 2.2.2.4 GetCoverage Request..............................................................................................................14 2.2.2.4.1 GetCoverage request............................................................................................................14 2.2.2.4.2 GetCoverage Response ........................................................................................................16 2.2.2.4. Exception Handling ...............................................................................................................17 3 Use Cases.........................................................................................................................................19 3.1 Introduction of use case ................................................................................................................19 3. 2 Description of use case ................................................................................................................19 3.3 Details of use case.........................................................................................................................19 3.3.1 Case 1: How to install GMU WCS package? ............................................................................19 3.3.2 Case 2: How to configure GMU WCS to support TRMM data? ...............................................21 3.2.3 Case 3: How to extend GMU WCS to support other data type?................................................25 3.3.4 Case 4: How to register WCS to GEOSS CSR system? ............................................................25 Appendix A: Glossary/Acronyms .......................................................................................................31 Appendix B: Summary of Important Links ........................................................................................31

GMU Web Coverage Service Tutorial – V1

1 GEOSS Introduction

1.1 Overview of GEOSS

The Global Earth Observation System of Systems will provide decision-support tools to a wide variety of users. As with the Internet, GEOSS will be a global and flexible network of content providers allowing decision makers to access an extraordinary range of information at their desk.

This ‘system of systems’ will proactively link together existing and planned observing systems around the world and support the development of new systems where gaps currently exist. It will promote common technical standards so that data from the thousands of different instruments can be combined into coherent data sets. The ‘GEOPortal’ offers a single Internet access point for users seeking data, imagery and analytical software packages relevant to all parts of the globe. It connects users to existing data bases and portals and provides reliable, up-to-date and user friendly information – vital for the work of decision makers, planners and emergency managers. For users with limited or no access to the Internet, similar information is available via the ‘GEONETCast’ network of telecommunication satellites.

1


Fig. 1-1 Societal Benefit Area (SBA) of GEOS

The Global Earth Observation System of Systems (Fig. 1) is simultaneously addressing nine areas of critical importance to people and society. It aims to empower the international community to protect itself against natural and human-induced disasters, understand the environmental sources of health hazards, manage energy resources, respond to climate change and its impacts, safeguard water resources, improve weather forecasts, manage ecosystems, promote sustainable agriculture and conserve biodiversity. GEOSS coordinates a multitude of complex and interrelated issues simultaneously. This cross-cutting approach avoids unnecessary duplication, encourages synergies between systems and ensures substantial economic, societal and environmental benefits.

2


2 Introduction to the topic

2.1 Discussion of tutorial use

This tutorial is used to introduce how to work with GMU WCS open-source package to provide the cutomization fuctionality for Tropical Rainfall Measuring Mission (TRMM) data through OGC Web Covergae service interface. Some detailed use cases are provided.

2.2 How interoperability is improved through WCS

2.2.1 Gridded coverages interoperability problem

Formally, coverage is a feature that associates positions within a bounded space (its domain) to feature attribute values (its range). In other words, it is both a feature and a function. Commonly, coverage is a representation of a set of continuous variables (functions) in the space, measured following a particular geometric pattern defined by a geometric feature.

This definition might seam a bit too abstract. To make it more concrete, we are going to define continuous and discrete coverages.

When storing spatial distribution as variables as a mathematical function, then we say that we are dealing with a continuous coverage. Examples of a continuous coverage are a statistical trend surface, a mathematical description of a climate change model, etc. In this tutorial we are not going to deal with this kind of coverages.

Functions representing continuous attribute values generate an unlimited number of attribute values in the space, these can not be stored in a computer system, and a common approach for a coverage representation is to capture sampled values of this attributes following a sequence of positions. By doing this, we are generating a discrete coverage. Examples of this kind of coverages are satellite images, triangular irregular networks (TIN) and raster digital elevation models (DEM).

3


The limits between these two kinds of coverages are not completely clear. On one hard, a discrete coverage can be used to sample values on a continuous coverage. And on the other hand, discrete values on discrete coverages can be extrapolated by interpolation algorisms, and thus giving the impression of a continuous description of the space. E.g. the values of the 3 vertices of a particular triangle of a TIN, can be interpolated to get a value in any position inside this triangle.

A particular case of discrete coverages is a regular spaced grid of values. WCS standard focuses on an interoperable way of sharing regular grids in 0, 1, 2 or 3 axes, which define regular spaced locations in the domain. For each location in the domain, a single attribute value (e.g elevation), a set of values (e.g temperature, pressure, humidity, etc) or a vector of discrete samples of a function (e.g. the brightness values in different parts of the electromagnetic spectrum) will be provided.

A WCS can serve that coverage as a whole at the exact resolution of the coverage, or it can also serve a fragment of it, and optionally, it can resample the data. It is also able of subsetting the data, as well as educing the number of dimensions.

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 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 (e.g. point, lines, polygons…), the Web Coverage Service returns coverages representing space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties.

4


2.2.1.1 Coverage data model

The GML Application Schema for Coverages (09-146r1) defines the data model of a coverage based on the idea that a coverage can be seen as a set of positions in space (called domain), a type of measure made for this positions (called range type) and the measures themselves (called range set). Usually conventional coverage files (image files) are focused on the range set, providing an array of binary values, limiting the information on the range type to the value type, while limiting the information on the domain to the number of rows and columns of the image. Moreover, each image format has its own way to express theses information (generally included in the header of the file). This is the case of the basic tiff format and the jpeg2000 format.

The coverage model (Fig. 1-1) used in WCS includes more information. We are going to use the WCS 2.0 model to better illustrate these 3 concepts. The WCS developer needs to be aware that not all versions of WCS have the division as explicit as WCS 2.0, but they all have the same principles.

class GML 3.2.1 Application Schema for Cov erages

«FeatureType»Coverage

AbstractFeatureType

«FeatureType»GML::Feature

«Union»GML::DomainSet

«Union»GML::RangeSet

This component is inherited and only listed for the reader's convenience; its substructure is omitted here.GML 3.2 is the namespace of GML 3.2.1 [OGC 07-036].

This component is inherited and only l isted for the reader's convenience; its substructure is omitted here.GML 3.2 is the namespace of GML 3.2.1 [OGC 07-036].

DataRecord is defined in SWE Common 2.0 [OGC 08-094];its substructure is omitted here.

«type»SWE Common::DataRecord

1rangeSet

1

1domainSet

1

1rangeType

1

Fig. 1-1 Application schema for GML coverage model

5


2.2.1.1.1 Domain Set

In the domain set is where the dimensions of the coverage (spatial, temporal, etc) have to be defined. For example, a RectifiedGrid will have the size of the grid specified (which determines the number of rows and columns), as well as specifications on the point of origin of the grid, and the offset vector of the cells of the grid (allowing the grid to have a rotated orientation versus the real coordinates; this property is rarely used). This is an example of a domain set <gml:domainSet> <gml:RectifiedGrid dimension="2"> <gml:limits> <gml:GridEnvelope> <gml:low>0 0</gml:low> <gml:high>640 480</gml:high> </gml:GridEnvelope> </gml:limits> <gml:axisLabels>x y</gml:axisLabels> <gml:origin> <gml:Point gml:id="origin" srsName="urn:x-ogc:def:crs:EPSG:6.6:23031"> <gml:pos>344323.66 4716647.00</gml:pos> </gml:Point> </gml:origin> <gml:offsetVector srsName="urn:x-ogc:def:crs:EPSG:6.6:23031">0.5 0</gml:offsetVector> <gml:offsetVector srsName="urn:x-ogc:def:crs:EPSG:6.6:23031">0 -0.5</gml:offsetVector> </gml:RectifiedGrid> </gml:domainSet>

Fig. 2-2 Coverage domain set example

2.2.1.1.2 Range type

The range type, defines the name and description of the property that is held, the limits of the possible values, the number of significant figures, the units, the null value support, etc.

This is an example of a range type: <rangeType> <swe:field name="white"> <swe:Quantity definition="http://opengis.net/def/property/OGC/0/Radiance"> <gml:description>Panchromatic</gml:description> <gml:name>White</gml:name> <swe:nilValues> <swe:nilValue reason="http://www.opengis.net/def/nil/OGC/0/BelowDetectionRange"> 0 </swe:nilValue> <swe:nilValue

6


reason="http://www.opengis.net/def/nil/OGC/0/AboveDetectionRange"> 255 </swe:nilValue> </swe:nilValues> <swe:uom code="W/cm2"/> <swe:constraint> <swe:AllowedValues> <swe:interval>0 255</swe:interval> <swe:significantFigures>3</swe:significantFigures> </swe:AllowedValues> </swe:constraint> </swe:Quantity> </swe:field> </rangeType>

Fig. 2-3 Coverage range type example

2.2.1.1.3 Range set

In the range set, the actual values are transported or linked to the binary file that contains the values provided.

This is an example of a range set with the values embedded in GML: <gml:rangeSet> <DataBlock> <rangeParameters/> <tupleList> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </tupleList> </DataBlock> </gml:rangeSet>

Fig. 2-4 Coverage range type example

2.2.1.2 Earth Observation Coverage type

Based on OGC WCS Earth Observation Application Profile [OGC 10-140], there are three EO coverage type: Dataset, Stitched Mosaic and Dataset Series, which are defined as follows:

A Dataset is a 2-D coverage with latitude and longitude axes, which can represent, for example, a hyperspectral satellite scene;

A Stitched Mosaic is a 2-D horizontal coverage which can refer to several co-referenced non-overlapping Datasets;

A Dataset Series is a collection of coverage; A Dataset Series can refer to any number of co-referenced Datasets and Stitched Mosaics.

The conceptual view of those three EO coverages is shown in Table 2-1.

7


Table 2-1 Conceptual view of EO Coverage

Dataset Coverage Mosaic Coverage DatasetSeries Coverage

2.2.1.2 Trimming a coverage

A WCS can serve a coverage at its full extend, but commonly, it will only serve a subset of it in response to a request when containing a bounding box.

2.2.1.3 Resampling a coverage

A WCS can serve coverage in its original resolution or can resample the cell size to any other value. When resampling, it is possible to request the interpolation method that fits best. WCS standard calls this characteristic a range subsetting.

2.2.1.4 Slice a coverage

Normally, a WCS can serve coverage in its original number of dimensions; the WCS 2.0 introduces the possibility of reducing the original dimension number of the coverage. E.g. this is useful to extract a 2D layer from 3D data.

2.2.2 The OGC-WCS Service interoperable interface

2.2.2.1 GetCapabilities Operation

2.2.3.1.1 GetCapabilities request

All OWS Common services are self-describing. In the case of WCS this

8


means that you are able to request enough information to the service, in order to know the service details, and thus formulate further request until getting the coverage data desired. The mandatory GetCapabilities operation allows WCS clients to retrieve service metadata and coverage brief description from a server. The response to a GetCapabilities request shall be an XML document containing service metadata about the server and the coverage information. Sample GetCapabilities URL is followed: http://geobrain.laits.gmu.edu/cgi-bin/ows8/wcseo?service=wcs&version=2.0&request=

getcapabilities

Without specifying the section parameters, WCS server will return all information in the response document. GMU WCS support the following four sections in capabilities: ServiceIdentification, ServiceProvider, OperationsMetadata, Contents. The meaning for each section is explained in the Table 2-2 of [OGC 07-067r2]. Table 2 lists the parameters for GMU WCS GetCapabilities operation.

Table 2-2 GMU WCS GetCapabilities request parameters

Parameter Description Value(s) M/O

service Requested service Fixed to "WCS" Mandatory

request Type of request Fixed to

"GetCapabilities"

Mandatory

version Version number Fixed to "2.0" Optional

sections Comma-separated

section names

ServiceIdentification,

ServiceProvider,

OperationsMetadata,

Contents

Optional

GMU WCS also support HTTP post method for GetCapabilities operation. The following figure is a GetCapabilities HTTP POST Request XML Example. <?xml version="1.0" encoding="UTF-8"?> <GetCapabilities xmlns="http://www.opengis.net/wcs/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wcs/2.0 http://schemas.opengis.net/wcs/2.0/wcsGetCoverage.xsd" service="WCS"> <owcs:Sections> <owcs:Section>ServiceProvider</owcs:Section> </owcs:Sections> </GetCapabilities>

Fig. 2-5 GetCapabilities HTTP POST request example

9


2.2.3.1.2 GetCapabilities response

The response to a correct GetCapabilities request is a capabilities document (also known as "OGC service metadata document". This is an XML document that has different sections that can be slightly different from one version to another, but where the general idea is maintained.

In the GMU WCS, GetCapabilities response document that uses all this sections will be examined one by one: <wcs:Capabilities version="2.0.0" xmlns=[...]> <ows:ServiceIdentification>[…]</ows:ServiceIdentification> <ows:ServiceProvider>[…]</ows:ServiceProvider> <ows:OperationsMetadata>[…]</ows:OperationsMetadata> <wcs:ServiceMetadata >[…]</wcs:ServiceMetadata> <wcs:Contents> <wcs:CoverageSummary>[…]</wcs:CoverageSummary> […] <wcseo:DatasetSeriesSummary>[…]</wcseo:DatasetSeriesSummary > […] </wcs:Contents> </wcs:Capabilities>

Fig. 2-6 GMU WCS Capabilities document structure

2.2.2.2 DescribeCoverage Operation

2.2.2.2.1 DescribeCoverage Request

The client needs to issue a DescribeCoverage request to obtain a full description of one or more Dataset coverage. The server responds to such a request with an XML document describing one or more coverage. Table 2-3 lists the parameters for GMU WCS DescribeCoverage operation.

Table 2-3 GMU WCS DescribeCoverage request parameters


service Requested

service

Fixed to "WCS" Mandatory

request Type of request Fixed to "GetCapabilities" Mandatory

version Version number Fixed to "2.0" Mandatory

coverageId valid identifier

of a Dataset or

Stiched Mosaic

coverage

Example:

MOD13C1.A2009241.005.2009261200123.hdf

Mandatory

10


GMU WCS also support HTTP post method for DescribeCoverage operation. The following is DescribeCoverage HTTP POST Request XML Example. <?xml version="1.0" encoding="UTF-8"?> <DescribeCoverage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcs="http://www.opengis.net/wcs/2.0" xmlns:gml="http://www.opengis.net/gml/3.2" xsi:schemaLocation="http://schemas.opengis.net/wcs/2.0 ../wcsAll.xsd" service="WCS" version="2.0.0"> <wcs:CoverageId>GLSDEM_n049e035.tif_dem</wcs:CoverageId> </DescribeCoverage>

Fig. 2-7 DescribeCoverage HTTP POST request example

2.2.2.2.2 DescribeCoverage Response

The response to a well formed DescribeCoverage request is a document describing the coverage generically. Versions previous to WCS 2.0 use its own type of document, but the version 2.0 introduces a new element named “gmlcov”. Sample KVP URL is followed:

http://geobrain.laits.gmu.edu/cgi-bin/ows8/wcseo?service=wcs&version=2.0&request

=describecoverage&coverageid=MOD13C1.A2007145.005.2007184062524.hdf

The structure of DescribeCoverage response XML document is shown in Figure 2-8: <wcs:CoverageDescriptions xmlns=[...]> <wcs:CoverageDescription> <gml:boundedBy>[…]</ gml: boundedBy> <wcs:CoverageId>[…]</ wcs:CoverageId> <wcs:ServiceParameters>[…]</wcs:ServiceParameters> <gml:domainSet>[...]</gml:domainSet> <gmlcov:rangeType>[…]</gmlcov:rangeType> <gmlcov:metadata>[…]</gmlcov:metadata > <wcseo: DatasetSeriesSummary>[…]</wcseo: DatasetSeriesSummary> <wcs:CoverageDescription> </ wcs:CoverageDescriptions>

Fig. 2-8 GMU WCS DescribeCoverage document structure The contents for each part in Fig. 2-8 are elaborated as follows.

• boundedBy element: Provide the spatial bounding box of specified EO Dataset coverage by adopting <gml: Envelope> element.

• CoverageId: the identifier of requested coverage, which also will be used in the next GetCoverage request.

• ServiceParameters: Indicate the coverage subtype: RectifiedDataset or ReferenceableDataset.

11


• domainSet: Provide the extent details of specified coverage by using GML elements, which include the width/height, axis, origin and resolution information.

• rangeType: Provide the field information contained in the specified coverage. The description, fill value and allowed values will be presented.

• metadata: Provide the details metadata information about the requested coverage, which adopts <wcseo: EOMetadata> element to convey temporal range, platform and sensor related information.

2.2.2.3 DescribeEOCoverageSet Operation

2.2.2.3.1 DescribeEOCoverageSet Request

In WCS 2.0 EOAP, a new operation is imported to handle EO DatasetSeries coverage type. Since one DatasetSeries coverage may contains time-series dataset, it’s logical for the user to pick out some interested dataset from the specified DatasetSeries coverage.

Based on WCS EOAP [OGC 10-140], a Dataset Series is an identifiable, query-able collection of EO Dataset Coverages. DatasetSeries refer to contain zero or more Datasets and/or Stitched Mosaics, which in turn can refer to Datasets.

To send the DescribeEOCoverageSet request, the user needs to get the DatasetSeries identifier from the response of GetCapabilities operation, and then using spatial and temporal filter parameter to narrow down the collection and get the interested Dataset coverage. Table 2-4 lists the parameters for EO WCS DescribeCoverage operation.

Table 2-4 GMU WCS DescribeEOCoverageSet request parameters


service Requested

service

Fixed to "WCS" Mandatory

request Type of

request

Fixed to "GetCapabilities" Mandatory

version Version

number

Fixed to "2.0" Mandatory

12


eoId using the eoId

of a

DatatsetSeries

Example:

MODIS_Vegetation_Indices_NDVI_16-Day_L3_Gl

obal_0.05Deg_Year_2009

Mandatory

subset Allows to

constrain the

request in

each

dimensions

and define

how these

parameters are

applied.

Spatial

trimming and

temporal

trimming are

included.

Example: Long,http://www.opengis.net/def/crs/EPS

G/0/4326(-120,-100)

Long,EPSG:4326(-120,-100)

Lat,http://www.opengis.net/def/crs/EPSG/0/4326(20,40)

Lat,EPSG:4326(20,40)

phenomenonTime("2009-01-01")

phenomenonTime("2009-01-01T12:12:00Z","2009-01-07")

Optional

2.2.2.3.2 DescribeEOCoverageSet Response

The response to a well formed DescribeEOCoverageSet request contains two major parts: one is the description about the DatasetSeries, and the others are the description of the matched Dataset. Sample URL is followed:


=describeeocoverageset&eoid=Global_MODIS_vegetation_indices_2009_16_Days_N

DVI&subset=Lat,http://www.opengis.net/def/crs/EPSG/0/4326(10,40)&subset=Long,

http://www.opengis.net/def/crs/EPSG/0/4326(-120,-90)&subset=phenomenonTime("2

009-09-15","2009-09-22")

The structure of DescribeEOCoverageSet response XML document is shown in Figure 2-9: <wcseo:EOCoverageSetDescription xmlns=[...]> <wcseo:DatasetSeriesDescriptions> <gml:boundedBy>[…]</ gml: boundedBy> <wcseo:DatasetSeriesId>[…]</wcseo:DatasetSeriesId> <gml:TimePeriod>[…]</gml:TimePeriod> </wcseo:DatasetSeriesDescriptions> <wcs:CoverageDescriptions> <gml:boundedBy>[…]</ gml: boundedBy>

13


<wcs:CoverageId>[…]</ wcs:CoverageId> <wcs:ServiceParameters>[…]</wcs:ServiceParameters> <gml:domainSet>[...]</gml:domainSet> <gmlcov:rangeType>[…]</gmlcov:rangeType> <gmlcov:metadata>[…]</gmlcov:metadata > </wcs:CoverageDescriptions> [...] </wcseo:EOCoverageSetDescription>

Fig. 2-9 GMU WCS DescribeEOCoverageSet document structure Notice the element <wcseo:DatasetSeriesDescriptions>, which provide

the brief information, such as spatial extent, temporal range and identifier, about the specified DatasetSeries coverage.

2.2.2.4 GetCoverage Request

2.2.2.4.1 GetCoverage request

This operation allows a client to request coverage comprised of selected range properties at a selected set of geographic locations. The server extracts the response data from the selected coverage, and encodes it in a known coverage format. The GetCoverage operation is normally run after GetCapabilities and DescribeCoverage operation responses have shown what requests are allowed and what data are available [OGC 07-067r5]. Sample GetCoverage request URL is followed:

http://geobrain.laits.gmu.edu/cgi-bin/ows8/wcseo?service=wcs&version=2.0&req

uest=getcoverage&coverageid=MOD13C1.A2009241.005.2009261200123.hdf&su

bset=Lat,http://www.opengis.net/def/crs/EPSG/0/4326(20,40)&subset=Long,http:/

/www.opengis.net/def/crs/EPSG/0/4326(-120,-100)&format=image/geotiff&width

=1000&height=1000

As to the EO WCS developed in GMU, Table 2-5 lists the acceptable parameters for GetCoverage request.

Table 2-5 GMU WCS GetCoverage request parameters


service Requested service Fixed to "WCS" Mandatory

request Type of request Fixed to "GetCapabilities" Mandatory

version Version number Fixed to "2.0" Mandatory

coverageId valid coverageID of a

Dataset/StichedMosaic

Example:

TRMM_Daily_Accumulated_Precipitation_

Mandatory

14


Year_2004

subset Trimming and (or)

slicing of coverage

dimension

Example: Long,EPSG:4326(-120,-100)

Lat,http://www.opengis.net/def/crs/EPSG/0/4326(20,40)

phenomenonTime("2009-01-01")

phenomenonTime("2009-01-01T12:12:00Z","2009-01-07")

Optional

format Requested format of

coverage to be

returned

Example: image/geotiff

image/jpeg2000

application/x-hdf4

application/x-netcdf

Mandatory

outputcrs CRS for the requested

output coverage

outputcrs=http://www.opengis.net/def/crs/EP

SG/0/32612

Optional

mediatype Coverage delivered

directly as image file

or enclosed in in GML

structure

mediatype=multipart/mixed Optional

size/resolution Specify the output

width/height or

resolution per axis.

Example: size=Long(20)

size=x(50)

resolution=long(0.01)

resolution=y(0.3)

Optional

store When store euqls to

true, the XML

documet which

contains output URL

will be returned.

Default is false.

store=true Optional

interpolation Interpolation method

to be used

nearest(default)

bilinear

cubic

cubicspline

lanczos

Optional

15


2.2.2.4.2 GetCoverage Response

Here is where we really see the difference between a WMS and a WCS. Although both requests syntax are very similar and the response can even be in the same format, we will explain a particular case to illustrate where these two servers differ. Let’s suppose a population data, data is presented in persons per km2. This data can not be represented in an integer format so a WCS will return a GeoTIFF that includes floating data. This is a variant of tiff which is not supported by many common image viewers, so e.g. cannot be previewed by the windows operating system common tools. On the other hand, a WMS will return an image in a tiff format but in a way that is ready to be represented on the screen. This will result in an image of 255 color degrees specified in an internal palette. It will be easier to see in common image viewers; the values in the actual cells will no longer represent a physical magnitude but a color index. Additionally, the WMS returned image will not be useful for GIS population related analysis but the returned image from a WCS will.

Depends on the request parameters, GMU WCS will return the GetCoverage response in different way. If the “store” option is specified to true, GMU WCS will return the URL link of the result data. If the “mediatype” parameter is specified to “multipart/mixed”, GMU WCS will return the result data stream and come with metadata. If both “store” and “mediatype” parameter are not specified, GMU WCS will return the result file stream directly.

Sample GetCoverage request for TRMM data are followed: http://geobrain.laits.gmu.edu/cgi-bin/ows8/wcseo?service=wcs&version=2.0&request

=GetCoverage&CoverageID=TRMM_Daily_Accumulated_Precipitation_Year_2004

&subset=phenomenonTime("2004-08-01","2004-08-03")&format=image/geotiff

The request will request three days TRMM daily data from 2004-08-01 to 2004-08-03, and the customized format is GeoTIFF. The screenshot of returned file is shown in Fig. 2-10.

16


Fig. 2-10 Screenshot of GetCoverage response for TRMM data

2.2.2.4. Exception Handling

Sometimes the client does not provide a well formed supported request, or for some reason the service is not able to perform the requested task. Under these circumstances, the service will respond with an XML file that explains the origins of the problem.

To handle complex exception type, OGC defines the following exception and, some of them from WCS 1.X and some of them from WCS 2.0.

OperationNotSupported

MissingParameterValue

InvalidParameterValue

VersionNegotiationFailed

InvalidUpdateSequence

OptionNotSupported

NoApplicableCode

NoSuchCoverage

InvalidAxisLabel

InvalidSubsetting

Take GetCapabilities request as example, if the HTTP GET request contains “GetCapability” other than “GetCapabilities”, such as:


=getcapability

Then GMU WCS will throw an exception and report the contents to user

17


18

with an XML document, as follows: <?xml version="1.0" encoding="UTF-8"?> <ExceptionReport xmlns="http://www.opengis.net/ows" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ows/owsCommon.xsd" version="0.3.20" language="en"> <Exception exceptionCode="InvalidParameterValue" locator="WCS-GET-KVP"> <ExceptionText>Passed KVPs could not be parsed based on [OGC 09-147r1] extension.</ExceptionText> </Exception> </ExceptionReport>

Fig. 2-11 GMU WCS exception sample


19

3 Use Cases

3.1 Introduction of use case

GMU WCS is an OGC Web Coverage Service for Earth Observation data, which implements the OGC WCS 2.0 Interface Standard – Core, and WCS 2.0 Application Profile – Earth Observation specification. GMU WCS package is released under the Open License a MIT-style license and written in C++ programming language, and entirely based on Open Source software.

The use case of GMU WCS involves two aspects, show how to work with existing code framework and how to extend it to support more data types to the data provider, and also introduces how to use GMU WCS to customize data to data user.

3. 2 Description of use case

GMU WCS is based on multiple open-source libraries, such as GDAL, Proj.4 and hdfeos. Several data formats could be served through the released GMU WCS package.

The use case of GMU WCS package is used to show the scenario to design, develop and deploy an OGC Web Coverage Service for Earth Observation data, and also show how to customize data through standard WCS operation.

As to the data provider, the use case will show how to find and download GMU WCS open-source package and also introduce how to install, configure and deploy the GMU WCS. As to the data user, the use case also presents how to get and customize dataset.

3.3 Details of use case

3.3.1 Case 1: How to install GMU WCS package?

Step 1: Access the open-source GMU WCS package directory through the


20

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 Fig. 3-1 shown.

Fig. 3-1 GMU WCS Package

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


21

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.

4.1 Compile WCS20lib library. The path to header file and library path should be configured correctly in WCS20lib project.

4.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

4.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.

3.3.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. <wcs:Contents>


22

<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>

Fig. 3-2 Example of Contents.xml (2) dataset.xml: provide the detailed information for the Dataset coverage

to-be-served. XML segment are followed. <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>

Fig. 3-3 Example of dataset.xml 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. <WCSEODatasetSeries> <DatasetSeries> <DatasetSeriesId>TRMM_Daily_Accumulated_Precipitation_Year_2000_To_2010</DatasetSeriesId>


23

<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>

Fig. 3-4 Example of datasetSeries.xml 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.

Table 3-1 WCS Configuration Iterms

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


24

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 an interested 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. http://geobrain.laits.gmu.edu/ows8/wcseo/demo/wcseodemo.html


25

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: http://geobrain.laits.gmu.edu/ows8/wcseo/doc/

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.

3.3.4 Case 4: How to register WCS to GEOSS CSR system?

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

http://geobrain.laits.gmu.edu/ows8/wcseo/doc/

http://www.geossregistries.info/


26

Fig. 3-5 GEOSS CSR Portal

As shown in above figure 3-5, 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/geosspub/user_register.htm

Fig. 3-6 User Registration Page

Please remember that the user name is case-sensitive. GEO affiliation list contains member country, participating organization and observer group. If you

https://geossregistries.info/geosspub/user_register.htm

https://geossregistries.info/geosspub/user_register.htm


27

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.

Fig. 3-7 GEOSS Registry Publication Portal

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


28

Fig. 3-8 GEOSS Resource Registration Page

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.

Fig. 3-9 Basic Rgistration Information

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.


29

(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:

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.

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.

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.

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

http://www.earthobservations.org/geoss.shtml


30

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.

Fig. 3-10 Request for Approval

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.


31

Appendix A: Glossary/Acronyms

The following terms and definitions apply. Coverage: feature that acts as a function to return values from its range for any direct position within its spatiotemporal domain [OGC 07-111] GML coverage: feature which is a concrete subclass (specialization) of gmlcov:AbstractCoverage NOTE: The term “GML coverage” does not imply that such a coverage always needs to be represented by a GML document; a coverage can well be represented by some wellknown encoding different from GML as long as the data model contents is semantically equivalent. Offered coverage: extended →GML coverage structure, stored on a WCS server and accessible by clients via WCS operations, which additionally carries WCS service relevant information (Coverage) Subsetting: operation on →GML coverages which, for a coverage provided, extracts part or all of its cell/value pairs and returns a →GML coverage containing these cell/value pairs (Coverage) Trimming: GML coverage subsetting operation which returns a →coverage with the same number of dimensions as the input → GML coverage (Coverage) Slicing: GML coverage subsetting operation which returns a → GML coverage with a reduced number of dimensions as compared to the input → GML coverage

Appendix B: Summary of Important Links

http://www.opengeospatial.org/standards/wcs http://gdal.org/ http://hdfeos.org/ http://www.csiss.gmu.edu/

http://www.opengeospatial.org/standards/wcs

http://gdal.org/

http://hdfeos.org/

http://www.csiss.gmu.edu/

Documents

George Mason University (GMU) Center for Spatial ...csiss.gmu.edu/cesir/pdf/gmu_wcs_v2.pdf · George Mason University (GMU) Center for Spatial Information Science and Systems Organization