Application Profile for EO Products

1

• Application Profile for EO Products
• (NOT a Christmas Carol by Charles Dickens)
• Jolyon Martin
• NOT the Ghost of Christmas Past (History)NOT the
  Ghost of Christmas Present (Best Practices, OGC
  Huntsville)NOT the Ghost of Christmas Future
  (HMA Draft Changes)

2
Catalogues for E O

• The scope of the problem
• Very large, historic datasets are available.
  Generally organised in collections, as basic data
  from same instrument on one or a series of
  satellites. Extensive catalogues are part of
  existing ground segments.
• 105 EO data products per collection frequent
• Note that free text search doesnt give much
  value at product level (as opposed to discovery
  level)
• Harvesting not a good approach for product
  metadata
• Our key requirements Catalogue Order
• Distributed searching of collections from
  multiple providers
• Identification of available order options, order
  submission and order monitoring

3
05-057r3 Best Practices Paper

• Originally formulated as minimal profile for
  catalogue search and order using WSDL/SOAP, This
  profile describes the interfaces, bindings and
  encodings required to search, present and order
  data from catalogues of EO products. The profile
  is presented as a minimum requirement for
  interoperability, it is anticipated that this can
  be supported in a cost-effective manner by
  providers of EO products.
• A readable/digestable specification (lt50 pages)
• Not fully compliant with OGC Catalogue
  Specification v 2.0 in some ways further
  advanced, in some ways less thus raised as
  discussion paper,
• Posted on pending documents June 05, reviewed by
  OGC TC,
• approved to be Discussion paper at Bonn with
  ammendments to specify alignment planned with OGC
  v2.0, approved to be Best Practices paper at
  Huntsville
• Needs to address issues of other HMA partners,
  evolve from a minimum profile

4
Heterogeneous Mission Accessibility

• The ESA Heterogeneous Mission Accessibility
  study sets the scene for improved / standardised
  access to EO data services from the main
  European/Canadian satellite operators, within the
  context of GMES
• As a part of an overall strategy to pull and
  push IT standards to arrive at a standardised,
  harmonised set of interfaces for
• Discovery,
• Catalogue,
• Order,
• Online Data Access,
• Mission Planning
• User Management
• This set of interfaces shall be available to
  service providers as the start of value added
  service chains.

5
High Level Context
6
Catalogue metadata model

• Data model references ISO, OGC, FGDC,
• Proposed to align to GML3.2, plus newer HMA
  schema proposal

7
HMA Changes 1 Schema

• Proposal to evolve from just minimal profile,
  to cope with base schema (hma) and
  specializations for Optical High Resolution
  (ohr), Synthetic Aperture Radar (sar),
  Atmospheric Instruments (atm) and project
  specific codespaces (e.g. phr)

8
Catalogue Operations Details

• Stateless protocol
• searchRequest this message allows to identify
  products inside a single collection via a search
  condition and to request the number of hits or
  product metadata in different formats as
  response.
• Will be renamed getRecords
• presentRequest this message allows to retrieve
  (multiple) product metadata within a single
  collection by providing the product
  identification.
• Will be renamed getRecordById
• response this message contains the result in
  form of number of hits or returned product
  metadata.
• Various presentation formats that allow efficient
  transfer of results and aid user in refining
  search
• Will be aligned to CSW

9
Catalogue Details Query Definition

• Current schema defines standardised available
  search operations for the key parameters (
  implicit AND, low complexity, the standard set of
  options available required for most applications
  )
• Planned to include OGC Filter Syntax already
  found issues in different ways to specify the
  same query (e.g temporal query greater and less
  than, or between)
• strongly recommend that 05-22 change request
  (support of QueryModel) is implemented.

10
Order Details requests / responses

• productOrderRequest this message allows to submit
  an order by providing one or more product
  identification and its collection with the order
  options selected.
• Naming changed to submitProductOrder
• orderResponse this message contains the result in
  form of the order identifier.
• orderMonitorRequest this message allows to
  monitor the order status by providing the order
  identifier, or to retrieve all orders for a user
  that have been updated since a given date.
• Naming changed to getOrderStatus
• orderMonitorResponse this message contains the
  result in form of the order status returned.
• These are the first simple order operations, now
  we tackle
• OrderacquisitionOrderSubmit(future-product-defini
  tion),
