Changes between Version 4 and Version 5 of OwsNotes


Ignore:
Timestamp:
26/04/07 09:47:28 (13 years ago)
Author:
spascoe
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • OwsNotes

    v4 v5  
    33 - OwsNotes/OgcServicesReview 
    44 - OwsNotes/DataServicesProposal 
    5  
    6 = Using OGC Web Services for NDG = 
    7  
    8 Below is a review of the major OWS specifications WMS, WCS, WFS and 
    9 WPS from the perspective of how we might use these services when 
    10 implementing NDG data services. 
    11  
    12 == Assumptions == 
    13  
    14  1. CSML is our model of data. 
    15  1. CSML affordance is our model of operations on a single Feature. 
    16  
    17 == Web Map Service == 
    18  
    19 A web map service is relatively simple.  It serves images of a given 
    20 geospatial coverage (bounding box).  WMS servers have the concept of 
    21 layers that may be nested.  There is explicit support for coordinates 
    22 TIME and ELEVATION and informal support for other dimensions, however 
    23 each request addresses a single horizontal coverage in these dimensions. 
    24  
    25 === How would WMS map onto CSML? === 
    26  
    27 The WMS data model is much more restricted than the CSML feature 
    28 model, therefore a means of mapping features to layers is required. 
    29  
    30 Each CSMLFeature maps onto a WMS layer (except in the case of compound 
    31 phenomena).  How a NDGDataSet is served as a whole is less clear.  The 
    32 IPCC DDC takes the approach of creating a separate WMS service 
    33 endpoint for each CSMLDataset (aka DataGranule).  This prevents the 
    34 GetCapabilities document from growing unmanageble as the number of 
    35 DataGranules increase. 
    36  
    37 == Web Feature Service == 
    38  
    39 A WFS is basically a database system that uses GML as it's data model. 
    40 As GML is itself an extensible language built upon XML schemas, WFS 
    41 semantics are heavily influenced by XML schema. 
    42  
    43 The GetFeature request specifies a feature type and a query.  The 
    44 query specifies which properties of the feature type are wanted in the 
    45 response and a filter which restricts the set of feature types 
    46 returned.  E.g. 
    47  
    48    Get me the properties widget and thingemy of all FooFeatures where 
    49    property wibble > 100 
    50  
    51 This is really quite similar to the SQL 
    52 {{{ 
    53    SELECT widget, thingemy 
    54    FROM FooFeature 
    55    WHERE wibble > 100; 
    56 }}} 
    57 (Which sure beats the XML representation ;-) 
    58  
    59 In the case of WFS all property references can be XPATH expressions 
    60 and the filter can contain symbolic and goespatial constraints. 
    61  
    62 It is important to recognise that WFS isn't designed to support 
    63 operations on features such as would be required to implement CSML 
    64 affordances.  You can constrain your feature set and the properties 
    65 returned but you can't implement something like SubsetToGridSeries 
    66 which creates a totally new GridSeries from another GridSeries. 
    67  
    68 Actually this isn't quite true.  There are 3 ways in which affordances 
    69 could be implemented within WFS: 
    70  
    71 ==== 1. the <Native> tag ==== 
    72  
    73 This is a loophole in the spec that allows you to implement anything 
    74 you like. 
    75  
    76 ==== 2. Use GetFeature/Query/Function ==== 
    77  
    78 The WFS schema allows an <ogc:Function> element to appear as a child 
    79 of <wfs:Query> (i.e. in the equivilent of the SELECT clause). 
    80 However, this isn't documented in the specification and is 
    81 incompletely documented in the schema.  It should probably be 
    82 considered another loophole. 
    83  
    84 ==== 3. Use the recent FilterModel extension ==== 
    85  
    86 This is probably the correct way of doing it but requires the 
    87 definition of your operation in XML schema.  The intention is that a 
    88 WFS can define view of a FeatureType (the FilterModel) which is used 
    89 as the subject of a query but the result remains the original 
    90 FeatureType.  This view can restrict the properties visible to the 
    91 query or add derived properties that aren't present in the returned 
    92 FeatureType.  However, as the specification points out, the 
    93 FilterModel doesn't have to resemble it's associated FeatureType.  The 
    94 FilterModel could effectively describe the parameters of an arbitary 
    95 operation. 
    96  
    97 Although theoretically one could express affordances as a FilterModel 
    98 I can see several disadvantages: 
    99  
    100  1. Constructing valid XML schema relating CSML FeatureTypes to 
    101     affordance FeatureModels would be complex.  Evaluating a query on 
    102     the server would probably be even worse. 
    103  
    104  2. The WFS spec. is predicated on retrieving FeatureTypes from a 
    105     database (in the general sense of the word) but a FeatureType 
    106     created from the affordance of another FeatureType wouldn't be 
    107     stored on the server (unless the WFS cached it) and wouldn't 
    108     necessarily be selectable from subsequent WFS requests.  This 
    109     appears to go against the spirit of a WFS. 
    110  
    111 Another way we could use FilterModels is to use them to encapsulate 
    112 selection of parts of a CSML Feature such as it's phenomenum or 
    113 domain.  This would be an alternative to selecting them using XPATH. 
    114 However, support for XPATH expressions *on the FilterModel* would still be 
    115 required according the WFS spec. 
    116  
    117 == Web Processing Service == 
    118  
    119 WPS is easily the most general OWS specification.  It simply executes 
    120 a process converting inputs to outputs.  You could wrap a Sudoku 
    121 solver in a WPS :-). 
    122  
    123 There are several useful features in the specification: 
    124  
    125  - Flexible input methods: Sent in the request or locatable by the 
    126    server via a URL.  
    127  - Flexible output methods: Returned in the response or stored for future  
    128    retrieval. 
    129  - Process state polling. 
    130  
    131 The main drawback of WPS is that because it's a very general spec 
    132 there will still be lots of design decisions to make in using it. 
    133  
    134 A WPS would be a natural way of implementing CSML affordances and 
    135 would allow the server to scale well to affordances that take a while 
    136 to execute.  It could also be used to create visualisation products 
    137 such as publication-quality plots. 
    138  
    139 == Web Coverage Service == 
    140  
    141 A WCS serves data in the form of "coverages", geospatial information 
    142 representing space-varying phenomena.  Unlike WFS, WCS is not tightly 
    143 integrated with GML.  This has some advantages, for instance WCS is 
    144 agnostic about the coverage data format, but means that there is not a 
    145 close correspondence between CSML and the WCS data model.  If WCS were 
    146 to be used in NDG a considerable ammount of work would be required to 
    147 map these two models onto each other.