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

Open Source Development Achievements Deliverables Specifications Executable Test Suite Open Source Development SF Client SF Server Demonstrations

Deliverables

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 Modular Specification Model used

Published as OGC 08-094 and OGC 09-001 sweCommon Published as OGC 08-094 and OGC 09-001 Comprises SWE Common Data Model and SWE Common Service Model. Specifications published at: http://portal.opengeospatial.org/files/?artifact_id=41157 http://portal.opengeospatial.org/files/?artifact_id=38476 Schemas published at: http://schemas.opengis.net/swes/ http:// … Used by: Sensor Planning Service 2.0, Order Handling Service … …

Provides a set of Data Models SWE Data Model – OGC 08-094 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 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://portal.opengeospatial.org/files/?artifact_id=38478 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 Mandatory Interface (Operation Group) 9

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

EO Sensor Planning Service 2.0 Specifications published at: http://portal.opengeospatial.org/files/?artifact_id=38478 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 Provides Tasking Parameters for all missions (eg. how to specify Region and Time of interest) for Optical (eg. MinLuminosity) for Radar (eg. polarizationMode) Provides 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 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>

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 Reserve, Confirm GetStatus, DescribeResultAccess Validate SF server also implements Notifications Code is to be released as Open Source [Question : More detail useful? Or just show demo?]

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

What Next To Do ...

Demonstration To Do Summary of steps/storyboard... Would this perhaps be better as a separate presentation (covering all the tasks)?

Thanks for listening Questions Any Questions before SF Client and SF Server Demonstration? reuben.wright@deimos-space.com

Extra Slides - if there any questions on the technical details of standards or development/design. SF Client UI (final UI in Operations Manual) SPS 2.0 operations EO Extension for SPS 2.0 parameters and operations Sensor Feasibility Reference Environment architecture

SF Client screenshots SF Client UI 3D Map Sensor selection Tasking Parameters (sent to SF Server) Display of Server responses (Feasibility Analyses)

SF Client screenshots

SF Client screenshots

SF Client screenshots

SF Client screenshots

SF Client screenshots

SF Client screenshots

SF Client screenshots

SF Client screenshots

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

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

EO Extension for Sensor Planning Service 2.0 SPS Tasking Parameters for all missions 32

EO Extension for Sensor Planning Service 2.0 SPS Tasking Parameters for all missions 33

EO Extension for Sensor Planning Service 2.0 SPS Tasking Parameters for all missions 34

EO Extension for Sensor Planning Service 2.0 SPS Tasking Parameters specific to Optical and Radar 35

EO Extension for Sensor Planning Service 2.0 Validation parameters specific to Optical and Radar 36

EO Extension for Sensor Planning Service 2.0 SPS Feasibility Study Parameters 37

EO Extension for Sensor Planning Service 2.0 SPS Status Parameters 38

EO Extension for Sensor Planning Service 2.0 New Operation: GetSensorAvailability 39

EO Extension for Sensor Planning Service 2.0 New Operation: Validate 40

EO Extension for Sensor Planning Service 2.0 New Operation: SubmitSegmentByID Response is classical SPS SubmitResponse 41

EO Extension for Sensor Planning Service 2.0 Additional Notification Topics SegmentPlanned SegmentAcquired SegmentValidated SegmentCancelled SegmentFailed 42

SF Client Architecture WorldWind Google Web Toolkit Apache Tomcat Web Browser Web Server MySQL DB WorldWind Google Web Toolkit Apache Tomcat SPS Library

SF Server Architecture Earth Explorer Mission CFI Apache Axis SPS Controller Notifications Planning System Earth Explorer Mission CFI Apache Axis SPS Library Notification Library

SF Server State management Submit Reserve Confirm Update Simulated acquisitions May fail (eg weather) Database updated Notifications triggered Get Status responses updated