Open Geospatial Consortium Inc.

Transcription

1 Open Geospatial Consortium Inc. Date: Reference number of this document: OGC r3 Version: 2.0 draft Category: OpenGIS Implementation Specification Profile Editors: Philippe Mérigot (Spot Image) Alexandre Robin (Spot Image) OpenGIS Sensor Planning Service for Earth Observation profile Implementation Specification To obtain additional rights of use, visit Warning This document is not an OGC Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. Document type: Document subtype: Document stage: Document language: OpenGIS Implementation Specification Sensor Planning Service Implementation Specification Draft proposed version TBD English

2 OGC r3 draft Contents Page 1 SCOPE COMPLIANCE NORMATIVE REFERENCES TERMS AND DEFINITIONS CONVENTIONS ABBREVIATED TERMS UML NOTATION USED PARTS OF OTHER DOCUMENTS PLATFORM-NEUTRAL AND PLATFORM-SPECIFIC STANDARDS DATA DICTIONARY TABLES... 8 TABLE 1 CONTENTS OF DATA DICTIONARY TABLES SPS EO OVERVIEW SHARED ASPECTS INTRODUCTION OPERATION REQUEST ENCODING SWECOMMON ENCODING DEFAULT VALUES PRELIMINARY LIST OF TASKING PARAMETERS PROGRAMMINGREQUEST Definition UML diagram SWE Common encoding example QUALITYOFSERVICE Definition UML diagram Description SWE Common encoding example COVERAGEPROGRAMMINGREQUEST Definition UML diagram SWE Common encoding example SWATHPROGRAMMINGREQUEST Definition UML diagram REGIONOFINTEREST Definition UML diagram SWE Common encoding example TIMEOFINTEREST Definition UML diagram SWE Common encoding example ii

3 OGC r3 draft SurveyPeriod TemporalSeries ACQUISITIONTYPE Definition UML diagram SWE Common encoding example MONOSCOPICACQUISITION Definition Description SWE Common encoding example AcquisitionAngleRange STEREOSCOPICACQUISITION Definition Description SWE Common encoding example ACQUISITION PARAMETERS UML diagram AcquisitionParametersOPT AcquisitionParametersSAR VALIDATIONPARAMETERS UML diagram ValidationParametersOPT ValidationParametersSAR FEASIBILITY STUDY EXTENDED DATA Definition UML diagram Description SWE Common encoding example GridCell Segment Quality PROGRESS REPORT EXTENDED DATA Description ADDITIONAL SPS STATUS CODES AND NOTIFICATION TOPICS IMPLEMENTATION GUIDANCE SPS EO AND SWECOMMON LIBRARIES ANNEX A (NORMATIVE) ABSTRACT TEST SUITE ANNEX B (NORMATIVE) XML SCHEMA DOCUMENTS ANNEX C (INFORMATIVE) EXAMPLE XML DOCUMENTS C.1 INTRODUCTION C.2 GETCAPABILITIES GET REQUEST EXAMPLE C.3 GETCAPABILITIES RESPONSE EXAMPLE C.4 DESCRIBESENSOR REQUEST EXAMPLE C.5 DESCRIBESENSOR RESPONSE EXAMPLE C.6 DESCRIBETASKING REQUEST EXAMPLE C.7 DESCRIBETASKING RESPONSE EXAMPLE C.8 GETFEASIBILITY REQUEST EXAMPLE C.9 GETFEASIBILITY RESPONSE EXAMPLE C.10 SUBMIT REQUEST EXAMPLE C.11 SUBMIT RESPONSE EXAMPLE C.12 GETSTATUS REQUEST EXAMPLE C.13 GETSTATUS RESPONSE EXAMPLE iii

4 OGC r3 draft C.14 DESCRIBERESULTACCESS REQUEST EXAMPLE C.15 DESCRIBERESULTACCESS RESPONSE EXAMPLE iv

5 OGC r3 draft i. Preface This candidate implementation specification, based on the version 2.0 of the SPS specification, explains how Sensor Planning Service is organized and implemented for the Earth Observation domain. The final goal being to agree to a coherent set of interfaces for sending a programming request for EO products to support access to data from heterogeneous systems dealing with derived data products from satellite based measurements of the earth s surface and environment. This document has used the Implementation Specification for the Sensor Planning Service (SPS) version 2.0 [OGC ] as input. Suggested additions, changes, and comments on this draft report are welcome and encouraged. Such suggestions may be submitted by message or by making suggested changes in an edited copy of this document. The changes made in this document version, relative to the previous version, are tracked by Microsoft Word, and can be viewed if desired. If you choose to submit suggested changes by editing this document, please first accept all the current changes, and then make your suggested changes with change tracking on. ii. Document terms and definitions This document uses the standard terms defined in Subclause 5.3 of [OGC ], which is based on the ISO/IEC Directives, Part 2. Rules for the structure and drafting of International Standards. In particular, the word shall (not must ) is the verb form used to indicate a requirement to be strictly followed to conform to this standard. iii. Submitting organizations The following organizations submitted this document to the Open Geospatial Consortium Inc. ESA European Space Agency Spacebel s.a. Astrium Spot Image v

