OGC RESTful encoding of OGC Sensor Planning Service for Earth Observation satellite Tasking

Transcription

1 Open Geospatial Consortium Submission Date: Approval Date: Publication Date: External identifier of this OGC document: Internal reference number of this OGC document: OGC r1 Version: 1.0 Category: OGC Best Practice Editor: Nicolas FANJEAU Sebastian ULRICH OGC RESTful encoding of OGC Sensor Planning Service for Earth Observation satellite Tasking Copyright notice To obtain additional rights of use, visit Warning This document defines an OGC Best Practices on a particular technology or approach related to an OGC standard. This document is not an OGC Standard and may not be referred to as an OGC Standard. It is subject to change without notice. However, this document is an official position of the OGC membership on this particular technology topic. Document type: Document subtype: Document stage: Document language: OGC Best Practice if applicable Approved for public release English 1

2 License Agreement Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement. If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR. THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY. This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party. Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it. 2

3 Contents 1. Scope Conformance References Normative references Other references Terms and Definitions Conventions Abbreviated terms UML notation Used parts of other documents Platform-neutral and platform-specific standards Data dictionary tables RESTful encoding of Sensor Planning Service for Earth Observation satellite Tasking (RESET) overview RPC view of RESET Resource view of RESET Essential use cases Planning with feasibility study Direct planning Reservation planning Resource model Resource root path Capabilities resource URL Definition HTTP methods Error handling

4 7.3 Procedures resource URL Definition HTTP methods Error handling Feasibility resource URL Definition HTTP methods Error handling Planning resource URL Definition HTTP methods Error handling Reservation resource URL Definition HTTP methods Error handling RESET Core Class Capabilities Service Identification Contents Notifications OperationsMetadata URL resource distribution

5 8.2 Procedures Tasking description Sensor description Sensor availabilities Tasking Task status Task description RESET Feasibility Class Capabilities Procedures Feasibility Creation Task description RESET Planning Class Capabilities Procedures Planning Status Creation Acquisition Task description Result description Segments validation RESET Feasibility Planning Class Capabilities Procedures Feasibility

6 Submission Planning RESET Reservation Class Capabilities Procedures Planning Reservation Creation Modification Submission RESET Cancellation Class Capabilities Procedures Tasking Task cancellation Annex A: Conformance Class Abstract Test Suite (Normative) Conformance class: Core Capabilities resource Procedures resource Tasking resources Conformance class: Feasibility Feasibility resource Conformance class: Planning Planning resource Conformance class: Feasibility Planning Feasibility resource Planning resource

7 14.5 Conformance class: Reservation Capabilities resource Planning resource Reservation resource Conformance class: Cancellation Capabilities resource Planning resource Reservation resource Annex B: Revision history

8 Figures Figure 2-1 RESET Classes Figure 6-1 Planning with Feasibibility study sequence diagram Figure 6-2 Direct planning sequence diagram Figure 6-3 Reservation planning sequence diagram Figure 7-1 Operation Metadata example Figure 7-2 Operation URL example Tables Table 2-1 RESET Classes Table 5-1 Contents of data dictionary tables Table 7-1 Capabilities URL Table 7-2 Capabilities HTTP methods Table 7-3 Capabilities Error Handling Table 7-4 Procedures URL Table 7-5 Procedures URL parameters Table 7-6 Procedures HTTP methods Table 7-7 Procedures HTTP methods parameters Table 7-8 Procedures Error handling Table 7-9 Feasibility URL Table 7-10 Feasibility URL parameters Table 7-11 Feasibility HTTP methods Table 7-12 Feasibility HTTP methods parameters Table 7-13 Feasibility Error handling Table 7-14 Planning URL Table 7-15 Planning URL parameters Table 7-16 Planning: Results not available Table 7-17 Planning: Segment cancellation Table 7-18 Planning HTTP methods Table 7-19 Planning HTTP methods parameters Table 7-20 Planning Error handling Table 7-21 Reservation URL Table 7-22 Reservation URL parameters Table 7-23 Reservation HTTP methods Table 7-24 Reservation HTTP methods parameters Table 7-25 Reservation Error handling Table 8-1 Core operations Table 8-2 Feasibility operations Table 8-3 Planning operations Table 8-4 Feasibility planning operations Table 8-5 Reservation operations Table 8-6 Cancellation operations Table 10-1 Planning task status description Table 10-2 Planning segments status description Table 14-1 Conformance classes

