Service Discovery Service Catalogue Service

54 Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.

12.4 Programming Services

12.4.1 Comments on Programming ICD

Hereafter the list issues related to the Programming ICD:  Confusion on document and schema versions Schemas refer to 0.9.4, while the document does not provide its version number.  Error handling The reference to the exception specification of OGC Web Service Specification is wrong: the correct section is §8 and not §7.4 e.g. see §13.6, §14.6, 15.3.1, etc.  GetCapabilities response Not clear the meaning of the following fields:  sps:RequiresNotificationTarget  sps:SubsequentGetFeasibilitySupported  wns:SupportedCommunicationProtocols  wns:SupportedCommunicationFormats Additionally seems missing a parameter specifying the support of WS-Addressing for asynchronous requests.  Tasking Parameters The section §8.2 describes the preliminary list of tasking parameters providing a short description and type for each of them. It is missing the specification of which sps:definition to use i.e. what element of the following ones has to be used for each the parameters: o sps:commonData element, which implies SWECommon; o sps:TaskMessageDefinition, which is not clear how does it work; o sps:GeometryDefinition o sps:ParameterDescriptor for nested parameters Additionally for each of above elements further information is needed: o in case of sps:commonData element, it is necessary to specify which SWECommon type has to be used e.g.: Count, Quantity, Text, Category, TimeRange, DataRecord, etc. o in case of sps:GeometryDefinition, it is necessary to specify whether it is a gml:Polygon or gml:Point etc.. o in case of nested parameters it is necessary to specify whether swe:DataRecord or nested sps:ParameterDescriptor have to be used. Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. 55 To be noted that SWECommon types allow defining complex and nested structures without the need of using nested sps:ParameterDescriptor. In fact for example, the swe:DataRecord allows specifying elements that can be simple or complex type as well; array are also supported. Then it is suggested: o either to complement that paragraph with a table specifying all above information for each identified parameter o or provide a rule and a template XML file showing how the different parameters have to be declared and set.  Detailed comments on sps:ParameterDescriptor: o sps:restriction can be removed because constraints can be defined directly within SWE Common types. o sps:cardinality is not described in the document. o Parameter names are case sensitive?  Detailed comments on preliminary identified tasking parameters: o ―Urgence‖ to be corrected to ―Urgency‖. It is defined as Quality of service but the values are not aligned with the OS EO [AD-02]. o Polarization Mode to be clarified: what‘s the meaning of these values? D, Q, S, T, UNDEFINED. This is a comment for GML Application schema rather than SPS EO. o Clarification on SurveyPeriods:  If a sensor can be tasked by scenes and by coverage, how it can be encoded? How the choice specified in §8.2.6 can be encoded when declaring the parameter? o TemporalSeries: there is only the periodicity and not also the repetition then the standing order will never finish. o The tasking parameters for coverage orders are too few: in fact it is not possible to filter also by orbit, pass, track, frame which are currently supported by the ESA Catalogue when computing future potential products.  ―Estimate‖ Feasibility Level This level of feasibility analysis takes into account also meteorological data. It looks not necessary because it is implicit when specifying the ―Validation Parameters‖. In fact when the tasking parameters include the accepted level of snow or cloud coverage it implies automatically to use meteorological data. Then it is suggested to use only 2 levels e.g. ―Standard‖ and ―Full‖ when the mission planning is also considered.  GetFeasibility input parameters It is not clear the purpose of ID element in the get feasibility request.  Get Feasibility Output Parameters In the current release of the Programming ICD it is not yet defined how scenes strips calculated by the feasibility analysis are represented i.e. which parameters EO Product Metadata attributes have to be returned.