Task #17761

Data Catalogue: integrate and support the temporal concept

Added by Francesco Mangiacrapa 3 months ago. Updated about 1 month ago.

Status:PausedStart date:Mar 14, 2019
Priority:NormalDue date:
Assignee:Francesco Mangiacrapa% Done:


Sprint:Data Catalogue


This is a master ticket to trace the activities regarding temporal integration/support and temporal queries into D4Science's catalogues

06-042_OpenGIS_Web_Map_Service_WMS_Implementation_Specification.pdf (759 KB) Francesco Mangiacrapa, Oct 16, 2019 04:28 PM

Example_of_Multi-Dimensional_GetMap_Requestes.png (78.2 KB) Francesco Mangiacrapa, Oct 16, 2019 04:47 PM

Dimension_part_of_schema.png (273 KB) Francesco Mangiacrapa, Oct 21, 2019 04:32 PM



Task #16276: Catalogue: check how the 'ckanext-datesearch' plugin work...ClosedFrancesco Mangiacrapa

Task #17799: Customize the `ckanext-datesearch` plugin according to th...PausedFrancesco Mangiacrapa


#1 Updated by Francesco Mangiacrapa 3 months ago

OGC: temporal data and their representation in the WMS standard

From attached file "OpenGIS_Web_Map_Service_WMS_Implementation_Specification"

6.7.6 Temporal CS
Some geographic information may be available at multiple times (for example, an hourly weather map). A WMS
may announce available times in its service metadata, and the GetMap operation includes a parameter for
requesting a particular time. The format of a time string is specified in Annex D. Depending on the context, time
values may appear as a single value, a list of values, or an interval, as specified in Annex C. When providing 
temporal information, a server should declare a default value in service metadata, and a server shall respond with
the default value if one has been declared and the client request does not include a value.

C.1 Overview
This annex describes support for multi-dimensional data in the service metadata and operation request
parameters of the WMS. “Dimensions” in this annex refers to Time, Elevation, and sample dimensions; horizontal
dimensions are expressed using Layer CRS (see 6.7.3). Optional elements in WMS metadata declare available
values along one or more dimensional axes applicable to a Layer. GetMap requests for that layer may include
parameters specifying dimensional value(s). .....

C.3.2 Elevation and time values in requests
If a data object has an Elevation dimension defined, then operation requests to retrieve that object may include
the parameter
If a Layer has a Time dimension defined, then requests may include the parameter
In either case, value uses the format described in Table C.2 to provide a single value, a comma-separated list, an interval of the form start/end without a resolution. 
value shall not contain white space. An interval in a request
value is a request for all the data from the start value up to and including the end value.
The absence of Time or Elevation parameters in the request is equivalent to a request for the Layer’s default
value (if defined) along that dimension (see C.4.2). All parameter names are case-insensitive as stated in 6.8.1,
so, for example, “TIME”, “Time” and “time” are all acceptable.
For the TIME parameter, the special keyword “current” may be used if the <Dimension name="time"> service
metadata element includes a nonzero value for the “current” attribute, as described in C.2. The expression
“TIME=current” means “send the most current data available”. The expression “TIME=start_time/current” means
“send data from start_time up to the most current data available”.

D.1 Overview
This Annex specifies the encoding of moments and periods in time to allow the Web Map Service to support
temporal data descriptions and requests. This Annex is based on ISO 8601 and extends ISO 8601 by defining a
syntax for expressing in a single string the start, end and periodicity of a data collection. .....

D.4 Time lists and ranges
C.3 defines a syntax for representing single or multiple values of dimensions including time. Thus, a list of several
times is expressed by separating valid time values with a comma (“,”). A temporal range is expressed using the
syntax start/end/period to indicate the start time of the data, the ending time, and the time resolution or refresh
rate. Data which are refreshed at regular intervals but not archived are represented using time/time/period, where
both time values are the same (that of the latest data) and the period indicates the refresh rate.
 This is an extension to ISO 8601:2000, which represents interval formats as start/end, or start/period, or
period/end, or period alone. ISO 19128 allows start/end/period, where “period” in this context means “periodicity” rather than
“amount of time between start and end of interval”.
D.5 Examples
 A single moment (scalar value): 2000-06-23T20:07:48.11Z
 Quarterly data (comma-separated list): 1999-01-01,1999-04-01,1999-07-01,1999-10-01
 Daily data taken at noon since 15 April 1995 (periodic interval):
 Current data refreshed every 30 min (periodic interval): 2000-06-18T14:30Z/2000-06-18T14:30Z/PT30M

see the Annex C and the Annex D for more details

#4 Updated by Francesco Mangiacrapa about 1 month ago

  • Status changed from In Progress to Paused

Also available in: Atom PDF