HMA Follow On Activities Task 2: Feasibility Analysis Service (Sensor Planning Service) Final Presentation 20 July 2011 Reuben Wright, Deimos Space

Overview Objectives Achievements Document Deliverables Specifications Software Future work Demonstration

Objectives I25. The completion of the work initiated in the HMA contract, on feasibility analysis service at the moment specified as OpenGIS® Sensor Planning Service Application Profile for EO Sensors OGC 07-018 to I25.1 specify unambiguously the interactions, taking into account the issues already identified in current version of the document Published and adopted as Earth Observation Extension for Sensor Planning Service (EO SPS 2.0) - 09-000 I25.2 The alignment of the specification with the evolving OGC “SWECommon” and SPS 2.0 Active work to complete all three of these “supporting” specifications. All published and adopted

Objectives I25.3 Completely specify all the operations: GetCapabilities, DescribeTasking, GetFeasibility, Submit, DescribeResultAccess All these and GetStatus, Reserve, Confirm, DescribeSensor, GetSensorAvailability, Validate and WS-Notifications I26. The design, development and testing of an open source Sensor Feasibility Reference Environment to be used by the Agency as a reference server and client to be used both for the testing and demonstration of the relevant specification Both Server and Client developed, tested and released open source. Demonstrations later

Objectives I27 – I29. The Sensor Feasibility Reference Environment shall support optical and radar missions, support systematic instruments (see e.g. MERIS, atmospheric), be configurable to simulate the presence of at least 4 missions (2 optical, 2 radar), sensor unavailability, station unavailability and weather conditions. Linux based. There are 4 missions, with MERIS swath supported. Server simulates all unavailabilities, and the responses (eg a failure due to weather) are displayed by the Client. URL based web admin and local configuration files I30. The definition of an abstract test suite and an executable test suite to be executed via the OGC TEAM engine Full ATS complementing the requirement classes. ETS to the extent possible within OGC TEAM Engine

Deliverables FP

Specifications Three specifications were written and gained OGC adoption: sweCommon 2.0 (Data Model and Service Model) Sensor Planning Service 2.0 EO Extension for Sensor Planning Service 2.0 Compliant with the OGC Specification Model – A Standard for Modular Specification - OGC 08-131r3

Published as OGC 08-094 and OGC 09-001 sweCommon FP Published as OGC 08-094 and OGC 09-001 Comprises SWE Common Data Model and SWE Common Service Model. Specifications published at: http://www.opengeospatial.org/standards/swecommon http://www.opengeospatial.org/standards/swes Schemas published at: http://schemas.opengis.net/sweCommon/2.0/ http://schemas.opengis.net/swes/2.0/ Used by: Sensor Planning Service, Ordering Service, Processing Service

Provides a set of Data Models SWE Data Model – OGC 08-094 FP Provides a set of Data Models Low level data models for exchanging sensor related data Allow applications and/or servers to structure, encode and transmit sensor datasets Structures are self describing Structures can be linked to semantic definitions

SWE Service Model – OGC 09-001 FP Provides the following packages of datatypes and operations Contents – data types for sensor services Notification – data types for notification capabilities, and also definition and encoding of SWES events Common - common data types for other packages Common Codes – commonly used lists of codes with semantics DescribeSensor – operation to retrieve sensor metadata UpdateSensorDescription – operation to modify sensor description InsertSensor – operation DeleteSensor – operation

Sensor Planning Service 2.0 Specifications published at: http://www.opengeospatial.org/standards/sps Schemas published at: http://schemas.opengis.net/sps/2.0/ Provides a set of operations to: Query about the capabilities of a sensor and how to task it Determine the feasibility of a sensor planning request Submit and reserve/commit a request Find out the status of a request Update or cancel such a request Request information about access to the data collected

Sensor Planning Service 2.0 Operations 1/2 FP Mandatory Interface (Operation Group) 12

Sensor Planning Service 2.0 Operations 2/2 FP Optional Interfaces (Operation Group) 13

EO Sensor Planning Service 2.0 Specifications published at: http://www.opengeospatial.org/standards/sps Schemas published at: http://schemas.opengis.net/sps/2.0/ Provides an extension to SPS specifically for EO: New Operations to support the way the industry works Defined and registered common parameters to aid interoperability New operations to: Validate acquisitions made in response to a task Find long term information on the availability of a sensor Submit tasking requests related to individual segments of a task

