George Mason University (GMU) Center for Spatial ...csiss.gmu.edu/cesir/pdf/gmu_wcs_v2.pdf ·...
Transcript of 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 (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
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
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" Mandatory
coverageId valid identifier
of a Dataset or
Stiched Mosaic
coverage
Example:
MOD13C1.A2009241.005.2009261200123.hdf
Mandatory
10
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
• 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
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" Mandatory
12
GMU Web Coverage Service Tutorial – V1
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:
http://geobrain.laits.gmu.edu/cgi-bin/ows8/wcseo?service=wcs&version=2.0&request
=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
GMU Web Coverage Service Tutorial – V1
<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
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" Mandatory
coverageId valid coverageID of a
Dataset/StichedMosaic
Example:
TRMM_Daily_Accumulated_Precipitation_
Mandatory
14
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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:
http://geobrain.laits.gmu.edu/cgi-bin/ows8/wcseo?service=wcs&version=2.0&request
=getcapability
Then GMU WCS will throw an exception and report the contents to user
17
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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>
GMU Web Coverage Service Tutorial – V1
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>
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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/
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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.
GMU Web Coverage Service Tutorial – V1
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.
GMU Web Coverage Service Tutorial – V1
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
GMU Web Coverage Service Tutorial – V1
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.
GMU Web Coverage Service Tutorial – V1
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/