# Presentation: 093144

## Philip Kershaw
[on behalf of Stephen Pascoe]

GO-ESSP Seattle
18 September 2008

- [on behalf of Stephen Pascoe]
- GO-ESSP Seattle
- 18 September 2008

**Integrated OGC Web Service Delivery ****with the COWS Framework**

**Notes:**
COWS Stands for Ceda OGC WebServices Framework.

We hope we won't regret our choice of name

:-) 

## Overview

- Brief Introduction to OGC WebServices
- Motivation and High-level design of COWS
- COWS services in the wild
- NERC Portals Project
- UKCIP (UK Climate Impacts Project) Data Delivery Portal

## OGC Web Services

- Open Geospatial Consortium
- Specifications
- Web Map Service (WMS)
- Web Feature Service (WFS)
- Web Coverage Service (WCS)
- Web Processing Service (WPS)
- KML !
- EU INSPIRE will mandate OGC Web Services

**Notes:**
This isn't a OGC talk but ...

The Open Geospatial Consortium is a large industrial body standardising interfaces to geospatial data.

blabla ...

## COWS Motivation

- Develop lightweight OGC Services in Python
- Support integration with bespoke Web Applications
- Support multiple OGC services in one application

**Notes:**
COWS is a toolset for building OGC Web services using the Pylons web application framework.  It has ambitions to become a framework itself.

COWS was developed so that we could write web applications in python with embedded OGC Web Services that had data access requirements not well catered for with other GIS tools

## COWS Features

- Layered design.  Implement your service at the level of abstraction that suites you.
- Complete flexibility in underlying data model.
- Deals with the protocol “bureaucracy” of OWS-compliant
- HTTP request/response
- metadata model (OWS-Common)‏
- Exceptions
**INCOMPLETE**

**Notes:**
COWS is integrated with the Pylons web framework and inherits many powerful features from Pylons.  If you want to write a new OGC service type conforming to the general OWS-Common specification you can do it.  If you want to just put up a WMS you can do it (with a little extra code)‏

COWS deals with the OWS bureaucracy without constraining how you get the data and transform it to output.

COWS is very incomplete.  A lot of work has been done on the WMS layer.  WCS has been implemented but needs updating.  WPS implementation is under development in the DCIP project.

## Building Blocks for Layered Approach

- WSGI – Web Server Gateway Interface
- standardized pattern for web application middleware
- defines standard i/o interface enabling chaining of WSGI middleware components to apply multiple passes over HTTP request and response
- Solution for multiplicity of Python frameworks
- Pylons web framework
- a Ruby on Rails for Python – enables rapid development approach
- Built on WSGI based architecture
- COWS Plugin

## WSGI Middleware

- Add security to a COWS Application by adding security middleware
- Python Paste package enables inclusion of middleware via a config file – no change to COWS code required:

- CowsApplication

- AnotherFilter

- AuthenticationFilter

- [pipeline:CowsApplication]
- pipeline = AuthenticationFilter AnotherFilter CowsApplication

- Example middleware chain:

- HTTP Request

- HTTP Response

## Idealised COWS Application

- Paste

- Pylons

- Middleware

- Web
- Application

- COWS

- WMS

- WCS

- W*S

- Data Model

- WSGI

- WSGI

- Apache + mod_python,
- FastCGI, Python HTTPD

- e.g. Authentication

**Idealised COWS Application**

- Library

- Standard Interface

- Application-specific Code

**Notes:**
This is an idealised view of how we might put together a Pylons application containing COWS services

< Say stuff about pylons/WSGI >

## COWS Components

**cows.model** implements The OWS Common data model for describing your service and it's contents
**cows.pylons** provides pylons-specific code
- Service controllers
- templates (XML rendering)‏
**cows.service** provides service interfaces and implementations

## COWS Flexibility

