This page last changed on May 30, 2011 by aaime.


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. 
Backwards Compatability

Proposed By

Alessio Fabiani

Simone Giannecchini

Assigned to Release



Under Discussion (voting started)


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


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:

 Figure 1: WCS 1.0.0 now

 Figure 1: WCS 1.0.0 afterwards

 Proposal summary

The proposal basically is comprised of four different parts:

  1. Creation of  the WCS 1.0.0 EMF model and merge into the GeoTools net.opengis.wcs module.
  2. Creation of WCS 1.0.0 and WCS 1.1.1 bindings and configuration as GeoTools xsd extension module.
  3. Refactoring of the GeoServer WCS 1.0.0 request parsing subystem in order to align it with the WCS 1.1.1.
  4. 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." ( 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.


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.


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

~jgarnett: +1
Rob Atkinson: +1

Francesco Izzi: +1


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

WCS-NOW.jpg (image/jpeg)
WCS-AFTER.jpg (image/jpeg)
Document generated by Confluence on May 14, 2014 23:00