6 OGC r3 draft iv. Document contributor contact points All questions regarding this document should be directed to the editor or the contributors: Name Organization Contribution Philippe Mérigot Spot Image Editor Alexandre Robin Spot Image Editor Daniele Marchionni DATAMAT OR11, Review and comments Jolyon Martin ESA Review and comments Patrick Floissac Ingo Simonis Magellium (CNES sub contractor) Geospatial Research & Consulting Review and comments Review and comments v. Revision history Date Release Editor Primary clauses modified Didier Giacobbo initial version initial version; Description Didier Giacobbo Small update Description of Simulated Sensor Workload and parameters to delegated mission plan added Didier Giacobbo Major update Add of new operations: DelegatedMissionPlan, Update Update of the XML example Add of UML description for the EO aspects Philippe Mérigot Major update DescribeTasking replaced by DescribeGetFeasibility and DescribeSubmit. Previous DescribeGetFeasibility removed. xxxrequestresponse renamed in xxxresponse Schemas modified: DescribeGetFeasibility, GetFeasibility, GetStatus Didier Giacobbo Major update HMA-IF-DAT-MP-0001_v1.0.3 merging Didier Giacobbo Minor update Editing correction Philippe Mérigot Major update viii Open issues Future work External interface Preliminary list of Tasking Parameters ordering parameters removed GetCapabilities protocol/encoding + capabilities schema Operations removed: UpdateStatus Operations modified: GetStatus, Cancel, DescribeGetFeasibility, DescribeSubmit XML examples modified: GetFeasibility & Submit request/response, SWE Common instance (annexe) vi

7 OGC r3 draft Philippe Mérigot Major update Definition of acknowledgment messages for asynchronous operations Input parameters: QOS and Priority in a new element Priority AcquisitionMode possible values (OHR) ValidationParameters SurveyPeriods Op. modified: DescribeSubmit, Submit & GetStatus Philippe Mérigot Editing correction Future work and open issues Use of UML for the description of the preliminary list of input Parameters GetCapabilities, DescribeSensor, GetFeasibility (feasibility levels) operations modified DelegatedMissionPlan removed Delivery information removed Schemas (annex A), SensorML examples (annex B) Philippe Mérigot Editing corrections SOAP version 1.1 supported Input parameters : parameter Priority 21 (Implementation guidance) has been replaced by 20 Multi provider scenario Schemas: recursivity in Input parameters ( 8.3), GML version (v3.1.1) and target namespace Scenarios modified New request response examples in Annex B Philippe Mérigot Major update - Reference to UM ICD - OWS version Unit of measure: UCUM codes recommended - 8 and 9 inverted and modified - (IMPR#81) ProgrammingRequestMode parameter harmonised between SAR and OHR Operation - GetFeasibility : feasibility levels - Cancel : asynchronous - DescribeSensor response aligned with SOS - Shared requests and responses acknowledgement (GetFeasibility, Submit, Cancel) - Progress reports - Soap messages examples (annex B) draft Philippe Mérigot Alexandre Robin Major update - Based on OGC SPS v2.0 specification and swecommon v2.0 specification - Tasking parameters reviewed - Use of swecommon for sending values simplified - Status codes and notification topics vii

8 OGC r3 draft vi. Changes to the OGC Abstract Specification The OpenGIS Abstract Specification requires/does not require changes to accommodate the technical contents of this document. The needed changes are proposed in OGC documents XX-XXX, XX-XXX, and XX-XXX. The following is a list of the required changes: a) This clause is required in an Implementation Standard, whether or not the OpenGIS Abstract Specification requires enhancement. Note that the specific changes do not need to be specified, only that changes are required and in what areas changes need to be made. Please notice that OGC and OpenGIS are correct, and that OGC is wrong, in the standard text above, in multiple places on the title page, and in the header of page 1. vii. Future work Improvements in this document are desirable to: The parameters of the GetSensorWorkload operation have to be defined precisely. A complete schema applicable to this specification has to be provided. The user should be able to validate an acquisition in order to close the loop and update consequently the submitted task. viii

9 OGC r3 draft Foreword This document is an Earth Observation candidate profile of the future OGC Implementation Specification for the Sensor Planning Service (SPS) version 2.0 [OGC r3 and r4]. This document references several external standards and specifications as dependencies: a) Unified Modeling Language (UML) Version 1.3, The Object Management Group (OMG): b) The Extensible Markup Language (XML), World Wide Web Consortium, c) W3C Recommendation (24 June 2003): SOAP Version 1.2 Part 1,Messaging Framework, d) WSDL, Web Services Description Language (WSDL) 1.1, e) WS_Notification, Web Services Description Language (WSDL) 1.1, This second/third/... edition cancels and replaces the first/second/... edition (OGC nn-nnnrx), [clause(s) / subclause(s) / table(s) / figure(s) / annex(es)] of which [has / have] been technically revised. This document includes TBD annexes; Annexes TBD are normative, and Annexes TBD are informative. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The OGC shall not be held responsible for identifying any or all such patent rights. ix

