1. 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
Slide 1

2. Objectives of the Work
I1. “To permit the evolution and test of the HMA interoperability standards”
by applying the GML application schema for EO Products (OGC ) and the EO Extension Package for ebRIM CSW (OGC ) 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
Slide 2

3. Metadata Mapping
Compare the GML 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
Slide 3

4. 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
Slide 4

5. 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.
Slide 5

6. 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)
Slide 6

7. 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, ...
Slide 7

8. 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
Slide 8

9. VGT Derived Schema
Slide 9

10. 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)
Slide 10

11. 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)
Slide 11

12. Alternative approach Prototype
VGT4Africa EO EP ebRIM CSW Catalogue with GetRepositoryItem
For integration in HMA Portal, adapted workflows were developed.
Slide 12
Slide 12 12

13. 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
Slide 13

14. Questions !
Slide 14