9 Abstract This OGC Best Practices document specifies the interfaces, bindings, requirements and conformance classes that enable complete workflows for the tasking of sensor planning services for Earth Observation (EO) satellites. In fact it provides the interfaces for supporting the following EO sensor planning scenarios: Planning future acquisitions with feasibility study, Direct planning of future acquisitions, Reservation of planning for future acquisitions. This specification includes a comprehensive list of sensor options and tasking options derived from the parent specification OGC [NR22] which gathered inputs from several Satellite Agencies and Operators: ESA EUMETSAT CNES DLR CSA Airbus Defence & Space This document is based on the standard: OGC , Sensor Planning Service Interface Standard 2.0 Earth Observation Satellite Tasking Extension, version which was initially produced during the ESA HMA (Heterogeneous Missions Accessibility) initiative [OR1] and related projects. With respect to the parent specification this Best Practice document proposes the following changes: Replaces SOAP with REST for service encoding. This affects not only the way the service is implemented but also the way the standard is presented and described. In fact, basing the standard on REST implies that the service has to be described in terms of resources and methods applied on them whilst in SOAP services, the description is focusing on operations and in fact the OGC [NR22] is structured in Web Service operations. Usage of OpenSearch Description Documents as an alternate method for describing sensors and tasking Options ( 7.3.2). This specification uses the sensors and tasking options model already described in the OGC [NR22] standard but defines an additional method for describing sensors and tasking options within OpenSearch Description Documents based on the OGC [NR23]. Actually this part of the specification refers to the OpenSearch Extension for Earth Observation Satellite Tasking. 9

10 Keywords The following are keywords to be used by search engines and document catalogues. ogcdoc, OGC document, sps, eo-sps, earth observation, eo, hma-s, sensor, planning, satellite, tasking, RESTful 10

11 Preface This OGC Best Practices document specifies the interfaces for issuing EO satellite tasking sensor planning in different scenarios (e.g. feasibility, planning, etc.) and with a lot of flexibility (feasibility options, planning options). Due to the number of supported feasibility and planning scenarios covering different and also alternative needs, then a number of s Classes have been defined collecting the specific requirements a conformant implementation has to comply with. In parallel, a number of Conformance Classes have been defined that regroup all the tests that a server has to pass in order to claim compliance with the corresponding Class. A server can comply with some of the Classes as it is not required to implement all classes. Implementers shall be aware that: Not all scenarios ( Classes) shall be implemented, only the Core one plus the others that are necessary for their use cases (see 0). However a server has to specify the supported Conformance Classes as evidence of the provided functionality. If tasking options are supported, then the implementation has to use a sub-set of the already identified scenarios unless they are not fitting with their needs; in that case an application profile listing the new scenarios to be modeled with SWE Common 2.0, has to be defined and implemented. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights. Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation. Submitting organizations The following organizations submitted this Document to the Open Geospatial Consortium (OGC): Airbus Defence & Space European Space Agency Spacebel s.a. 11