10 OGC r3 draft Introduction The SPS configuration proposed in this profile is intended to support the programming process of Earth Observation (EO) sensors system. This profile describes a consistent SPS configuration that can be supported by many satellite data providers, most of whom have existing facilities for the management of these programming requests. The Sensor Planning Service (SPS) is intended to provide a standard interface to collection assets (i.e., sensors, and other information gathering assets) and to the support systems that surround them. Not only must different kinds of assets with differing capabilities be supported, but also different kinds of request processing systems, which may or may not provide access to the different stages of planning, scheduling, tasking, collection, processing, archiving, and distribution of requests and the resulting observation data and information that is the result of the requests. The SPS is designed to be flexible enough to handle such a wide variety of configurations. x

11 OpenGIS Implementation Specification OGC r3 OpenGIS Sensor Planning Service Application profile for Earth Observation 1 Scope This SPS EO profile document specifies at a lower level the interfaces and parameters for requesting information describing the capabilities of a Sensor Planning Service dedicated to the EO Sensor domain, for determining the feasibility of an intended sensor planning request, for submitting such a request, for inquiring about the status of such a request, for updating or cancelling such a request, and for requesting information about further OGC Web services that provide access to the data collected by the requested task. This profile document re-uses largely information models, descriptions and information comprise as defined in within version 2.0 of the SPS implementation specification [OGC09-000]. This document describes the interfaces for programming the activities of Earth Observation sensors. In particular this candidate implementation specification defines operations for: Getting the list of parameters that can be specified for programming a specific sensor; Verify the feasibility of the request that is going to be submitted; Submit the request and then check its progress; If necessary to cancel the submitted request; Retrieve the sensor s acquired data. 2 Compliance Compliance with this standard shall be checked using all the relevant tests specified in Annex A (normative). 1

12 3 Normative references The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies. [NR1] W3C Recommendation January 1999, Namespaces In XML, [NR2] W3C Recommendation 6 October 2000, Extensible Markup Language (XML) 1.0 (Second Edition), [NR3] W3C Recommendation 2 May 2001: XML Schema Part 0: Primer, [NR4] W3C Recommendation 2 May 2001: XML Schema Part 1: Structures, [NR5] W3C Recommendation 2 May 2001: XML Schema Part 2: Datatypes, [NR6] W3C Recommendation (24 June 2003): SOAP Version 1.2 Part 1: Messaging Framework, [NR7] WSDL, Web Services Description Language (WSDL) 1.1. Available [online]: [NR9] OGC r3 Corrigendum 1 OGC Web Services Common Specification [NR10] OGC swecommon Data Model encoding Standard v2.0 [NR11] OGC [NR12] GML Application schema for Earth Observation products OGC r2 Ordering Services for Earth Observation Products [NR13] OGC Version /01/2009 OpenGIS Sensor Planning Service Implementation Specification [NR14] OGC Version Sensor Model Language (SensorML) Implementation Specification [NR15] [NR16] [NR17] UCUM, Unified Code for Units of Measure Schadow, G. and McDonald, C. J. (eds.), Web Services Addressing (WS-Addressing) W3C Member Submission 10 August 2004 Web Service Base Notification 1.3 (WS-BaseNotification) OASIS standard, 1 October 2006 [NR18] OGC OpenGIS User Management Interfaces For Earth Observation Services 2

13 In addition to this document, this standard includes several normative XML Schema Document files as specified in Annex B. 4 Terms and definitions For the purposes of this standard, the definitions specified in Clause 4 of the OWS Common Implementation Specification [OGC ] shall apply. In addition, the following terms and definitions apply. 4.1 Application profile set of one or more base standards and where applicable the identification of chosen clauses, classes, subsets, options and parameters of those base standards that are necessary for accomplishing a particular function [ISO 19101, ISO 19106] 4.2 asset synonyms: sensor, simulation an available means. For the SPS, an available means of collecting information. 4.3 asset management system Synonyms: acquisition system, asset support system A system for controlling the effective utilization of an asset 4.4 client software component that can invoke an operation from a server 4.5 collection Process sense (default for this document): the act of gathering something together Result sense: an aggregation of the results of one or more collection processes. 4.6 data clearinghouse collection of institutions providing digital data, which can be searched through a single interface using a common metadata standard [ISO 19115] 4.7 data level stratum within a set of layered levels in which data is recorded that conforms to definitions of types found at the application model level [ISO 19101] 4.8 dataset series (dataset collection 1 ) collection of datasets sharing the same product specification [ISO 19113, ISO 19114, ISO 19115]. In this context, a collection metadata record in the catalogue describes a 1 Due to historical reasons we ll mainly use the term dataset collection in this document although the term dataset series is used in the ISO/TC211 Terminology Maintenance Group. 3

14 collection of EO Products, typically a dataset collection corresponds to datasets (i.e. products) generated by a single sensor in a specific mode on a particular EO satellite. 4.9 geographic dataset dataset with a spatial aspect [ISO 19115] 4.10 geographic information information concerning phenomena implicitly or explicitly associated with a location relative to the Earth [ISO draft] 4.11 georesource geographic information of a specific type (e.g. geographic dataset, geographic application, geographic service) 4.12 identifier a character string that may be composed of numbers and characters that is exchanged between the client and the server with respect to a specific identity of a resource 4.13 interface named set of operations that characterise the behaviour of an entity [ISO 19119] 4.14 metadata dataset (metadataset) metadata describing a specific dataset [ISO 19101] 4.15 metadata entity group of metadata elements and other metadata entities describing the same aspect of data NOTE 1 A metadata entity may contain one or more metadata entities. NOTE 2 A metadata entity is equivalent to a class in UML terminology [ISO 19115] metadata schema conceptual schema describing metadata NOTE ISO describes a standard for a metadata schema. [ISO 19101] 4.17 metadata section subset of metadata that defines a collection of related metadata entities and elements [ISO 19115] 4.18 operation specification of a transformation or query that an object may be called to execute [ISO 19119] 4.19 parameter variable whose name and value are included in an operation request or response 4

