Changes between Version 5 and Version 6 of OWSSoftwareCollaborations

29/11/06 13:49:09 (13 years ago)



  • OWSSoftwareCollaborations

    v5 v6  
    1717 1. Input/Output back-ends/APIs – often potentially running behind an OWS, or talking to it. 
    19 '''Purpose''' 
     20== Purpose == 
    2123The purpose of this page is to expose the software that we are building. There are three main aims that we hope to achieve: 
    23 1. Collaborative Code Development (big savings!) 
    24 2. Interoperability of Interfaces 
    25 3. Identification of “holes” in the OGC specs that need to be filled to ensure they are fit for our purpose. 
     25 1. Collaborative Code Development (big savings!) 
     26 2. Interoperability of Interfaces 
     27 3. Identification of “holes” in the OGC specs that need to be filled to ensure they are fit for our purpose. 
    2729This page does not present a Road Map because there are different drivers and requirements for different collaborators. 
    29 Organisations Involved 
     31== Organisations Involved == 
    3133The 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 ). 
    33 Kick-off Meeting: 01/11/06 
     35== Kick-off Meeting: 01/11/06 == 
    3437Notes from the Kick-off meeting that started these activities are provided in rough form at [Ref: /OWSSoftwareCollaborations/KickOffMeeting] – APPENDED TO THIS DOC FOR NOW 
    106109Bryan 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*** 
    108 Appendix 1: to put in new wiki 
    110 Agenda for Our Services and OGC Web Services Meeting 
    111 Version 0.4 – Ag Stephens 
    113 Attendees:      A.Woolf (NDG), D. Lowe (NDG), J. Blower (ESSC), J.Tandy (MO), B.Lawrence (NDG), A.Stephens (NDG), N.Bennett (Daresbury), S.Pascoe (NDG). 
    114 Time:           1000-1300, Wednesday 1st November 2006. 
    115 Location:       EOASD Room, , RAL. 
    116 Contact for Visitors: Dominic Lowe - 01235 44(5139) 
    118 Agenda 
    120 1000-1200: What have we got and what do we know about? 
    121 Discussion with possibly some quick demos if people want to. The aim of this session will be to draw up (literally) a diagram of all the components that we currently, or plan to, deploy and the external projects that we hope to borrow from. I think the cards on the table are: 
    123 Geo-clients: DX and GS clients, ReSC GoogleMaps/OpenLayers map portal. 
    124 GML Application Schemas: CSML (1.0/2.0), O&M, MO App Schemas. 
    125 WMS: GeoServer, ReSC CDMS-WMS, Ag’s hack (CDMS/VCS), ESSC Java-NetCDF-WMS (NcWMS)? 
    126 WCS: NDG-WCS, GADS-WCS/GeoServer, DX server, version changes. 
    127 WFS: GADS-WCS/GeoServer, DX server, version changes. 
    128 Filter Encoding (applied to other services) 
    129 WPS: ? Martin Juckes proposal, JB has looked at spec, MO use, DEWS use? 
    131 ShapeChange issues: CSML-compatibility? auto-generation of parsing/demarshalling code? integration into EA? GML 3.2-compliance? 
    133 Given that the conversation will no doubt jump between these because of the crossover I don’t think we need to worry about treating them as sequential agenda items. 
    135 Things that we also need to cover: 
    136 - queuing systems 
    137 - parallel systems 
    138 - animations rather than images 
    140 1200-1300: Where do we think we are going?  
    141 There are clearly a lot of possible futures. However, we now have enough experience to be able to guess the future. The aim of this session is to look at how we can achieve convergence in the mid to long term. Which components do we imagine will stand the test of time? 
    143 Ag and Bryan to exit at 1300 but others welcome to carry on. 
    145 Table on current Versions of OGC Specs  (is this right?) 
    146 Spec    Commonly implemented    Current Draft 
    147 WFS     1.0     1.1.0 (May 2005) 
    148 + Corrigendum (Oct 2005)        1.2 (not seen)  
    149 DAQM and filter encoding 1.2 
    150 WCS     -       1.0 (August 2003) 
    151 + Corrigendum (Oct 2005)        1.1 (voting on it now) 
    152 WMS     1.1.1   1.3.0 (March 2006)  
    153 + App Profile for EO Products (July 2006) 
    154 ISO19128 standardised   ? 
    155 WPS             0.4.0 (Sep 2005) - DRAFT        ? 
    156 Filter Encoding         1.1.0 (May 2005)        ? 
    159 Geo-clients:  
    160 1. DX and GS clients: Ag intro 
    161 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. 
    162 BL: How will it differ from THREDDS? 
    163 AW: THREDDS is only WCS, not WMS. 
    164 JB: Keep simple and no security etc. OpenLayers is WCS and WFS aware. 
    165 AW: WFS client is normally not aware of more than one feature. Maybe it is aware of only SimpleFeaturesProfile – doing point, line, polygon only. 
    167 GML Application Schemas:  
    168 1. CSML (1.0/2.0): GML App Schema to define FTs for climate science data. Re-factoring to V2.0 which increases number of FTs, becomes more compatible with O&M model, defines some “operations” associated with FTs. 
    169 2. O&M: Going to be a new OGC Spec. It is an App Schema developed by OGC. It uses standard patterns for recording information from measurements and simulations etc.  
    170 3. MO App Schemas: Need to expose meteorological information. But limited to Simple  
    172 Services: 
    173 SOS: Will allow you to expose O&M features. 
    175 WMS Spec:  
    176 The WMS Spec: 1.3.0 is latest. The major changes from 1.1.0 are: 
    177 •       data is a set of maps, supports time and elevation and other arbitrary dimensions. (i.e. XY x any number of other dimensions). 
    178 •       supports a number of CRSs. 
    179 •       Changed code for some projections and then swapped lat/lon. 
    180 •       a layer is now 4D – i.e. is a variable (or parameter or field) and these can be nested in layers that are essentially datasets. 
    181 Very few implementations are truly compliant with the spec. 
    182 Mpeg (i.e. animation) is valid output format. 
    183 Possible holes in spec are: 
    184 •       cannot (easily) match a range to a colourmap 
    185 •       capabilities document is monolithic: 
    186 o       layer definitions allow nesting but could expose large XML unnecessarily. 
    187 o       But GetCapabilities has a timestamp so the client can cache the returned XML and then only get new version if it has changed. 
    189 WMS Implementations: 
    190 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. 
    191 GeoServer issues: 
    192 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.  
    193 JB: You can plug in your own modular WCS or other into the GeoServer framework. 
    194 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. 
    195 Branches that we know of are: 
    196 •       WCS branch 
    197 •       Complex Feature branch (Rob Atkinson) – hacky and will die when re-factoring of GFM 
    198 •       Trunk will be re-factored but probably unlikely to be ready within next year 
    201 2. 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.  
    202 3. 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: 
    203 •       python to talk to CDMS 
    204 •       jython to talk to Java Web Application  
    205 I.e. one set of code with two different back-ends. 
    206 4. TPAC are implementing a WMS layer over LAS (new Java version). 
    208 WCS Spec:  
    209 Voting on it now. 
    210 One problem is that implementations tend to be 2D focussed – until latest version gets implemented.  
    211 DL gave overview of changes to 1.1.  
    212 Issues about CRS and dimensionality selection. 
    214 WCS Implementations: 
    215 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. 
    216 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. 
    217 3. DX server: Ag talked about interface issues (SOAP, WSDL etc). 
    218 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. 
    220 WFS Spec: 
    221 Could WFS spec use getGmlObject to return a binary file (NetCDF)? We should look into this. 
    223 WFS Implementations:  
    224 1. DX server 
    225 2. GeoServer at the MO: Simple GML Apps supporting only. Will be using it for DEWS – but might need to simplify DEWS feature model.  
    227 Filter Encoding (applied to other services) 
    228 WPS: ? Martin Juckes proposal, JB has looked at spec, MO use, DEWS use? 
    229 Projects:  
    230 DEWS, MO projects,  
    231 GALEON: Moving into a phase looking at further integration tests etc, hooking into NcML and CSML. We will contribute where we can.  
    232 THREDDS: Has a WCS interface. 
    235 ShapeChange issues:  
    236 ShapeChange allows the generation of a GML App Schema from a UML model based on the rules set in ISO19xxx. You can export UML to XMI, import to ShapeChange and it should be able to create an App Schema. However, it is limited to simple features. Main point is that you can map onto existing schemas so that you can re-use elements from other ISO standards and/or other GML schemas etc. Mappings to things like CSML are missing. GML 3.2-mappings not available until re-factored, and someone creates them. No specific plans for integration into EA. XMI 2 is going to be a clear standard. Planning to use the Eclipse MOF model. 
    238 Outputs we want from this meeting: 
    240 1.      Whiteboard roadmap 
    241 2.      Notes (Jon, Ag, Jeremy, Bryan?) 
    242 3.      Key issue: interoperability tests – interfaces that can talk to eachother. 
    244 ACTIONS: 
    245 DL: Raise issue of asynchronous results. Need to look at WPS version (as used in DEWS by JB). 
    248         Whiteboard roadmap 
    250 2.      Notes (Jon, Ag, Jeremy, Bryan?) 
    252 3.      Key issue: interoperability tests – interfaces that can talk to eachother. 
    256 ACTIONS: 
    258 DL: Raise issue of asynchronous results. Need to look at WPS version (as used in DEWS by JB).