OpenSearch

Introduction

Since version 0.4, EOxServer features an OpenSearch 1.1 interface to allow the exploration of its contents in a different manner than by using the EO-WCS or WMS functionality.

In contrast to EO-WCS and WMS, the OpenSearch interface operates on metadata only and allows a performant view of the data, by using slimmer output formats such as GeoJSON or Atom/RSS XML structures.

In EOxServer, both the Time and the Geo extensions are implemented to limit the spatio-temporal scope of the search.

Setup

To enable the OpenSearch interface in the EOxServer instance, the urls.py has to be adjusted and the following line added:

from django.conf.urls import patterns, include, url
...
from eoxserver.services.opensearch.urls import urlpatterns as opensearch

urlpatterns = patterns('',
    ...
    url(r'^opensearch/', include(opensearch)),
    ...
)

This adds the necessary URLs and views to the instances setup to expose the interface to the users.

Additionally, the the string "eoxserver.services.opensearch.**" has to be added to the COMPONENTS of the settings.py file.

Usage

The OpenSearch implementation of EOxServer follows a two-step search approach:

  1. the instance can be searched for collections
  2. single collections can be searched for records

For each of those steps, the OpenSearch interface allows two interactions, the description and the``search``. The description operation returns an XML document with service metadata and parametrized endpoints for further searches. The search operation hosts the main searching functionality: the search parameters are sent the service, and the results are encoded end returned.

Parameters

As mentioned before, EOxServers implementation of OpenSearch adheres to the core, and the time and geo extensions. Thus the interface allows the following parameters when searching for datasets:

OpenSearch Search Request Parameters
Parameter (Replacement Tag) Description Example
→ q (searchTerms) This parameter is currently not used.  
→ count Number of returned elements as an integer count=25
→ startIndex The initial offset to get elements as an integer startIndex=125
→ format The output format of the search. Currently supported are “json”, “kml”, “atom”, and “rss”. format=json
→ bbox (geo:box) The geographical area expressed as a bounding box defined as “west,south,east,north” in EPSG:4326 decimal degrees. bbox=-120.0,40.5,-110.5,43.8
→ lat and lon (geo:lat/geo:lon) latitude and longitude geographical coordinate pair as decimal degrees in EPSG:4326. lat=32.25&lon=125.654
→ r (geo:radius) The radius parameter used with lat and lon parameters. Units are meters on along the earths surface. lat=32.25&lon=125.654
→ geom (geo:geometry) A custom geometry encoded as WKT. Supported are POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, and MULTIPOLYGON. The geometry must be expressed in EPSG:4326. geom=POINT(6 10) geom=LINESTRING(3 4,1 5,20 25)
→ georel (geo:relation)

The geospatial relation of the supplied geometry (or bounding box/circle) and the searched datasets geometry. This parameter allows the following values: - “intersects” (default): the passed geometry has to

intersect with the datasets geometry
  • “contains”: the passed geometry has to fully enclose datasets geometry. Currently only PostgreSQL/PostGIS supports this relation for distance lookups.
  • “disjoint”: the passed geometry has no spatial overlap with the datasets geometry.
 georel=contains
→ uid (geo:uid) This parameter allows to match a single record by its exact identifier. This is also used to allow links to searches with only a specific item, as used in the atom and RSS formats. uid=MER_FRS_1P_reduced_RGB
→ start and end (time:start/time:end) The start and end data/time of the given time interval encoded in ISO 8601. start=2006-08-16T09:09:29Z& end=2006-08-17
→ timerel (time:relation)

The temporal relation between the passed interval and the datasets time intervals. This parameter allows the following values: - “intersects”: the given interval has to somehow

intersect with the datasets time span.
  • “during”: the given interval has to enclose the datasets time span.
  • “disjoint”: the given interval must have no temporal overlap with the datasets time span.
  • “equals”: the given interval has to exactly match the datasets time span.
 timerel=equals

Note

Unfortunately there are some known issues for certain parameters, especially concerning the geo:radius with the geo:lat and geo:lon: On certain platforms any distance based search results in an abort caused by GEOS, the underlying geometric algorithm library.

All parameters are available for both collection and record searches.

Output Formats

EOxServer supports various output formats to encode the results of the searches. All formats are available for both collection and record searches.

ATOM and RSS

The EOxServer OpenSearch implementation tries to adhere the specification and recommendations for using OpenSearch with either of the two formats. Apart from the usual metadata links are added to the various enabled services like WMS and WCS wherever applicable. When searching for collections a link to the collections OpenSearch description document is also added.

GeoJSON and KML

These formats aim to provide only a compact metadata overview of the matched collections and records. Only the identifier, begin/end timestamps and the footprint geometry are included.

Enabling/Disabling Formats

With the steps described in Setup, all formats are enabled by default. To limit the available formats, the line added to the line "eoxserver.services.opensearch.**" of the COMPONENTS setting in the settings.py must be replaced by the following:

COMPONENTS = [
    ...
    "eoxserver.services.opensearch.v11.*",
    "eoxserver.services.opensearch.extensions.*",
    "eoxserver.services.opensearch.formats.<format>",
]

where <format> is one of atom, geojson, kml or rss. To enable more than one format, the last line can be repeated for each format.

Future Work

As of EOxServer version 0.4, it is planned to also implement support for the OpenSearch EO extension. This extension was held back on purpose, as the current data models do not include the necessary metadata fields.

Additionally, the aim is to support most of the required and recommended best practices of the CEOS OpenSearch Best Practice Document.