15 4.20 profile set of one or more base standards and where applicable the identification of chosen clauses, classes, subsets, options and parameters of those base standards that are necessary for accomplishing a particular function [ISO 19101, ISO 19106] 4.21 qualified name name that is prefixed with its naming context 4.22 request invocation of an operation by a client 4.23 requirement Something that is necessary in advance 4.24 response result of an operation, returned from a server to a client 4.25 schema formal description of a model [ISO 19101, ISO 19103, ISO 19109, ISO 19118] 4.26 server service instance a particular instance of a service [ISO 19119] 4.27 service distinct part of the functionality that is provided by an entity through interfaces [ISO 19119] capability which a service provider entity makes available to a service user entity at the interface between those entities [ISO terms repository] 4.28 service interface shared boundary between an automated system or human being and another automated system or human being [ISO 19101] 4.29 service metadata metadata describing the operations and geographic information available at a server [ISO draft] 4.30 state condition that persists for a period NOTE The value of a particular feature attribute describes a condition of the feature [ISO 19108] transfer protocol common set of rules for defining interactions between distributed systems [ISO 19118] 5

16 4.32 version version of an Implementation Specification (document) and XML Schemas to which the requested operation conforms NOTE An OWS Implementation Specification version may specify XML Schemas against which an XML encoded operation request or response must conform and should be validated. 5 Conventions 5.1 Abbreviated terms Most of the abbreviated terms listed in Subclause 5.1 of the OWS Common Implementation Specification [OGC ] apply to this document, plus the following abbreviated terms. API ATM Application Program Interface Atmospheric COTS Commercial Off The Shelf CQL CRS CSW DCE DC Common Query Language Coordinate Reference System Catalogue Service-Web Distributed Computing Environment Dublin Core DCMI Dublin Core Metadata Initiative DCP EO GML HMA Distributed Computing Platform Earth Observation Geographic Markup Language Heterogeneous Missions Accessibility HTTP HyperText Transport Protocol ISO OGC International Organisation for Standardisation Open GIS Consortium 6

17 OHR SAR Optical High Resolution Synthetic Aperture Radar SensorML Sensor Model Language SOAP Simple Object Access Protocol SPS SQL SWE Sensor Planning Service Structured Query Language Sensor Web Enablement UCUM Unified Code for Units of Measure UML URI URL URN Unified Modeling Language Uniform Resource Identifier Uniform Resource Locator Uniform Resource Name UTF-8 Unicode Transformation Format-8 WNS Web Notification Service WSDL Web Service Definition Language W3C XML World Wide Web Consortium extensible Markup Language 5.2 UML notation Most diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of [OGC ]. 5.3 Used parts of other documents This document may use significant parts of documents [OGC ] and OGC SPS specification v2.0 [NR13]. To reduce the need to refer to these documents, this document copies some of those parts with small modifications. To indicate those parts to readers of this document, the largely copied parts are shown with a light grey background (15%). 7

18 5.4 Platform-neutral and platform-specific standards As specified in Clause 10 of OGC Abstract Specification Topic 12 OpenGIS Service Architecture (which contains ISO 19119), this document includes both Distributed Computing Platform-neutral and platform-specific standards. This document first specifies each operation request and response in platform-neutral fashion. This is done using a table for each data structure, which lists and defines the parameters and other data structures contained. These tables serve as data dictionaries for the UML model in Annex C, and thus specify the UML model data type and multiplicity of each listed item. EXAMPLES 1 Platform-neutral standards are contained in Subclauses TBD, and TBD. The specified platform-neutral data could be encoded in many alternative ways, each appropriate to one or more specific DCPs. This document now specifies encoding appropriate for use of HTTP GET transfer of operations requests (using KVP encoding), and for use of HTTP POST transfer of operations requests (using XML or KVP encoding). However, the same operation requests and responses (and other data) could be encoded for other specific computing platforms, including SOAP/WSDL. EXAMPLES 2 EXAMPLES 3 Platform-specific standards for KVP encoding are contained in Subclauses TBD, and TBD. Platform-specific standards for XML encoding are contained in Subclauses TBD, and TBD. 5.5 Data dictionary tables The UML model data dictionary is specified herein in a series of tables. The contents of the columns in these tables are described in Table 1. 8

