Version 6 (modified by astephen, 13 years ago) (diff)


Software Development Projects Involving OGC-compliant Services


We, the climate and met scientific community (in the UK) are developing a number of software tools that will seek to expose our geospatial datasets in a manner compliant with the OGC Web Service (OWS) specifications:

  1. WCS – Web Coverage Service (
  2. WFS – Web Feature Service (
  3. WMS – Web Map Service (

We are also developing web-client applications that provide a simple user-interface:

  1. Web-clients – that can talk to OWSs

It is also worth mentioning other significant code-bases that exist:

  1. Input/Output? back-ends/APIs – often potentially running behind an OWS, or talking to it.


The purpose of this page is to expose the software that we are building. There are three main aims that we hope to achieve:

  1. Collaborative Code Development (big savings!)
  2. Interoperability of Interfaces
  3. Identification of “holes” in the OGC specs that need to be filled to ensure they are fit for our purpose.

This page does not present a Road Map because there are different drivers and requirements for different collaborators.

Organisations Involved

The collaborations that we hope will come out of this process should include the BADC, NDG, ESSC (and possibly, the Met Office). Anyone else reading this is welcome to get in contact (mail: a.stephens AT ).

Kick-off Meeting: 01/11/06

Notes from the Kick-off meeting that started these activities are provided in rough form at [Ref: /OWSSoftwareCollaborations/KickOffMeeting] – APPENDED TO THIS DOC FOR NOW

Existing Code Bases

The following table outlines the existing developments that we are aware of, have used, tried, and are actively developing. There is a column marking whether each product already does, or could potentially, expose an OWS implementation, OWS client or useful I/O layer.

Who? What? Status? WCS? WFS? WMS? Web-client? I/O-Layer? Language? Comment. GML Application Schemas: CSML (1.0/2.0), O&M, MO App Schemas. WMS: GeoServer?, Ag’s hack (CDMS/VCS), WCS: NDG-WCS, GADS-WCS/GeoServer, WFS: GADS-GeoServer?-WCS,

LAS GeoServer? ESSC ncWMS Godiva2 DX-Server DX-Client GS-Server GS-Client

  1. DX and GS clients: Ag intro
  2. ReSC GoogleMaps/OpenLayers? map portal: currently ad-hoc, moving to OpenLayers?. Making back-end a WMS then front end could talk to any WMS. Plan to distribute back-end to other people, via NetCDF.

BL: How will it differ from THREDDS? AW: THREDDS is only WCS, not WMS. JB: Keep simple and no security etc. OpenLayers? is WCS and WFS aware. AW: WFS client is normally not aware of more than one feature. Maybe it is aware of only SimpleFeaturesProfile? – doing point, line, polygon only.

  1. GeoServer? [General chat includes WCS and WFS and WMS] – heavily set up around 2D. Source is a set of features. Can render features into a map (uses simple profile?) – based on rendering features on the land surface. But GeoServer? is now being re-engineered to support 4D data (relevant to WCS) and to support NetCDF inputs. Support WMS 1.1.1.

GeoServer? issues: JT: GeoServer? doesn’t currently connect the Feature and Coverage support. When they re-factor they’ll put it all into supporting the general feature model. And once GeoTools? has been re-factored to support the (4D) General Feature Model it should provide a harmonized view. JB: You can plug in your own modular WCS or other into the GeoServer? framework. AW: Neil will be working on getting CSML into GeoServer?. Should we plug in like JB (DEWS) or go for strategic route in core of GeoServer? (or will it not be ready in time). NB has about 6 months to work on this. Branches that we know of are: • WCS branch • Complex Feature branch (Rob Atkinson) – hacky and will die when re-factoring of GFM • Trunk will be re-factored but probably unlikely to be ready within next year

  1. MapServer?: Faster than GeoServer? (C-based not Java), doesn’t try and be clever about Feature Model. Just creates pictures. Can compile with NetCDF libs. Slow to generate maps when high-res (GDAL issue). Hence JB developed alternative. DARC have used MapServer? in their Visualisation Observatory?? GDAL is 2D limited.
  2. ESSC Java-NetCDF-WMS (NcWMS): began as python on top of cdat and apache etc. Now Java NetCDF libraries worth using (instead of GADS). Hence merged to a python implementation with:

• python to talk to CDMS • jython to talk to Java Web Application I.e. one set of code with two different back-ends.

  1. TPAC are implementing a WMS layer over LAS (new Java version).
  1. TPAC/NDG-WCS: 1.0 compliant, began as WCS wrapper over OpenDAP. Now works on CSML GridSeries? Features and can serve NetCDF as well.
  2. EESC GADS-WCS (for DEWS): Building into GeoServer?, but using GADS libraries. 1.0 compliant. Would like to get to 1.1. Asynchronous delivery is added (from WPS spec). Integrating with NDG/DEWS Security. Talking HTTP rather than SOAP.
  3. DX server: Ag talked about interface issues (SOAP, WSDL etc).

AW: Very few people have dealt with WCS in other stuff than 2D-gridded data. In theory we could use either WCS or WFS for CSML.

  1. GeoServer? at the MO: Simple GML Apps supporting only. Will be using it for DEWS – but might need to simplify DEWS feature model.

Working Together?

The following pages detail overlap where we intend to start converging our code development.

How to Co-develop?

One key issue in co-developing is what strategy we adopt. Some of the key issues are:

  • common code repositories
  • common wiki and documentation
  • merging
  • planning
  • co-ordinating tasks
  • software to do these (e.g. CVS, SVN)

Frameworks To Consider

Bryan has written some useful notes on WSGI (Web Server Gateway Interface) [REF], a python framework for standardising how web-based interactions should take place. It includes use server/client request/response, session management, threading etc etc*