wiki:PetascopeUserGuide

Version 4 (modified by pbaumann, 7 years ago) (diff)

--

Petascope User guide

Petascope is implemented as a war file of servlets which give access to coverages (in the OGC sense) stored in rasdaman.

Internally, incoming requests requiring coverage evaluation are translated into rasql queries by petascope. These queries are passed on to rasdaman, which constitutes the central workhorse. Results returned from rasdaman are forwarded to the client, finally.

For this purpose, petascope needs additional metadata (such as georeferencing) which is maintained in separate relational tables. Note that not all rasdaman raster objects and collections are available through petascope by default; rather, they need to be registered through the petascope administration interface.

For installation, this war file needs to be deployed and configured for use with some rasdaman server installation. See the installation section? for details.

Currently, petascope offers interfaces according to WCS 1.1, WCPS 1.0, WCS-T 1.4, and WPS 1.0. These are described below.

The WCPS Standard

WCPS

The OGC Web Coverage Processing Service (WCPS) defines a language for retrieval and processing of multi-dimensional geospatial coverages representing sensor, image, or statistics data. Services implementing this language provide access to original or derived sets of geospatial coverage information, in forms that are useful for client-side rendering, input into scientific models, and other client applications. WCPS relies on the coverage model as defined in OGC Abstract Specification Topic 6 “Schema for Coverage Geometry and Functions “ [OGC 07-011] and the OGC Web Coverage Service (WCS) Standard [OGC 07-067r5] where coverages are defined as “digital geospatial information representing space-varying phenomena”, in WCS currently constrained to equally spaced grids.

The WCPS language is independent from any particular request and response encoding, as no concrete request/response protocol is specified by WCPS. For setting up a WCPS instance, therefore, a separate, additional specification establishing the concrete protocol is required. This allows embedding of WCPS into different target service frameworks. One such target framework is OGC WCS. Together with the pertaining request type definition [OGC 08-059r3] WCPS forms an extension of the Web Coverage Service (WCS) version 1.1.2 Standard [OGC 07-067r5]. With small changes, this extension is expected to also apply to subsequent versions of WCS. Another target framework is the OGC Web Processing Service (WPS) standard [OGC 05-007r7]. WPS defines a generic framework for XML-RPC based submission of processing requests. WCPS represents one particular service type, namely one that accepts requests expressed in the WCPS language for execution on coverages stored server side. Further, discussion about a linkage of WCPS with the OGC Sensor Web Enablement (SWE) has been initiated.

The following documents are relevant for WCPS; they can be downloaded from www.opengeospatial.org/standards/wcps:

  • OGC 08-068r2: The protocol-independent ("abstract") syntax definition; this is the core document. Document type: IS (Interface Standard.
  • OGC 08-059r3: This document defines the embedding of WCPS into WCS by specifying a concrete protocol which adds an optional ProcessCoverages? request type to WCS. Document type: IS (Interface Standard.
  • OGC 09-045: This draft document defines the embedding of WCPS into WPS as an application profile by specifying a concrete subtype of the Execute request type.

Schemas:

  • The XML schema of the WCS Processing Extension (OGC 08-059r3) is schemas.opengis.net/wcps/.
  • The XML schema of WCPS as a WPS application profile is under development.

(see also WCPS manual and tutorial)

The WCPS service can handle most of the operations specified in the WCPS specification document. It can answer both XML and Abstract Syntax queries. The servlet will always respond to a GET request with a user friendly form for entering a query along with a greeting message. To send a query a post request must be sent. Two protocols are supported, XML (with two sub-variants) and Abstract Syntax:

  • To send a abstract syntax request: A post request must be sent. The query string must be sent in a post parameter named query.
  • To send a request as a XML file, a multi-part post request must be sent. Only one file must be sent. The Mime type has to be text/xml.
  • To send a request as XML: A post request must be sent. A post parameter named xml must be attached.

If you intend to implement forms-based access:

To obtain a proper query from an XML page a form must be used. The method should be post and action should be an URL pointing to the servlet access point. The form should contain either a file field or a text/hidden field that has the name xml or query. An error in the access method will generate the same user friendly form and greeting message as for the GET request. For a simple example check the reply you get from accessing the service check the user friendly form obtained by a GET request.

WCS

See the WCS standards for the moment being; further documentation to come.

Attachments (1)

Download all attachments as: .zip