Adding Search on Temporal Extent to Advanced Search

Date	2010/04/14
Contact(s)	Simon Pigot
Last edited	Timestamp
Status	complete
Assigned to release	2.5.0
Resources	Available, patch attached

Overview

GeoNetwork can search for metadata records based on date of last change but cannot search for metadata records with a temporal extent in the resource Identification section (DataIdentification or ServiceIdentification).

Proposal Type

• Type: GUI Change, Core Change
• App: GeoNetwork
• Module: Data Manager, Lucene Index, Search Interface, User Interface

Links

• Sandbox: BlueNetMEST
• Other wiki discussions: Proposed at 2008 Bolsena meeting and has been present in BlueNetMEST for some years - too long.

Voting History

• Note voted on yet

---

Motivations

Add Temporal Search capability to GeoNetwork.

Proposal

Advanced Search Interface would look like the following:

In ISO records temporal extents can be specified in a number of different ways (GML has many different and flexible representations for time). The GeoNetwork editor simplifies the options by using a JavaScript calendar interface to specify an ISO DateTime or ISO Date interface. For temporal extent searching to work correctly, we need a flexible method of parsing as many of the different time formats as possible because not all records in the catalog will be created using the GeoNetwork editor. After parsing we will need to convert to a common time format and timezone before storing in a Lucene Index field for searching.

Example temporal extents (these were not created with the GeoNetwork editor):

<gmd:temporalElement>                         
  <gmd:EX_TemporalExtent>                             
    <gmd:extent>
      <gml:TimePeriod xmlns="http://www.isotc211.org/2005/gmd" gml:id="TemporalExtent">                                     
        <!--
              1) Use 2000-01-01 to specify the beginning of the extent                                         
              2) Use the *period* [P] declaration to indicate that extent ends in 3 days 
          -->                                     
        <gml:beginPosition>2000-01-01<gml:beginPosition/>
        <gml:endPosition>P3D</gml:endPosition>                                 
      </gml:TimePeriod>                             
    </gmd:extent>                         
  </gmd:EX_TemporalExtent>                     
</gmd:temporalElement>

<gmd:temporalElement>                         
  <gmd:EX_TemporalExtent>                             
    <gmd:extent>
      <gml:TimePeriod xmlns="http://www.isotc211.org/2005/gmd" gml:id="TemporalExtent">                                     
        <!--
              1) Use indeterminate position to specify the beginning of the extent as "now"
              2) Use -P3D to specify a period of 3 days (minus means subtract from the other extent) - so its 3 days before now 
          -->                                     
        <gml:beginPosition>2000-01-01<gml:beginPosition/>
        <gml:endPosition indeterminatePosition="now">                                 
      </gml:TimePeriod>                             
    </gmd:extent>                         
  </gmd:EX_TemporalExtent>                     
</gmd:temporalElement>

Note that the second example above uses an indeterminatePosition to specify one end of the extent - indeterminate extents are not yet supported.

Temporal extents supported:

• begin: most any date format supported by JODA eg. ISO datetime, ISO date, some other forms of date, plus indeterminateposition="now"
• end: same as begin but also any GML time period eg. P3D (or even a negative period) as above

This proposal would see GeoNetwork use the parser from the JODA time library for this purpose as JODA is generally considered to be the most comprehensive time library for Java. The parsing and conversion step is done by a call to Java objects that use the JODA library when preparing the Lucene Document for indexing (index-fields.xsl).

Proposal also includes hide/show for some advanced search fields to reduce size of the form.

Backwards Compatibility Issues

None known.

Participants

• Michael Stegherr - CSIRO CESRE - ported some of the functionality from BlueNetMEST to trunk