Earth observation (EO) products have specific characteristics like the orbit number, processing center and acquisition station that follow a specific logic inherent to the EO community of users of satellite datasets.

Typically a EO product contains information regarding the:

• Platform or satellite from where it originates (e.g. SPOT, ENVISAT)
• The Satellite number (if exists)
• The sensor used to acquired the data
• The specific dataset identifier
• The processing center responsible for its elaboration together with the date and software used for the processing
• The date of acquisition
• The geographical footprint or coverage of the data present in the product

While the last two items are already covered by the time and geo opensearch specification extensions, all the others are currently only accessible through the generic searchTerms. This entry describes an extension proposal for OpenSearch that will provide a standard mechanism to query a resource based on those Earth observation elements. The naming of the elements follow the “GML 3.1.1 Application schema for Earth Observation products OGC 06-080r4“[OR2] normative that describe the EO Metadata format within the Heterogeneous Mission Accessibility (HMA) project. This elements present here are an initial set that were identified in this project phase. More elements will be added upon further analysis and discussion.

Namespace

The proposed XML Namespace URI for the OpenSearch Earth observation products extension is:

http://www.genesi-dr.eu/spec/opensearch/extensions/eop/1.0/

Example

 <?xml version="1.0" encoding="UTF-8"?>
 <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
                        xmlns:eop="http://www.genesi-dr.eu/spec/opensearch/extensions/eop/1.0/">
   <ShortName>Web Search</ShortName>
   <Description>Use Example.com to search the Web.</Description>
   <Tags>example web</Tags>
   <Contact>admin@example.com</Contact>
   <Url type="application/atom+xml"
       template="http://example.com/?q={searchTerms}&orbit={eop:orbitNumber?}&amp;
                 acqstation={eop:acquisitionStation?}&amp;pw={startPage?}&amp;format=atom"/>
   <Url type="text/html"
       template="http://example.com/?q={searchTerms}&orbit={eop:orbitNumber?}&amp;
                 acqstation={eop:acquisitionStation?}&amp;pw={startPage?}"/>
   <LongName>Example.com Web Search</LongName>
   <Image height="64" width="64" type="image/png">http://example.com/websearch.png</Image>
   <Developer>Example.com Development Team</Developer>
   <SyndicationRight>open</SyndicationRight>
   <AdultContent>false</AdultContent>
   <Language>en-us</Language>
   <OutputEncoding>UTF-8</OutputEncoding>
   <InputEncoding>UTF-8</InputEncoding>
 </OpenSearchDescription>

Parameters

platform

A string identifying the platform from which the product originated (e.g. ENVISAT, SPOT)

http://example.com/?q={searchTerms}&pw={startPage?}&platform={eop:platform?}

This tag name corresponds to the Xpath description eop:platform/eop:Platform/eop:shortName

sensorType

A string identifying the sensor type from which the product originated. The possible values are: OPTICAL, RADAR, ALTIMETRIC, ATMOSPHERIC

http://example.com/?q={searchTerms}&pw={startPage?}&sensor={eop:sensorType?}

This tag name corresponds to the Xpath description eop:sensor/eop:Sensor/eop:sensorType

instrument

A string identifying the instrument from which the product originated (e.g. MERIS, AATSR, ASAR, HRVIR).

http://example.com/?q={searchTerms}&pw={startPage?}&instrument={eop:instrument?}

This tag name corresponds to the Xpath description eop:instrument/eop:Instrument/eop:shortName

resolution

A real number interval requesting the range of Sensor Resolution given in metres (i.e. uom=’m’). This parameter is a range or a group of integer number defined as [n1,n2] (meaning n1 <= resolution <= n2). It uses typical mathematical notation to define the interval with:
• [n1,n2] equals to n1 <= resolution <= n2
• [n1,n2[ equals to n1 <= resolution < n2
• ]n1,n2[ equals to n1 < resolution < n2
• ]n1,n2] equals to n1 < resolution <= n2

http://example.com/?q={searchTerms}&pw={startPage?}&res={eop:resolution?}

This tag name corresponds to the Xpath description eop:sensor/eop:Sensor/eop:resolution

orbitNumber

A integer number interval requesting the range of acquisition orbit number. This parameter is a range or a group of integer number defined as [n1,n2] (meaning n1 <= orbit <= n2). It uses typical mathematical notation to define the interval with:
• [n1,n2] equals to n1 <= orbit <= n2
• [n1,n2[ equals to n1 <= orbit < n2
• ]n1,n2[ equals to n1 < orbit < n2
• ]n1,n2] equals to n1 < orbit <= n2