12 Submitters All questions regarding this submission should be directed to the editor or the submitters: Name Nicolas FANJEAU Sebastian ULRICH Affiliation Airbus Defence & Space Airbus Defence & Space 1. Scope The scope of this Best Practice document is to describe the interfaces for providing an interoperable access to the tasking capabilities of various types of earth observation systems. The interfaces can be used 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 on means of obtaining the data collected by the requested task. It allows the preparation of different types of operation: GetCapabilities: describes abilities of the specific server implementation. DescribeSensor: describes a sensor. DescribeTasking: format of the tasking requests that can be submitted. GetSensorAvailibility / GetStationAvailibility: check the availability of a sensor or a ground station. GetFeasibility: perform the feasibility analysis process. Submit: submit a planning task described by the Tasking Parameters to the mission planning system. SubmitSegmentByID: submit a planning task created from the results of a Feasibility Analysis. To verify whether the submission has been successfully completed and to retrieve / manage the results, dedicated operations have to be called: GetStatus: status of a planning task. GetTask: results of a Feasibility Study or of a submitted planning task. DescribeResultAccess: access to submitted products ready for download. Cancel: cancel of an already submitted planning task. Validate: manually validate an acquisition once it has been acquired. 12

13 A set of additional information permits the implementation of a reservation system. It includes the following operations: Reserve: reserve a task before submitting it. Update: change the parameters of a reserved task. Confirm: confirm the submission of a reservation and enter it to the mission planning system. Tasking and Sensors Options are declared and set in two different formats: Tasking and Sensors Options in Canonical XML format ( 8.1.4): the format defined in the parent Standard OGC [NR22], represented by the eosps:taskingparameters and swes:proceduredescriptionformat elements which are complex structure regrouping options defined via SWE Common [NR20] and EO- SPS [NR22]. Tasking and Sensors Options in OpenSearch Description Document format ( [NR23]): Tasking and sensors options can be declared in the OpenSearch Template URL similar to the other query parameters. However options elements in Canonical XML format are embedded as foreign mark-up in the OpenSearch Description Document in order to provide the information that a simple template parameter is not able to describe e.g. type, allowed values, default values etc. This specification uses REST for defining its service interface: actually it is the reengineering of the standard (replacing SOAP by REST): OGC , Sensor Planning Service Interface Standard 2.0 Earth Observation Satellite Tasking Extension, version Additionally to REST replacement of SOAP, a further modification has been done: Removed support for asynchronous notifications: in fact this document focuses on Web Applications in general and on REST approach in particular whilst the asynchronous message exchange is more of a SOAP Web Service Oriented function. 13

14 The REST encoding also affects the way the document is presented. In fact according to REST philosophy, the service is described in terms of Resources and Methods applied on them rather than in terms of operations as the parent specification did. From the Resource perspective, this Best Practice document defines the following: Service Metadata ( 7.2): which is the resource document returning the description of the service capabilities, supported operations, supported collections and other service capabilities. Procedures ( 7.3): which is the resource document returning the description of the sensors offered by the server. Ground Stations ( 7.5): which is the resource document returning the description of the ground station. Feasibility ( 7.4): which is the resource to perform a Feasibility Analysis on a given sensor or type of sensor (optical, SAR, etc.), as well as accessing its results. Reservation ( 7.6): which is the resource allowing a user to reserve a task before submitting it. Planning ( 7.5): which is the resource allowing a user to submit a planning task, access its status, its results, as well as cancelling a task. For each resource, the document specifies: The definition, via XML schema, of the various items composing the resource. The HTTP Methods available (according to the REST Uniform Interface concept) e.g. GET, POST, PUT and DELETE. The HTTP URLs for accessing the resource. The connections with the other resources (according to the REST Connectedness concept). The section 6 provides a more detailed description of the REST approach for this specification and the mapping with the parent Standard document. Due to the flexibility of the protocol, several conformance classes have been defined, each addressing a specific use case. A compliant implementation does not have to comply with all of these classes but with at least Core class. Compliance to the remaining classes is optional. 14