EO Sensor Planning Service 2.0 Parameters Tasking Parameters for all missions (eg. how to specify Region and Time of interest) for Optical (eg. MinLuminosity) for Radar (eg. polarizationMode) Validation Parameters for Optical (eg. MaxCloudCover) for Radar (eg. maxNoise) Parameters are in OGC registry Includes names, datatypes and semantics Allows reuse Allows RDF/Ontology support to link semantics to other definitions

EO Sensor Planning Service 2.0 Executable Test Suite Executable Test Suite written in CTL In the EO SPS Abstract Test Suite there are 31 core tests: Have implemented 23 of these tests as a first release ETS. Any limitations are documented in the test scripts. The parts not implemented are because the specification says it is: to be a manual check or to run a different ETS (for the core SPS), or require TEAM Engine to be able to handle asynchronous testing.

EO SPS 2.0 Executable Test Suite - Reusable function FP Provides ability to modify a provided set of parameters programatically. This means a “base” request can be edited to create the various test messages. <ctl:call-function name="ModifyRequest"> <ctl:with-param name="Request" select="."/> <ctl:with-param name="Modifications"> <Element name="procedure" namespace="http://www.opengis.net/sps/2.0" text="{$sensorID}"/> <Element name="GetFeasibility" namespace="http://www.opengis.net/sps/2.0"> <swes:extension> <eo:FeasibilityLevel>COMPLETE</eo:FeasibilityLevel> </swes:extension> </Element> </ctl:with-param> </ctl:call-function>

EO SPS 2.0 Improvements from 0.9.5 All operations synchronous, but compatible with asynchronous processes Based on sweCommon 2.0 Choice Optional values / sections Nil values Use of sweCommon simplified and optimized Description of parameters not in GetFeasibility and Submit requests anymore (only in DescribeTasking) Parameters value can be sent using XML, binary or ASCII, optionally without tags Progress Report section used in several operations

EO SPS 2.0 Improvements from 0.9.5 WS_Notification No need for server on client side (WS-Addressing is a big issue in case of firewall) Any number of subscribers Subscriptions can be cancelled and/or modified at any time Notifications can be sent to any support (sms, email, etc.) New operations (Reserve-Confirm, Validate, GetSensorAvailability) Matches the OGC Specification Model including linked Requirement and Conformance Classes

SFRE Development (SF Client and SF Server) Fully working reference implementations – client and server All the EO SPS Operations have been successfully implemented: GetCapabilities, GetSensorAvailability DescribeSensor, DescribeTasking GetFeasibility, Submit Cancel, Update, Validate Reserve, Confirm GetStatus, DescribeResultAccess SF server also implements Notifications Code is Open Source: http://code.google.com/p/sensor-feasibility-client/ http://code.google.com/p/sensor-feasibility-server/

Other (non-Open Source) code SPOT Image SPS Server Deployed at: http://ws.spotimage.com/axis2/services/SPS_v2.0.4 SF Client configured to use it (as well as SF Server) Ad hoc SF Client testing and ETS testing has been carried out Not Open Source. Earth Explorer CFI Used in SF Server, with the libraries included in the delivered code. Collection of multiplatform precompiled C libraries for timing, coordinate conversions, orbit propagation, satellite pointing calculations, and target visibility calculations. SF Server does not include the source code of the software. Library is provided under the Earth Observation CFI Licence Terms and Conditions - http://eop-cfi.esa.int/CFI/EOCFI_LTC.html

DecribeSensor responses Future Work DecribeSensor responses SensorML document containing information about the EO instrument being tasked and the satellite platform that carries it. This profile will ideally build on a generic “discovery profile” of SensorML to which we add more specific metadata for EO sensors and platforms Make sure to reference ISO 19115 descriptions of data collections, so that there will be consistency  Orchestration between services End to End workflows (eg within GSCDA) Extension of such work as HMA Cookbook and various documents covering service interactions (eg SPS – Ordering, SPS – WCS) Promotion, extension, integration of reference software

SF Feasibility Client basic UI Demonstration SF Feasibility Client basic UI Globe, layers, past requests, ability to specify acquisition details Parallel requests to SF Server, SPOT Server GetFeasibility / Submit Display of server responses Text of responses and Footprints plotted on the globe Simulated acquisitions (servers on “fast forward”) Visual status display in SF Client GetStatus Ability to find details of the products DescribeResultsAccess Links to: FTP, HTTP, Ordering Service, Web Catalogue Service More sophisticated workflow possible Reserve – Confirm - Validate

Thanks for listening Questions Any Questions? reuben.wright@deimos-space.com