19 Table 1 Contents of data dictionary tables Column title Names (left column) Definition (second column) Data type and value (third column) or Data type (if are no second items are included in rows of table) Multiplicity and use (right or fourth column) or Multiplicity (if are no second items are included in rows of table) Column contents Two names for each included parameter or association (or data structure). The first name is the UML model attribute or association role name. The second name uses the XML encoding capitalization specified in Subclause of [OGC ]. The name capitalization rules used are specified in Subclause of [OGC ]. Some names in the tables may appear to contain spaces, but no names contain spaces. Specifies the definition of this parameter (omitting un-necessary words such as a, the, and is ). If the parameter value is the identifier of something, not a description or definition, the definition of this parameter should read something like Identifier of TBD. Normally contains two items: The mandatory first item is often the data type used for this parameter, using data types appropriate in a UML model, in which this parameter is a named attribute of a UML class. Alternately, the first item can identify the data structure (or class) referenced by this association, and references a separate table used to specify the contents of that class (or data structure). The optional second item in the third column of each table should indicate the source of values for this parameter, the alternative values, or other value information, unless the values are quite clear from other listed information. Normally contains two items: The mandatory first item specifies the multiplicity and optionality of this parameter in this data structure, either One (mandatory), One or more (mandatory), Zero or one (optional), or Zero or more (optional). The second item in the right column of each table should specify how any multiplicity other than One (mandatory) shall be used. If that parameter is optional, under what condition(s) shall that parameter be included or not included? If that parameter can be repeated, for what is that parameter repeated? When the data type used for this parameter, in the third column of such a table, is an enumeration or code list, all the values specified by a specific OWS shall be listed, together with the meaning of each value. When this information is extensive, these values and meanings should be specified in a separate table that is referenced in the third column of this table row. The data type of many parameters, in the third table column, is specified as Character String type, not empty. In the XML Schema Documents specified herein, these parameters are encoded with the xsd:string type, which does NOT require that these strings not be empty. The contents of these data dictionary tables are normative, including any table footnotes. 9

20 6 SPS EO overview The SPS operations can be divided into informational and functional operations. The informational operations are the GetCapabilities, DescribeSensor, DescribeTasking, DescribeResultAccess and GetStatus operation. The functional operations are the GetFeasibility, Reserve, Commit, Submit, Update and Cancel operations. Another functional operation, GetSensorWorkload, has to be adopted for the EO profile. a) GetCapabilities (mandatory) This operation allows a client to request and receive service metadata (or Capabilities) documents that describe the abilities of the specific server implementation. This operation also supports negotiation of the specification version being used for client-server interactions. Moreover, the content section of this operation contains the list of sensorid provided by the service. b) DescribeSensor (mandatory) This operation allows the client to obtain a description of the sensors supported by the current SPS. The mission can decide on the amount of details provided in such a description (The use of hyperlinks can help keep the initial document size small and simple while still allowing the client to go fetch more detailed information). c) GetSensorWorkload (optional) This operation provides information on the workload of the sensor specified in the request. The description of this workload is under the responsibility of the mission and the freshness of the information will be indicated by the mission. d) DescribeTasking (mandatory) This operation allows a client to request the information that is needed in order to send GetFeasibility (for a feasibility study), Submit, Update and Reserve (for tasking the asset) requests.. The response contains a description of the input (tasking parameters) and optionally the output parameters included in status reports. e) GetFeasibility (optional) This operation is to provide feedback to a client about the feasibility of a programming request. Depending on the sensor type offered by the SPS, the SPS server action may be as simple as checking that the request parameters are valid, and are consistent with certain business rules, or it may be a complex operation that calculates the usability of the sensor to perform a specific task at the defined location, time, orientation, calibration etc. f) Submit (mandatory) This operation submits the programming request. Dependent on the selected sensor, it may perform a simple modification of the sensor or start a complex mission. g) GetStatus (mandatory) This operation allows a client to receive information about the current status of the requested task. The response contains a progress report which content is defined by each service instance in the DescribeTasking response. 10

21 h) Cancel (optional) This operation allows a client to request cancellation of a previously submitted task. i) Update (optional) This operation allows a client to update a previously submitted task. j) DescribeResultAccess (mandatory) This operation allows a client to retrieve information how and where data that was produced by the sensor can be accessed. The server response may contain links to any kind of data and not necessary through an OGC Web services nevertheless OGC Web services such as SOS, WMS, WFS or WCS are desirable. The following operations enable clients to reserve a task instead of directly submitting it. This facilitates tasking of a group of SPSs. Reserved tasks have a finite lifetime before they expire. During this lifetime such a task can be confirmed so that the service starts execution. k) Reserve (optional) This operation reserves a task. A reservation lasts for a certain amount of time and can be committed during this timeframe. l) Confirm (optional) This operation is used to commit a reserved task. By committing a reserved task the SPS starts execution of the task. These operations have many similarities to other OGC Web Services, including the WMS, WFS, and WCS. Many of these interface aspects that are common with other OWSs are thus specified in the OpenGIS Web Services Common Implementation Specification [OGC ]. Many of these common aspects are normatively referenced herein, instead of being repeated in this specification. 11