15 2. Conformance This Best Practice document defines the interfaces and the requirements for implementing a server supporting the feasibility and planning for Earth Observation satellite sensors. Therefore different Classes have been defined specifying the requirements for implementing the feasibility and planning processes. Moreover additional classes have been considered for defining optional functions that might be implemented by servers having extended functionality. The complete list of s Classes is listed below: Core, which specifies the minimum behaviour that all RESET servers shall implement. It includes the support of the operations Tasking description, Sensor description or Task description. Feasibility, which specifies the additional requirements a RESET server has to implement for performing a feasibility analysis process. Planning, which specifies the additional requirements a RESET server shall implement for performing a planning process. Feasibility Planning, which specifies the additional requirements a RESET server shall implement for performing a feasibility analysis process and then submitting the subsequent results. Reservation, which specifies the additional requirements a RESET server shall implement for performing a feasibility analysis process and then submitting the subsequent results. Cancellation, which specifies the additional requirements a RESET server shall implement for performing the cancellation of planning or reservation processes. The following diagram shows the relationships between the defined Classes. Figure 2-1 RESET Classes 15

16 The inheritance relationship between the different classes represents the inheritance of all requirements from the super class. E.g.: The Feasibility class defines its specific requirements and includes the requirements defined in the Core class. Hence a Server claiming compliance to the Feasibility class has to comply with all the Feasibility and Core class requirements. The following table reports: o The Class name, o The URI, o The dependency with other requirements classes. Table 2-1 RESET Classes Class Core Class URI Dependency Feasibility Core Planning Core Feasibility Planning Core Feasibility Planning Reservation Core Planning Cancellation Core Planning The root path of all s and conformance test URIs defined in this document is: Conformance with this Best Practice document shall be checked using all the relevant tests specified in Annex A: Conformance Class Abstract Test Suite (Normative) of this document. The framework, concepts, and methodology for testing as well as the criteria to be achieved in order to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site

17 In order to conform to this OGC interface standard, a software implementation shall choose to implement at least Core class and optionally the other classes. A server that complies only with the Core class is a server supporting feasibility and planning based on identified EO sensors. All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified. 17

18 3. 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. 3.1 Normative references [NR1] IETF RFC4287, ATOM The Atom Syndication Format [NR2] IETF RFC 3066, Tags for the Identification of Languages [NR3] IETF RFC 3339, Date and Time on the Internet: Timestamps [NR4] IETF RFC 5988, Web Linking [NR5] OpenSearch, OpenSearch Specification, version 1.1 draft 5. [NR6] OpenSearch, OpenSearch Geo Extension, version 1.0 draft 2. [NR7] OpenSearch, OpenSearch Time Extension, version 1.0 draft 1. [NR8] OpenSearch, OpenSearch Parameters Extension, version 1.0 draft 2. [NR9] OASIS, SearchRetrieve: Part 4. APD Binding for OpenSearch, version [NR10] OGC r4, New OGC Document Template Draft. [NR11] OGC r2, Guidance to Editors and Authors of OGC Documents that use the OGC Standards document template, version [NR12] OGC r11, Policy Directives for Writing and Publishing OGC Standards: TC Decisions [NR13] OGC r3, The Specification Model - A Standard for Modular specifications, version [NR14] OGC , OGC Web Services Common Specification, version [NR15] OGC r9, OWS Common Implementation Specification, version [NR16] OGC r4, OGC Implementation Standard for Geographic information Simple feature access - Part 1: Common architecture, version [NR17] OGC r4, Earth Observation Metadata profile of Observations & Measurements, draft [NR18] OGC r2, OpenSearch Earth Observation product Extension [NR19] OGC r6, OpenSearch GeoSpatial and Temporal Extensions

19 [NR20] OGC r1, SWE Common Data Model Encoding Standard, version [NR21] OGC , Sensor Planning Service Implementation Standard, version [NR22] OGC , Sensor Planning Service Interface Standard 2.0 Earth Observation Satellite Tasking Extension, version [NR23] OGC , OpenSearch Extension for Earth Observation Satellite Tasking, version [NR24] OGC , OGC SWE Service Model Implementation Standard, version [NR25] OGC , RESTful Encoding of Ordering Services Framework For Earth Observation Products, version Other references [OR1] ESA, TM-21, Design Methodology, Architecture and Use of Geospatial Standards for the Ground Segment Support of Earth Observation Missions

