HMA-T: “EO GML” and “EO ebRIM
CSW” for VITO CVB
HMA-FO Task 1 Metadata Workshop
29th of September 2009, OGC TC Darmstadt
Steven Smolders, GIM nv
Tim Jacobs, VITO
Frédéric Houbie, ERDAS
Darmstadt, 29th of September 2009
Slide 1
Objectives of the Work

I1. “To permit the evolution and test of the HMA interoperability
standards”
• by applying the GML 3.1.1 application schema for EO Products
(OGC 06-080) and the EO Extension Package for ebRIM CSW
(OGC 06-131) on a wide range of (derived) EO Products

I3. Promote uptake of these standards by European Institutional users
and geospatial product developers
• by applying these standards on VITO CVB systems
• by providing a reference implementation for these standards
Darmstadt, 29th of September 2009
Slide 2
Metadata Mapping

Compare the GML 3.1.1 Application Schema for EO
Products to the metadata of a wide range of VITO EO
Products to verify the applicability of the EO GML and
propose extensions where required.

Base, Synthesis
& Derived
EO products
Darmstadt, 29th of September 2009
Slide 3
Metadata Mapping

Important remark: we have been looking at metadata to describe
EO products
• for discovery purposes => Catalogues
• for product exploitation => Descriptive file that is shipped together with
the products: important to have
 Lineage information (different processing steps)
 Information for the correct interpretation of the images (flag values, band
ranges, …)
• Would be convenient to have for both purposes similar metadata structure
Darmstadt, 29th of September 2009
Slide 4
Metadata Mapping

“Base Product” VGT-P Mapping Conclusion
• For discovery purposes, EO GML is sufficient but some
inconsistencies between text and schema for
– cardinality of <eop:ProcessingInformation> or subelements
(schema states cardinality of 0..1)
 ProcessingInformation Cardinality changed to 1..n in OGC06-080r5
– cardinality of ProductType (schema says it is mandatory)
 Made optional in OGC06-080r5
– Name of element EarthObservationEquipement
 Corrected in OGC06-080r5
• For exploitation metadata, information on the Geometric and
Radiometric corrections would be useful.
Darmstadt, 29th of September 2009
Slide 5
Metadata Mapping

“Synthesis Product” Mapping Conclusion
• For discovery purposes the EO Profile of GML is sufficient
 If more flexibility is allowed in the compositeType element
– Changed to xs:duration in OGC06-080r5
 Potentially an element is added to capture the synthesis nominal date
• For exploitation metadata, information on the synthesis
algorithm needs to be provided but can be taken up in the
ProcessingInformation (after proposed change in cardinality)
Darmstadt, 29th of September 2009
Slide 6
Metadata Mapping

“Derived Product” Mapping Conclusion
• For discovery purposes EO Profile of GML is sufficient allthough information
on physical quantities would be convenient for the user
• For exploitation metadata, information is required with respect to the
interpretation of the EO Product file:
 Significant digital value (display) range (min/max)
 Physical values range (min/max)
 Scale factor and Offset
 Flag values (Label, code and value): e.g. snow, cloud, missing meteo values, ...
Darmstadt, 29th of September 2009
Slide 7
How to extend EOP GML

To capture exploitation metadata additional elements are required

Two possible approaches (as per OGC06-080r4)
• use vendorSpecific/SpecificInformation elements
• development of a derived schema

VITO specific “VGT” schema
was developed
Darmstadt, 29th of September 2009
Slide 8
VGT Derived Schema
Darmstadt, 29th of September 2009
Slide 9
Effects on EO EP of CSW-ebRIM

How to deal with the EO Profile of GML extensions (which
should not be queryable) in the EO ebRIM CSW extension
package?
 Current EO ebRIM extension package approach involves the
mapping of all metadata elements to ebRIM slots even elements
that should not be queryable.
 Each extension to the EO Profile of GML requires in principle an
equivalent extension of the EO ebRIM CSW extension package
=> EO Profile of GML becomes “redundant”
=> Two documents to maintain
=> Interoperability

Issue also raised in OGC EOxebRIM.SWG- (#168)
Darmstadt, 29th of September 2009
Slide 10
Effects on EO EP of CSW-ebRIM

Alternative approach valid for VITO use case:
• Keep the currently existing EO extension Package and do not map the
additional EO Profile of GML elements to ebRIM
• Implement Search operation using GetRecords with Full ElementSet like this is
normally done
• Implement Present operation using GetRepositoryItem to retrieve full metadata
required for product evaluation

Issues with this approach for general applicability:
• Duplicate information in GetRecords ebRIM and GetRepositoryItem GML
• Binding of GetRepositoryItem operation (in principle only HTTP GET)
• Number of operation calls required to retrieve full metadata set
• Even though extended elements only appear in GML, current compliancy tests
fail due to vgt schema that is present in GML (comparison between slots and
GML)
Darmstadt, 29th of September 2009
Slide 11
Alternative approach Prototype

VGT4Africa EO EP ebRIM CSW Catalogue with GetRepositoryItem
•
For integration in HMA Portal, adapted workflows were developed.
Darmstadt, 29th of September 2009
Slide 12
Future alternative approach

Issues with this approach for general application:
• Duplicate information in GetRecords ebRIM and GetRepositoryItem GML
• Binding of GetRepositoryItem operation (in principle only HTTP GET)
• Number of operation calls required to retrieve full metadata set

Could be solved by:
• Mapping minimum elements (only queryables) to EO ebRIM CSW: light
extension package approach
• In response to a GetRecords operation return an ebRIM structure and a set of
GML instances
• Alternative technologies
 Zipped packages
 (Multipart MIME responses)
 SOAP with XOP and MTOM
Darmstadt, 29th of September 2009
Slide 13
Questions !
Darmstadt, 29th of September 2009
Slide 14