22 7 Shared aspects 7.1 Introduction This clause specifies aspects of the SPS EO Service behavior that are shared by several operations. 7.2 Operation request encoding The encoding of operation requests shall use HTTP GET with KVP encoding and HTTP POST with XML, SOAP (1.1 and 1.2), and/or KVP encoding as specified in Clause 11 of [OGC ]. Table 2 summarizes the SPS EO Service operations and their encoding methods defined in this standard. Table 2 Operation request encoding Operation name GetCapabilities (mandatory) DescribeSensor DescribeTasking (mandatory) GetFeasibility Submit (mandatory) Update GetStatus (mandatory) Cancel DescribeResultAccess (mandatory) EstimateSensorWorkload Reserve Confirm Request encoding KVP and optional SOAP/XML SOAP/XML and optional KVP SOAP/XML and optional KVP SOAP/XML SOAP/XML SOAP/XML SOAP/XML and optional KVP SOAP/XML and optional KVP SOAP/XML and optional KVP SOAP/XML and optional KVP SOAP/XML SOAP/XML and optional KVP Note: the optional KVP is proposed (as optional) only for the operation requests that do not contain complex parameters (i.e. tasking parameters). 7.3 swecommon encoding The description of the tasking parameters, returned in the DescribeTasking operation response, is given using swecommon format ([NR10]). Values of tasking parameters are also in swecommon format. Refer to 8 for examples of swecommon. 12

23 7.4 Default values The description of a tasking parameter may contain a default value, specified in a swe:value element. Example: <swe:field name="fusionaccepted" optional="true"> <swe:boolean definition="urn:ogc:def:property:ceos:eop:fusionaccepted"> <gml:name>fusion Accepted</gml:name> <swe:value>true</swe:value> </swe:boolean> In the example above, the default value for the FusionAccepted parameter is true. It means that if the client does not specify a value, the server will automatically apply the value true for this parameter. 13

24 8 Preliminary list of tasking parameters This paragraph proposes the preliminary and extensible list of parameters a client has to provide to task an EO profile asset. The objective is, in a multi mission context, to define the name and the type of the parameters shared by all the EO missions. For interoperability reason, when implementing an EO SPS, developers SHALL use (some of) the tasking parameters specified in this document, even if the name or the unit is different than the ones they usually use. It is possible to create parameters that are not specified in this document, but this possibility must be used only if the parameter is specific to the sensor and has no equivalent in this document. If the name and the type of the EO parameters are specified, each SPS implementer can: - Mark a parameter as optional or mandatory; - Restrict the possible values of a parameter; - Add its own proprietary parameters that are not listed in this document. These proprietary parameters should be optional for ensuring compatibility with generic clients. Note: it is recommended that all optional parameters have a default value. 14

25 8.1 ProgrammingRequest Definition The ProgrammingRequest element is the root element. It is abstract and cannot be instantiated. Instead, the CoverageProgrammingRequest element (cf. 8.3) or the SwathProgrammingRequest element (cf. 0) must be instantiated UML diagram ProgrammingRequest QualityOfServ ice * ValidationParameters Possibility of having several different ValidationParameters groups if sensorid regroups several types of instruments (OHR + SAR for instance) Cov erageprogrammingrequest Sw athprogrammingrequest QualityOfService is specified in 8.2 CoverageProgrammingRequest is specified in 8.3 SwathProgrammingRequest is specified in 8.4 ValidationParameters is specified in SWE Common encoding example See 8.3 and

26 8.2 QualityOfService Definition Levels of Urgency and Priority of the programming request UML diagram QualityOfServ ice + Priority: enum string Priority is specified in Erreur! Source du renvoi introuvable.. Mis en forme : Anglais (Royaume-Uni) Description Priority Name Description Type (unit) STANDARD, HIGH Enum string HIGH = Level of priority previously agreed upon with provider SWE Common encoding example <swe:field name="qualityofservice"> <swe:datarecord> <swe:field name="priority"> <swe:category definition="urn:ogc:def:property:ceos:eop:prioritylevel"> <swe:constraint> <swe:allowedtokens> <swe:valuelist>standard HIGH</swe:valueList> </swe:allowedtokens> </swe:constraint> <swe:value>standard</swe:value> </swe:category> </swe:datarecord> 16

27 8.3 CoverageProgrammingRequest Definition A CoverageProgrammingRequest is used when tasking a satellite based on an area and period of interest, by opposition to the SwathProgrammingRequest that allows the satellite to be tasked directly based on orbit related criteria (lower level tasking) UML diagram RegionOfInterest is specified in 8.5. Several regions of interest can be specified if the service can support it. TimeOfInterest is specified in 8.6. Several times of interest can be specified if the service can support it. If several periods of interest are supported, they should all be survey periods and not time series. Note: time series are used for multiple acquisitions at different dates, while specifying several survey periods means only one acquisition, made during one of the several possible periods. AcquisitionType is specified in

28 8.3.3 SWE Common encoding example The following example shows the skeleton of tasking parameters definition (the content of each field element has been hidden for clarity): 8.4 SwathProgrammingRequest Definition A SwathProgrammingRequest is used to provide low level tasking capabilities based directly on orbit, track and frame numbers. This should be restricted to advanced users since it requires a-priori knowledge of the mission being tasked. Moreover, this tasking mode is not applicable to a virtual SPS offering representing several missions, since a coherent programming request would not be possible in this case, each mission having a different orbit. 18

29 8.4.2 UML diagram ProgrammingRequest Sw athprogrammingrequest 0..1 TimeOfInterest 1..* «Choice» SwathSegment + Cycle: int [0..1] + Track: int SegmentByFrame + StartOrbit: int + StartFrame: int + StopOrbit: int + StopFrame: int SegmentByTime + StartTime: datetime + StopTime: datetime 8.5 RegionOfInterest Definition This is used to specify the desired geographical region of interest that should be acquired by the satellite. A user may specify the value of a Region of Interest by using either a polygon or a circle. 19