20 4. Terms and Definitions This document uses the terms defined in Sub-clause 5.3 of [OGC r8], 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. For the purposes of this document, the following additional terms and definitions apply. earth observation satellite Artificial spacecraft specifically designed to observe the earth from orbit, often using sensors that are sensitive to some part of the electromagnetic spectrum. 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. OpenSearch Draft specification for web search syndication, originating from Amazon's A9 project and given a corresponding interface binding by the OASIS Search Web Services working group. 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]. procedure oriented architectural style Platform-independent design approach that is focused on operations, their parameters and their results, that can be defined in an abstract level specification. Concrete platform dependent specifications can be derived from the abstract level, allowing, for example, KVP or SOAP messaging. requirement Something that is necessary in advance. resource oriented architectural style Platform-independent design approach that is focused on resources, representations and actions, that can be defined in an abstract level specification. Concrete platform dependent specifications can be derived from the abstract level, allowing, for example, a RESTful architecture. state Condition that persists for a period. 20

21 Task Conceptual resource that represents an SPS assignment. It includes the (possibly empty) set of tasking parameters. Tasking Parameterizing an asset; can be done by sending one or more tasking requests. Tasking request Request with certain tasking semantics that contains tasking parameters. Tasking Parameter Parameter that has an influence on the parameterization of an asset. URL component Text contained after the context path between two forward slashes /, that are not placed between two matching parentheses (...), and before any question mark character?. URL component key Text contained in a URL component that comes before an opening parenthesis (. URL component value Text contained in a URL component that is enclosed between the first opening parenthesis ( and the last closing parenthesis ) in the component. Example In the components are as follows: Context Path: URL Components: component1, componentkey(componentvalue) URL Component Keys: component1, componentkey URL Component Values:componentValue 21

22 5. Conventions This sections provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document. 5.1 Abbreviated terms Some of the abbreviated terms listed in sub clause 5.1 of the OWS Common Implementation Specification (OGC ) apply to this document, plus the following abbreviated terms. API ATM COTS CQL CRS DCE DCP DDS EC EO EO-SPS ESA GCM GMES GML HMA Application Program Interface Atmospheric Commercial Off The Shelf Common Query Language Coordinate Reference System Distributed Computing Environment Distributed Computing Platform Data Dissemination Service European Commission Earth Observation Earth Observation Satellite Tasking Extension for the SPS 2.0 Standard European Space Agency GMES Collaborative Mission Global Monitoring for Environment and Security Geographic Markup Language Heterogeneous Mission Accessibility HMA-AWG HMA Architecture Working Group HTTP IETF ISO LTDP Hypertext Transport Protocol Internet Engineering Task Force International Organisation for Standardisation Long Term Data Preservation 22

23 O&M OGC OSDD OASIS OPT RESET REST ROSEO RSS SAR SensorML SPS SWE SWS UML URI URL URL UUID URN UTF-8 WSDL W3C WKT XML Observations & Measurements Open Geospatial Consortium OpenSearch Description Document Organisation for the Advancement of Structured Information Standards Optical RESTful encoding of Sensor Planning Service for Earth Observation satellite Tasking Representational State Transfer RESTful Encoding of Ordering Services Framework for Earth Observation Products Rich Site Summary Synthetic Aperture Radar Sensor Model Language Sensor Planning Service Sensor Web Enablement Search Web Services Unified Modelling Language Uniform Resource Identifier Uniform Resource Locator Uniform Resource Name Universal Unique Identifier Uniform Resource Name Unicode Transformation Format-8 Web Service Definition Language World Wide Web Consortium Well Known Text extensible Markup Language 23

24 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 sub-clause 5.2 of OGC Used parts of other documents This document uses significant parts of document OGC To reduce the need to refer to that document, 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%). 5.4 Platform-neutral and platform-specific standards As specified in Clause 10 of OGC Abstract Specification Topic 12 OGC 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. 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). 5.5 Data dictionary tables 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. The UML model data dictionary is specified herein in a series of tables. 24