• OrdercoverageOrderSubmit(flexible-order-definitio
  n),
• OrdercoverageOrderFeasability
• Service taxonomy now being derived from use case
  and scenario analysis with HMA partners.

11
Order Details order options

• Originally formulated as an extra presentation
  format for order options, proposed as a new
  operation

12
HMA Changes - 2 Draft Taxonomy
13
Catalogue Scenarios Agency clients
DAIL
CNES
DLR
ESA
client
EOLI(ESA)
GetRecords( resultTyperesults
outputSchamehmarecord typenamedataset,
constraintHMA_SimpleQuery, (datasetcollectionE
SA.ASA.IM) presentationbrief)
DAIL simple routing
GetRecords( resultTyperesults
outputSchamehmarecord typenamedataset,
constraintHMA_simpleQuery (datasetcollectionESA
.ASA.IM) presentationbrief)
response(schemahmarecord)
Allow 2 (please no more!) alternatives, based on
simple shared and efficient hma schema
GetRecords( resultTyperesults
outputSchamehmarecord typenamedataset,
constraintHMA_SimpleQuery,(datasetcollectionPH
R.ABC.DEF) presentationbrief)
DAIL simple translation
GetFeature( resultTyperesults
outputSchamehmarecord typenamedataset,
constraintOGC_FilterSyntax (datasetcollectionPH
R.ABC.DEF) propertyNamesList)
response(schemahmarecord)
GetFeature( resultTyperesults
outputSchamehmarecord typenamedataset,
constraintOGC_FilterSyntax (datasetcollectionPH
R.ABC.DEF) propertyNamesList)
WFS (CNES)
14
Catalogue Scenarios ISO compatible client, two
step search
DAIL
CNES
DLR
ESA
ISOclient(FAO,INSPIRE)
Collection details (smXML)
initally
Harvesting requestCollection details (smXML)
optionally
GetRecords( resultTyperesults
outputSchamecswIsoProfile
typenamedatasetcollection,
constraintOGC_QueryFilter, presentationbrief)
DIAL pragmaticallyfills ISO metadata as required
for interoperability with Key partners(since
smXML isnt the lightest of schema)
DAIL queries collections databasefor matching
results
response(schemacswIsoProfile)
GetRecords( resultTyperesults
outputSchamecswIsoProfile
typenamedataset, constraintOGC_QueryFilter
(datasetcollectionESA.ASA.IM)
presentationbrief)
DAIL routes dataset query (notice, simple
EOLI-XML like I/F)
GetRecords( resultTyperesults
outputSchamehmarecord typenamedataset,
constraintHMA_simpleQuery (datasetcollectionESA
.ASA.IM) presentationbrief)
Single step approach also possible, depends if
FAO/INSPIRE want to get lots of hits (since
largely text focus for filter)
DAIL combines with collection level metadata and
returns results
response(schemacswIsoProfile)
15
Recap why do we need an EO profile?

• For Catalogue
• To precisely describe a semantic that allows
  description of EO data that is not currently
  available in ISO-19115 (or yet in part-2) (e.g.
  satellite domain orbit/swath/frame/pass
  definitions, query parameters such as
  viewingAngle, cloudCover )
• To describe an effective interface good
  performance to search, present distributed
  catalogues of EO data
• For Order
• To describe the order options appropriate to EO
  data (e.g. scene selection, processing options,
  programming options, delivery options)
• Plus for interfaces to Online Data Access and
  Mission Planning
• Re-iterating the goal a standardised, harmonised
  set of interfaces that support a service oriented
  view of the heterogeneous mission ground
  segments, and enable the construction of compound
  / value added services from our basic interfaces,
  that can be implemented in a cost-effective
  manner.
• Conclusions, some harmonsiation of EO profile
  towards OGC Catalogue planned but stateless web
  services with simple query part of our baseline
  solution.

16
Next Steps

• Objective Have an adopted profile of the
  Catalogue Specification by end of 2006
• Refine schema and approach with HMA partner
  requirements
• Continue to discuss selected issues in
  appropriate OGC TC working groups, e.g.
  Architecture WG
• Implementation of selected changes that have been
  specified within prototype

17
Conclusions

• NOT a Christmas Carol by Charles Dickensand NOT
  the Ghost of Christmas Yet To Come
• Thank you for your attention