30 8.5.2 UML diagram RegionOfInterest «Choice» Geometry Polygon + exterior: LinearRing + interior: LinearRing [0..*] Circle + Center: Point + Radius: float SWE Common encoding example The following example shows the skeleton of RegionOfInterest parameter definition (the content of Polygon and Circle items has been hidden for clarity): The content of the item elements is detailed below. SWE Common encoding for a RegionOfInterest using a polygon: <swe:item name="polygon"> <swe:datarecord definition="urn:ogc:def:property:iso-19107:polygon"> <swe:field name="exterior"> <swe:dataarray definition="urn:ogc:def:property:iso-19107:linearring"> <swe:elementcount> <swe:count/> </swe:elementcount> <swe:elementtype name="point"> <swe:vector is="record" referenceframe="urn:ogc:def:crs:epsg:6.2:4326"> <swe:coordinate is="field" name="lat"> <swe:quantity axisid="y"> <swe:uom code="deg"/> 20

31 </swe:quantity> </swe:coordinate> <swe:coordinate is="field" name="lon"> <swe:quantity axisid="x"> <swe:uom code="deg"/> </swe:quantity> </swe:coordinate> </swe:vector> </swe:elementtype> </swe:dataarray> </swe:datarecord> </swe:item> SWE Common encoding for a RegionOfInterest using a circle: <swe:item name="circle"> <swe:datarecord definition=" urn:ogc:def:property:iso-19107:circle"> <swe:field name="center"> <swe:vector is="record" referenceframe="urn:ogc:def:crs:epsg:6.2:4326"> <swe:coordinate is="field" name="lat"> <swe:quantity axisid="y"> <swe:uom code="deg"/> </swe:quantity> </swe:coordinate> <swe:coordinate is="field" name="lon"> <swe:quantity axisid="x"> <swe:uom code="deg"/> </swe:quantity> </swe:coordinate> </swe:vector> <swe:field name="radius"> <swe:quantity> <swe:uom code="km"/> </swe:quantity> </swe:datarecord> </swe:item> 8.6 TimeOfInterest Definition This parameter is used to specify the desired period(s) of acquisition. A TimeOfInterest may be specified either by one or more SurveyPeriods or (only) one TemporalSeries. 21

32 8.6.2 UML diagram TimeOfInterest «Choice» TimePrimitive Periodicity Range -> Tight range = strict periodicity = exact time series type formosat -> Large range ~ frozzen days specifying only a minimum Latest Start -> Latest date at which the first acquisition of the series should be completed, to make sure it is synchronized with seasons, etc.. «TimeRange» Surv eyperiod TemporalSeries + SurveyPeriod: datetime range + Occurrences: int + PeriodicityRange: float range + LatestStart: date [0..1] SurveyPeriod is specified in TemporalSeries is specified in SWE Common encoding example The following example shows the skeleton of TimeOfInterest parameter definition (the content of SurveyPeriod and TemporalSeries elements has been hidden for clarity): SurveyPeriod Definition The SurveyPeriod is a time range specifying the period during which the feasibility or tasking is done. 22

33 UML diagram SWE Common encoding example <swe:item name="surveyperiod"> <swe:timerange definition="urn:ogc:def:property:ceos:eop:surveyperiod"> <gml:name>survey Period</gml:name> <swe:uom xlink:href="urn:ogc:def:unit:iso:8601"/> </swe:timerange> </swe:item> TemporalSeries Definition This class can be used to specify a temporal series of acquisitions. A temporal series contains a SurveyPeriod element (see 8.6.4) and parameters that define the number of occurrences, the periodicity and the latest start date of the series UML diagram TemporalSeries + SurveyPeriod: datetime range + Occurrences: int + Periodicity: float range + LatestStart: date [0..1] Description Name Description Type (unit) SurveyPeriod Overall period during which the whole series should be datetime range acquired, while the latest start, if supported, specifies the date before which the first acquisition of the series must be completed. Occurences Number of times the region should be fully covered. int PeriodicityRange* Acceptable periodicity range for the temporal series (see float range note below). LatestStart Latest start. date 23

34 * The periodicity range provides a flexible mechanism to support strict time series (i.e. with an exact periodicity), as well as series with frozen days specifying a minimum duration between two successive acquisition of the series. The period is inclusive. - An exact periodicity is supported by indicating a tight range. It is specified in number of days. For example the following range [1 1] indicates that the periodicity should be EXACTLY 1 day. - A number of frozen days can be indicated by only specifying the lower bound of the range. For example, [30 +Inf] means that the period between two successive acquisitions must be AT LEAST 30 days, but can be arbitrary larger, as long as the whole series can be completed within the survey period. - Finally it is possible to obtain an intermediate behavior by indicating both low and high bounds such as [10 20] meaning that the period between two successive acquisitions must be BETWEEN 10 and 20 days, thus leaving more flexibility to the satellite operator, when a strict time series is not really required. It is worth mentioning that the periodicity range specified must be compatible with the overall survey period and the number of occurrence, such that: Minimum periodicity * Number of occurrences <= Survey duration If this constraint is not satisfied, the service should send an InvalidParameterValue exception SWE Common encoding example <swe:item name="temporalseries"> <swe:datarecord> <swe:field name="surveyperiod"> <swe:timerange definition="urn:ogc:def:property:ceos:eop:surveyperiod"> <gml:name>survey Period</gml:name> <swe:uom xlink:href="urn:ogc:def:unit:iso:8601"/> </swe:timerange> <swe:field name="occurences"> <swe:count definition="urn:ogc:def:property:ceos:eop:temporalseriesoccurences"> <gml:description>number of times the region should be fully covered</gml:description> <gml:name>number of Occurences</gml:name> </swe:count> <swe:field name="periodicityrange"> <swe:timerange definition="urn:ogc:def:property:ceos:eop:temporalseriesperiodicity"> <gml:description>acceptable periodicity range for the temporal series</gml:description> <gml:name>acquisition Periodicity Range</gml:name> <swe:uom code="d"/> </swe:timerange> 24