25 Table 5-1 Contents of data dictionary tables Column title Names (left column) 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 sub-clause of [OGC ]. Some names in the tables may appear to contain spaces, but no names contain spaces. Definition (second column) Data type and value (third column) or Data type 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). (if are no second items are included in rows of table) 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. Multiplicity and Normally contains two items: use (right or fourth column) The mandatory first item specifies the multiplicity and optionality of this parameter in this data structure, either One (mandatory), One or more or (mandatory), Zero or one (optional), or Zero or more (optional). Multiplicity (if are no second items are included in rows of table) 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? 25

26 6. RESTful encoding of Sensor Planning Service for Earth Observation satellite Tasking (RESET) overview As highlighted in the introduction sections, this document provides a simplified and RESTful encoding of the parent specification Earth Observation Satellite Tasking Extension for SPS 2.0 [NR22]. This is a RESTful specification and so it is described in terms of resources. However it is derived from [NR22], which is a SOAP Web Service and thus is both operations centric and following an RPC style Both techniques have almost the same functionality. This then means that this specification can be identically described from the two different points of view. This section summarizes this specification from both a Resource point of view and from an RPC style point of view and explains how they relate to each other. 6.1 RPC view of RESET RESET deals with the following information items: Sensor description, provides descriptions of the sensors that can be tasked. These descriptions can be provided in multiple OGC standards, including SensorML, SOS, etc. Tasking requests, are the requests to be sent. These contain all the information to configure the acquisition of a sensor, or set of sensors; Feasibility Study, describes the results of a feasibility request. This preliminary process allows the calculation of the possibilities offered by a given sensor to perform a given tasking request. This structure contains a list of Segments, which represent a given acquisition. Programming Status, describes the results of the submission of a task. It describes the current status of the Segment which represents a single acquisition. From RPC perspective, this specification is composed of the following operations: GetCapabilities: allows a client to request and receive a service metadata (or Capabilities) document that describes the abilities of the specific server implementation. DescribeSensor: allows a client to request the complete description of a sensor, including the modes it can perform, choosing between the various descriptions formats described in the GetCapabilities. DescribeTasking: this operation allows a client to get the format of the tasking requests that can be submitted to the server. This includes : o Area Of Interest (AOI): the area of the globe to be tasked. Extra information includes the kind of AOI (polygon, circle, etc.), the format of the coordinates, etc. o Time Of Interest (TOI): the periods that are to be tasked, with the format of these dates (e.g. ISO 8601). o Acquisition type : additional information that includes instrument (sensor) modes, acquisition angles, validation parameters such as cloud or snow coverage, 26

27 GetSensorAvailability / GetStationAvailability: these operations allow a user to check the availability of a sensor or a ground station. GetFeasibility: this operation requests the feasibility analysis process to be performed. The Segments provided by this function can then be submitted by the SubmitSegmentByID operation. Its results are also available through the GetTask operation. Submit, allows the submission of a planning task described by the Tasking Parameters to the mission planning system. SubmitSegmentByID, allows a user to submit a planning task created from the results of a Feasibility Analysis. These operations are asynchronous meaning that they perform the submission of the task to the mission planning system and return a summary containing the status of the Segments that have been submitted. To verify whether the submission has been successfully completed and to retrieve / manage the results, dedicated operations have to be called. GetStatus, allows the retrieval of the status of a planning task. GetTask, allows the retrieval of either the results of a Feasibility Study or of a submitted planning task. DescribeResultAccess, allows access to the submitted products ready for download once they have been acquired, downloaded to the Ground Station and processed as required. Cancel cancels a previously submitted planning task. This operation is a two-part process : the first call will evaluate the possibility of the cancellation and return a status report showing which segments can, or cannot, be cancelled, along with the time this report will be valid. The second call will then validate the cancellation of the segments that are cancellable. Validate allows the user to manually validate an acquisition once it has been acquired. Indeed, several attempts are sometimes needed for earth observation systems to acquire satisfactory data for an area of the earth surface. For instance, optical acquisitions are subject to cloud cover that can prevent clear imaging of the region of interest. In this case new acquisitions are performed until the region of interest is imaged properly. This operation provides a means to confirm that the last acquisition fits the user s needs. A set of additional information that allows the implementation of a reservation system. It includes the following operations : o Reserve that allows the user to reserve a task before submitting it, for example if the user wants to perform another feasibility study before confirming. o Update allows the changing of the parameters of a reserved task. o Confirm allows a user to confirm the submission of a reservation and enter it to the mission planning system. 27