- Data dimensions/parameters
- Climatological dimensions
- Probabilistic
- e.g. WMS layer supports extra WMS dimensions by default
- Custom Co-ordinate transformations
- UKMO UM rotated pole grid
- Custom rendering backend
- Custom URL layout
- Multiple URL endpoints for services

**Notes:**
COWS maximises flexibility
E.g. WMS.  The WMS layer supports extra WMS dimensions by default.  Different rendering backends can be used.

Custom code can be written to deal with coordinate transformations.

blabla

Traditional GIS frameworks like mapserver or geoserver are more constraining

CRS – Co-ordinate reference systems

## COWS Interface Evolution

- Service Controller

- Implementation Plugin

- COWS

- WMSController

- CSML WMS-impl.

**COWS Interface Evolution**

- NetCDF Data

- Data Model

- Current Design

- COWS

- Custom Controller

- Data Model

- Plugin Design

- WMS With CSML Backend

**Notes:**
Initially you need to write a Python class inheriting from COWS to implement an OGC Service.  This requires fairly detailed knowledge of COWS and Pylons.

We want to write less code

COWS is evolving to include an implementation plugin layer.  For WMS you implement a simple interface that renders WMS requests from your data model.  No knowledge of Pylons is required.

The next layer of abstraction allows you to create a WMS for a given data model without writing code.  The CSML WMS plugin does this for gridded data.

Future work is required to implement WCS and WPS with this design pattern.

## WMS Plugin Details

## NERC Portals: HiGEM WMS

- Portion of HiGEM dataset over WMS
- Uses COWS CSML Plugin
- OpenLayers as WMS Client
- Climatological time selectable as a dimension on the WMS
- KML generator links to WMS endpoint
- Enables display on GoogleEarth

**Notes:**
For the NERC Portals project we used the COWS CSML plugin to expose a portion of the HiGEM dataset over WMS.

Upper shot shows the NDG portal viewing HiGEM data using the OpenLayers browser WMS client.  Climatological time is selectable as a dimension on the WMS.  A separate web service creates KML that references the WMS to make HiGEM data visible in GoogleEarth.

## NERC Portals Project

- 2 Different Station datasets
- Integrate with CSML
- Pylons Application plots CSML Features
- 2 visualisation interfaces
- KML references plot service
- COWS WMS provides in-browser support.

**Notes:**
Also part of NERC Portals we combined 2 station-based datasets with completely different relational schemas into a single visualisation using CSML as an intermediate data model.

CSML features were plotted by a Pylons webservice.  Embedded in the same application was a COWS WMS that plots the stations as a transparent WMS layer (see next slide)‏

## Station time series via COWS WMS 

- WMS Browser Client

- GoogleEarth Client

- Times Series displayed via
- plot service

**Notes:**
Timeseries from stations were visible through either GoogleEarth or a web-based WMS client.

On the left you see stations displayed on a map.  These stations are rendered by a COWS WMS app.

On the Right the same station positions is available as a KML file.

Both views link to the plot service.  In the WMS case this is via the GetFeatureInfo request.

## UKCIP08 DDP

- Highly Dimensional Dataset
- Time Period
- Emission Scenario
- Percentile (CDF)‏
- Meaning Period
- UKMO UM Rotated Grid but we need to plot it on GoogleMaps (Transverse Mercator)
- Custom WMS operation to serve Grid-box values as JSON

**Notes:**
COWS is a central part of the data services in the DEFRA (Dept for Environment, Food and Rural Affairs) UKCIP08 (UK Climate Impacts Project) data delivery portal (DDP).

(Unfortunately I couldn't get a screenshot of the full DDP UI.  This is the WMS test-page but it's fully working.  The map widget is being integrated into the DDP UI now.)‏

Here we use COWS' flexibility to satisfy specific requirements:
	- A highly multi-dimensional dataset
	- The grid is defined on a rotated lat/lon pole but we needed to plot it on the GoogleMaps projection (transverse Mercator)‏
	- We wanted to display grid-box values on the interface.  COWS allowed us to write a custom WMS operation to return values as JSON.