35 <swe:field name="lateststart"> <swe:time definition="urn:ogc:def:property:ceos:eop:temporalserieslateststart"> <gml:name>latest Start</gml:name> <swe:uom xlink:href="urn:ogc:def:unit:iso:8601"/> </swe:time> </swe:datarecord> </swe:item> 8.7 AcquisitionType Definition The AcquisitionType class is used to specify if the acquisition is monoscopic or stereoscopic, as well as contain specific acquisition parameters UML diagram AcquisitionType AcquisitionParameters 1..* «Choice» Acquisition MonoscopicAcquisition + CoverageType: enum string + AcquisitionAngle: AcquisitionAngleRange StereoscopicAcquisition + CoverageType: enum string + AcquisitionAngle1: AcquisitionAngleRange + AcquisitionAngle2: AcquisitionAngleRange + BHRatio: float + MaxCoupleDelay: float MonoscopicAcquisition is specified in 8.8. StereoscopicAcquisition is specified in 8.9. AcquisitionParameters is specified in

36 8.7.3 SWE Common encoding example The following example shows the skeleton of AcquisitionType parameter definition (the content of MonoscopicAcquisition and StereoscopicAcquisition elements has been hidden for clarity): 8.8 MonoscopicAcquisition Definition Parameters for a monoscopic acquisition Description Name Description Type (unit) CoverageType Specifies if the imagery should be Enum string acquired in one or multiple passes. SINGLE_SWATH: The region of interest should be covered by a single segment. MONOPASS: The region of interest must be covered by one or more segments acquired from the same orbit (some agile satellites can cover large zones even when satisfying this constraint). MULTIPASS: The region of interest can be covered by using images extracted from several segments acquired at different dates provided that they are all acquired within the requested time period AcquisitionAngle See SINGLE_SWATH, MONOPASS, MULTIPASS 26

37 8.8.3 SWE Common encoding example Example of monoscopic acquisition for an optical instrument (the content of each field element has been hidden for clarity): Example of monoscopic acquisition for a SAR instrument: AcquisitionAngleRange UML diagram «Choice» AcquisitionAngleRange IncidenceAngleRange + AzimuthRange: float range + ElevationRange: float range PointingAngleRange + AlongTrackRange: float range + AcrossTrackRange: float range Acceptable acquisition angles can be specified either by indicating a range of incidence angles (i.e. the angle with which the look vector intersects the earth surface) or a range of pointing angles (i.e. the angle of the look vector in the nadir oriented frame of reference attached to the satellite). IncidenceAngleRange is specified in PointingAngleRange is specified in

38 IncidenceAngleRange Definition Specification of allowed acquisition angles in terms of angles expressed relative to a frame of reference attached to the location of the acquisition (i.e. on the ground) Description Name Description Type (unit) AzimuthRange Range of acceptable azimuth incidence angles. The azimuth angle is the angle float range (deg) that the look vector (projected vertically on the earth surface) makes with the north direction. It thus indicates from which geographic direction (i.e. North, East, West, South) the region of interest should be imaged ElevationRange Range of acceptable elevation incidence angles. The elevation angle is the angle that the look vector makes with the local vertical. It thus indicates how vertically the region should be imaged. This is the traditional meaning of incidence angle. float range (deg) PointingAngleRange Definition Specification of allowed acquisition angles in terms of angles expressed in the satellite reference frame and relative to the nadir direction Description Name Description Type (unit) AlongTrackRange Range of acceptable pointing angles in the along track direction (i.e. the angle between the nadir direction and the look vector, measured around the axis of the satellite reference frame that is float range (deg) 28

39 AcrossTrackRange. orthogonal to the orbit plane) Range of acceptable pointing angles in the across track direction (i.e. the angle between the nadir direction and the look vector, measured around the axis of the satellite reference frame with a direction tangent to the satellite trajectory) float range (deg) SWE Common encoding example 8.9 StereoscopicAcquisition Definition Parameters for a stereoscopic acquisition Description Name Description Type (unit) CoverageType See Enum string AcquisitionAngle1 See AcquisitionAngleRange AcquisitionAngle2 See AcquisitionAngleRange BHRatio MaxCoupleDelay Ratio between base and height of the triangle constructed by viewing directions of the two acquisitions in a stereoscopic couple, and the local horizontal plane. Maximum time delay between two acquisitions of a stereoscopic couple. float float (days) SWE Common encoding example 29