28 6.2 Resource view of RESET From the Resource perspective, this specification is composed of the following resources: Service Metadata: Describes the service capabilities, supported operations, supported collections and other service capabilities. The following HTTP methods are used: o GET: returns the capabilities of the system. Procedures: Describes the sensors offered by the server. The following HTTP methods are used: o GET /procedures/{sps:procedure}/{swes: proceduredescriptionformat?}: equivalent to the DescribeSensor operation. Allows the retrieval of the capabilities of a sensor in the given format (providing it is used by the server). o GET /procedures/{sps:procedure}/tasking: equivalent to DescribeTasking. o GET /procedures/{sps:procedure}/availability: equivalent to GetSensorAvailibility. Ground Stations: Retrieves information about a ground station. o GET /groundstation/{eosps:station}: Describes the ground station. o GET /groundstation/{eosps:station}/availability: equivalent to GetStationAvailability. Feasibility: Perform a Feasibility Analysis on a given sensor or type of sensor (optical, SAR, etc.), as well as accessing its results. The following HTTP methods are used : o POST /feasibility: equivalent to GetFeasibility. The content of the request shall be based on the response provided by the DescribeTasking operation. o POST /feasibility/{sps:taskid}:equivalent to SubmitSegmentByID in the RPC view of RESET 6.1 above. The method submits a set of segments that have been produced by a Feasibility Analysis. o GET /feasibility/{ sps:taskid}: equivalent to GetTask. The method retrieves the results of a Feasibility Analysis. Reservation: allows the user to reserve a task before submitting it. The following HTTP methods are used : o POST /reservation: equivalent to the Reserve operation. Allows the user to reserve a planning task for a certain time. o POST /reservation/{ sps:taskid}: equivalent to the Confirm operation. Allows the user to submit a planning task that was previously reserved. o PUT /reservation{sps:taskid}: equivalent to the Update operation. Allows the user to apply some modifications to a previously reserved task. Planning: allows the user to submit a planning task, accessing its status, its results, as well as cancelling a task. The following HTTP methods are used: o POST /planning: equivalent to the Submit operation in the RPC view of RESET. The method provides a means to submit a planning task. The content of the 28

29 request shall be based on the response provided by the DescribeTasking operation. o GET /planning/{ sps:taskid}: equivalent to the GetStatus operation. Checks the status of a task. o GET /planning/{ sps:taskid}/segments: equivalent to the GetTask operation. Retrieves a complete report of the task, with description of all segments submitted and their status. It should also be used prior to a Cancel request in order to assess the possibility of the cancellation. o POST /planning/{ sps:taskid}/segments/{ eosps:segmentid}: equivalent to the Validate operation. Allows the user to validate an acquisition as corresponding to the user s needs. o GET /planning/{ sps:taskid}/results: equivalent to DescribeResultAccess. o DELETE /planning/{ sps:taskid}: equivalent to the Cancel operation. Cancels a selected task. 6.3 Essential use cases The scenarios described here demonstrate the three basic use cases that perform the submission of a planning task to a (set of) mission planning system(s). In these scenarios, the following entities are specified: RESET client: the client application or user that will send the requests to the client. RESET server: the server application that will handle those requests. Download Server: the server location where the user will be able to download the results of the process. 29