http://example.com/?q={searchTerms}&pw={startPage?}&orbit={eop:orbitNumber?}

This tag name corresponds to the Xpath description eop:acquisitionParameters/eop:Acquisition/eop:orbitNumber

acquisitionStation

A string identifying the station used for the product acquisition (.

http://example.com/?q={searchTerms}&pw={startPage?}&acqStation={eop:acquisitionStation?}

processingCentre

A string identifying the processing centre from which the product was elaborated (e.g. PDHS-E, PDHS-K, DPA, F-ACRI)

http://example.com/?q={searchTerms}&pw={startPage?}&procCentre={eop:processingCentre?}

processingSoftware

A string identifying the software used when product was elaborated (e.g. ASAR/3.06, MERIS/5.04, MEGS-PC/7.4). This element shall return all the elements similar with the request as in LIKE or MATCH query. As such, a query for ASAR/3 will return all the products processed with any of the release of version of 3 of the ASAR processor.

http://example.com/?q={searchTerms}&pw={startPage?}&procCentre={eop:processingSoftware?}

processingDate

This queries the element for a time interval between two time points as defined by the ISO8601.

http://example.com/?q={searchTerms}&pw={startPage?}&procDate={eop:processingDate?}

The processingDate should be replaced by a string containing the time interval in the format YYYY-MM-DDTHH:mm:ss/YYYY-MM-DDTHH:mm:ss

---

This entry is an initial proposal and further elements might be added in the future. Please send any comments, doubts or suggestions.

INSPIRE requires us to submit metadata to a geoportal operated at the Member State level (or below). In practise this will be to a CSW2 service using the ISO Application Profile. In this entry we discuss some simple solutions to be INSPIRE compliant in this domain. [...]

Often enough a dataset will be available from multiple access points. This may simply be a different access protocol, for example via an FTP repository and an HTTP server. Alternatively data may also be available via geodata-specific services, such as a WMS or WFS. Online resources may require supplementary information in order to automate access to them - version, for example, can be critical for a WMS service. The DCLite4G namespace provides a supplementary vocabulary for identifying types of web service from which a dataset can be accessed. [...]

To define the structure of the GENESI-DR information model we use the DCLite4G vocabulary. DCLite4G is short for "Dublin Core Lightweight Profile for Geospatial" and it is a minimal information model for metadata about geospatial data. This vocabulary was designed to help extend Dublin Core with metadata about geodata. Our main use of DCLite4G is to provide classes that represent a DataSet and Series, with the relations between them. DCLite4G also covers properties specific to a geographic application - file formats for GIS data, different coordinate systems. [...]

We are using RDF model to allow nodes in a digital repository network to share data with catalogs. Here we go into more detail about our design decisions and how the model fits with currently developing standards in Europe. [...]

To share information about data sets and series available on Digital Repository nodes, we settled on an RDF model rendered in XML. Participating organisations publish RDF/XML files describing updates to their data products. This entry is an informative example of RDF/XML which can be consumed by the duetopia catalog and allow the automatic insertion of the dataset described in the GENESI-DR Discovery Agent. [...]

Following her articles dedicated to OpenSearch and how it could meet the INSPIRE requirements for the GENESI-DR discovery services, Jo Walsh published a new article on Terradue web site explaining the initial duetopia implementation. While the previous articles focused on abstract level, this new article shows the path to the initial prototype implementation of an OpenSearch interface to a geospatial metadata repository. [...]

In a new blog entry by Dion Hinchcliffe from ZDNet that discuss the striking contrast between the slow going of SOA initiatives in the enterprise and the vibrant and rapidly growing ecosystems similar to them on the consumer Web 2.0. It presents the differences and advantages of SOA and what the author is describing as Web-Oriented Architecture (WOA) which is less a strict set of standards than a loose set of enabling practices and simple applications. [...]

A article discussing the implementations details of the spatial data search service using the OpenSearch protocol. This article presents a key to "future-proofing" spatial data search is to make sure an interface complies with the INSPIRE Implementing Rules on Discovery Services [...]

In a new entry in the Terradue's blog, Jo Walsh discuss the issues behind the creation of multilingual metadata registries. It present the common standards that provide ways "internationalise" textual properties and help identify and locate pieces of non-textual data. [...]