Skip to content

GSIP 24

Jody Garnett edited this page Jul 12, 2017 · 1 revision

GSIP 24 - TIME-ELEVATION-BAND parameters parsing for WMS 1.1.1 WCS 1.X

Overview

The goal of this work is the introduction of initial capabilities to coherently parse TIME - ELEVATION - BAND parameters for WMS  1.1.1 and WCS 1.x modules. Refactor of the WCS 1.0.0 module using EMF model in order to align it with the others GeoServer  service implementations and especially with WCS 1.1.1 is foreseen. Exploitation of the ISO 19108  Temporal Schema ongoing work from GeoTools will be exploited in order to correctly parse time requests.

Notice that this proposal is only for the updating of actual GeoServer services in order to make them able to parse time/band/elevation parameters, a necessary preliminary work to prepare GeoServer handling real N-D entities.  Motivation Proposal Backwards Compatability Feedback Voting Links

Proposed By

Alessio Fabiani Simone Giannecchini

Assigned to Release

1.7.x

State

Under Discussion (voting started)

Motivation

Motivations for this proposal are the following:

  • GeoServer services work in a pure 2D fashion, i.e. there is no way to parse time, elevation and (for WMS) band parameters. Since In the near future we would like to add to the GeoServer capabilities to eploit multidimensional (t,z,b,y,x) datasets,we need to teach it how to handle t/z/b params coming from requests.
  • The WCS 1.0.0 module on GeoServer needs to be aligned with the structure of others GeoServer services
  • WCS 1.0.0 and WCS 1.1.1 should be merged into a single WCS module

Proposal

The WCS 1.0.0 module works against an old design based on a series of custom servlets which grab the HTTP request from the clients and almost manually parse them, retrieve the needed parameters and build up the response eventually invoking an opportune delegate. XML-responses also are almost hard coded as a big StringBuffer sent back to the client.

The new design is based on a generic OWS dispatcher instead, and delegates the request parsing and the XML-responses production totally to the Eclipse Modelling Framework, which automatically performs validation against the original XSD schema provided by OGC.

The simplified diagrams below show a quick comparison between the two approaches:

image  Figure 1: WCS 1.0.0 now{_}

image  Figure 1: WCS 1.0.0 afterwards{_}

 Proposal summary

The proposal basically is comprised of four different parts:

  • Creation of  the WCS 1.0.0 EMF model and merge into the GeoTools net.opengis.wcs module.
  • Creation of WCS 1.0.0 and WCS 1.1.1 bindings and configuration as GeoTools xsd extension module.
  • Refactoring of the GeoServer WCS 1.0.0 request parsing subystem in order to align it with the WCS 1.1.1.
  • Merge of the GeoServer WCS 1.0.0 and WCS 1.1.1 modules.
How we will proceed

For the first two points of the proposal we will create EMF model and Bindings on a separate project as described in this article “GeoServer/GeoTools - Creating EMF Model and Bindings for new services.” ([http://www.geo-solutions.it/index.php?option=com_content&task=view&id=40&Itemid=41]) and test them with opportune test-cases.

Then we will create a branch of GeoServer 1.7.x and make sure that passes all the WCS 1.0.0 CITE Tests.

Finally we will come back to the mailing list and PMC proposing to port the changes on the official GeoServer 1.7.x and GeoServer trunk. \\

Feedback

This section should contain feedback provided by PSC members who may have a problem with the proposal.

Backwards Compatibility

The WCS 1.0.0 code will be refactored, however from the users point of view no changes should be visible; on the other side from the developers point of view the WCS 1.0.0 architecture will be aligned with the others GeoServer services.

Voting

Andrea Aime: +1 Alessio Fabiani: +1 Justin Deoliveira: +1

\Jody Garnett: +1 Saul Farber: Rob Atkinson: +1

Francesco Izzi: +1

Links

JIRA Task Email Discussion Wiki Page GeoServer/GeoTools - Creating EMF Model and Bindings for new services.

Clone this wiki locally