30 6.3.1 Planning with feasibility study The typical scenario is: The client gets the capabilities of the server using the GetCapabilities operation (GET /). Selects the sensor to be tasked from the GetCapabilities and optionally (if more information is required) the DescribeSensor methods (GET /procedures/{sps:procedure}/{swes:sensordescriptionformat?}). The user then requests the format of the Tasking parameters needed to submit a task, through the DescribeTasking operation (GET /procedures/{sps:procedure}/tasking). Then this structure is filled in on the client side, allowing the user to choose the area of interest, the time of interest, as well as other parameters such as the instrument mode. This structure is then sent to the server as part of a GetFeasibility request (corresponding to POST /feasibility). This will return a set of segments representing acquisitions that fulfill the given tasking parameters. The user will then assess these results in order to choose the segments required to be submitted for acquisition. These segments will then be submitted using the SubmitSegmentByID (POST /feasibility/{taskid}). This will start a new planning task. After that, the following events are possible: o The user requests the status of the task using the GetStatus operation (GET /planning/{taskid}), or the complete description of the task using the GetTask operation (GET /planning/{taskid}/segments). o The user cancels the task using the Cancel operation (DELETE /planning/{taskid}). Once the task is finished, which corresponds to all segments involved begin acquired, the user can do the following: o Get the data describing a given segment, through the GetTask (GET /planning/{taskid}/segments), and the results with the DescribeResultAccess operation (GET /planning/{taskid}/results). This will provide the means to connect to the Download Server in order to get the acquired products. After assessing these results, validate a given segment using the Validate (POST /planning/{taskid}/segments/{segmentid}) operation. 30

31 sd FeasibilityPlanning RESET Client RESET Server Download Server GetCapabilities() opt DescribeSensor() DescribeTasking() FillInRequest() GetFeasibility(taskingParameters) SubmitSegmentByID(taskID, segments) opt getstatus(taskid) opt cancel(taskid) gett ask(taskid) describeresultaccess(taskid) opt validate(taskid, segmentid) downloadresults() Figure 6-1 Planning with Feasibility study sequence diagram 31

32 6.3.2 Direct planning The typical scenario is: The client gets the capabilities of the server using the GetCapabilities operation (GET /). Selects the sensor to be tasked from the GetCapabilities and optionally (if more information is required) the DescribeSensor methods (GET /procedures/{sps:procedure}/{swes:sensordescriptionformat?}). The user then requests the format of the Tasking parameters needed to submit a task, through the DescribeTasking operation (GET /procedures/{sps:procedure}/tasking). Then this structure is filled in on the client side, allowing the user to choose the area of interest, the time of interest, as well as other parameters such as the instrument mode. This structure is then sent to the server as part of a Submit request (corresponding to POST /planning). This will return a set of segments representing the acquisitions that have been submitted to fulfill the given request. This will start a new planning task. After that, the following events are possible: o The user requests the status of the task using the GetStatus operation (GET /planning/{taskid}), or the complete description of the task using the GetTask operation (GET /planning/{taskid}/segments). o The user cancels the task using the Cancel operation (DELETE /planning/{taskid}). Once the task is finished, which corresponds to all segments involved begin acquired, the user can do the following: o Get the data describing a given segment, through the GetTask (GET /planning/{taskid}/segments), and the results with the DescribeResultAccess operation (GET /planning/{taskid}/results). This will provide the means to connect to the Download Server in order to get the acquired products. After assessing these results, validate a given segment using the Validate (POST /planning/{taskid}/segments/{segmentid}) operation. 32

33 sd DirectPlanning RESET Client RESET Server Download Server getcapabilities() opt describesensor() describetasking() fillinrequest() submit(taskingparameters) opt getstatus(taskid) opt cancel(taskid) gett ask(taskid) describeresultaccess(taskid) opt validate(taskid, segmentid) downloadresults() Figure 6-2 Direct planning sequence diagram 33