Welcome to the TemporalDWG web

Preface

Goal of this Working Group is to clarify the role of time as a first-class alignment concept next to space, and to strive for a handling of time which is coherent and integrated with that of space. As the issue of time in CRSs is an overarching one across all of OGC, the WG will seek to include background from as many OGC stakeholder groups and WGs as possible. To this end, the WG is open to all who are interested in the topic.

The Temporal.DWG is a community oriented working group of the Open Geospatial Consortium (OGC). The group does not directly revise OGC standards, but rather enables collaboration and communication between groups with spatio-temporal modeling interests. While originating from work on multi-dimensional data, its spread meanwhile is far wider.

The Temporal DWG is intended to be a public forum for communication, and both the email list and this Twiki are open to interested parties.

• *Charter Temporal_Domain_WG_Charter_V0.5.doc
• *Contact The group is chaired by Chris Little (UK MetOffice) and Matthias Müller (Technical University Dresden)
• *Twiki Anyone can edit this wiki, but, of course, responsibly. Instructions can be found on the TWiki Text Formatting Rules page.
• *Email list Subscribe to the public email list at : https://lists.opengeospatial.org/mailman/listinfo/temporal
• Presentation: Some key ideas so far http://external.opengeospatial.org/twiki_public/pub/TemporalDWG/WebHome/Temporal_DWG_KeyIdeas.ppt
• Current documents:
  • Early draft Best Practice TemporalDWGBestPracticeV0.3.doc
    
  • Approved Discussion paper on temporal intervals A_Conceptual_Model_and_Text-based_Notation_for_Temporal_Geometry.pdf
    

Standards Working Group

• TemporalSWG

Events

• Temporal.DWG sessions at OGC TC (Technical Committee) meetings:
  • 2013-09-24..27 Crystal City Draft Agenda ( full TC agenda)
  • 2013-09-23..26 Frascati Draft Agenda

Problem statement

initiated by -- Chris Higgins, PeterBaumann - 12 Jul 2013

We need to have data structures expressive enough for:

• Coordinate systems and datums/epochs (years/days since 0 BCE, milliseconds since 1/1/1970, days since last Sunday, ...)
• Calendars (Proleptic-Gregorian, Julian, Mayan, 360day year, etc)
• Notation (ISO8601 or restrictive profile, etc)
• proxies for time (number of tree rings, mm of ice or sediment core, etc)

Cutting across these are also the ideas of:

• multiple time dimensions (e.g. ‘real’ time vs forecast time);
• relative and absolute time;
• points, periods and durations;

We need to have operations:

• temporal subsetting and aggregation as part of service definitions (eg, coverages: "January average daily maximum temperatures for 1980-2010" versus "average January day time maximum temperature for 1980-2010")
• CRS transforms (Gregorian - Japanese Imperial - Chinese - climate calendar - carbon time - geological epochs, etc.)
• metrics operations ("how many days are between X and Y? how many seconds?", "every January 1st from now back to year 1000", "is interval X contained in Y?", ...)

And we probably need some reference materials, both human readable and machine referenceable.

• publish the “vocabulary” of time-types at http://opengis.net/def/ as an official OGC resource?
• reference registries of CRS definitions and entities

The overall concept

The Temporal Coordinate Reference System (CRS)

When dealing with topology descriptions for a certain geographic feature (e.g. a coverage), GML only allows numerical coordinates: timestamps/dates cannot be used as meter for the temporal axis, and even though time can be used as information of support for the feature (e.g. gml:EnvelopeWithTimePeriod), a dedicated temporal Coordinate Reference System (CRS) must be used for a seamless integration of time. The time CRS gives meaning to the numerical temporal coordinates associated to a phenomeon (e.g. a temporal series of points) by means of an origin (//TemporalDatum/origin), a label (//TimeCS/axis/CoordinateSystemAxis/axisAbbrev), direction (//TimeCS/axis/CoordinateSystemAxis/axisDirection) and a UoM (//TimeCS/axis/CoordinateSystemAxis[@uom]).

gml:TemporalCRS elements provide a (publicly accessible) way to define time indexing of a temporal axis. The axis is meant to be a simple linear representation of time elapsed since an epoch, it should be up to third-party libraries to properly translate such numeric indexes from/to meaningful dates. Referring to a time CRS inevitably coerces the user to choose a temporal resolution, defining the amount of time which every step unit represents. Time indexes need not be integers however: like spatial coordinates, they can be floating-point numbers.

In the "Policy Directives for Writing and Publishing OGC Standards: TC Decisions" document OGC 06-135r11 (2011)] Sec. 20 "OGC HTTP URI Policy", the OGC members approved a new URI-oriented approach for persistent public OGC resources, CRS included (the EPSG:4326 example is reported: http://www.opengis.net/def/crs/EPSG/0/4326). By means of CRS compounding, a single URI would be able to concatenate a spatial (1D, 2D, 3D), with a temporal CRSs, yielding a spatiotemporal reference system. Note that compounding can be composed as well of 3+ CRSs, and the temporal dimension need not be unique.

Advantages of the URI-oriented schema for CRSs are the resolvability of the URIs to a detailed GML definition: in this case an OGC CRS Name Resolver would act as a new essential figure in the overall framework. See "OGC© Name Type Specification for CRSs" OGC 11-135] for further insight.

-- PieroCampalani - 26 Feb 2013

Regarding time in general, the Met-Ocean domain has three areas where its usage surprises or confuses outside users:

1. Forecasts and their relevant times: start and end points, actual time of issue, validity period, data cut-off, etc.
2. Calendars : pre-Gregorian times, different calendars (Chinese, Jewish, ...) and calendar types (solar, sidereal, models with 360 day years, ...), leap seconds, etc.
3. Statistics and the temporal support of the observed processes.

These aspects could be addressed by means of different activities:

1. CONCEPTUAL MODELLING : This is needed to agree terminology, universe of discourse, and to partition non-overlapping scopes of activities. The ongoing CF-NetCDF conceptual modelling discussions are relevant here, as maybe some of John Herring's work on Simple Features and any spatio-temporal stuff.
2. CRS COORDINATE REFERENCE SYSTEMS : Agree what is and what is not a CRS, and give some commonly used examples, with some common conversion processes, whether precisely correct or not. I also expect some discussion here with the spatio-temporal approaches.
3. CALENDARS : Agree what is the default (Proleptic Gregorian?), suggest guidelines for choice and highlight common pitfalls. Do we need a registry of calendars and conversions?
4. NOTATION : People mistake ISO8601 for a CRS or a calendar. It is neither but a notation that works for many calendars or temporal CRSs. The latest version of the standard has some good practices documented in informative sections, but these are not always well known. Perhaps we could highlight the characteristics of the different versions of the standard, and then produce some ISO8601 best practice?

-- PieroCampalani - 09 Apr 2013 (from Chris Little's email, 18 Mar 2013)

Temporal CRS definitions: an example

This section provides an example of how a GML definition of a temporal CRS would look like.

The following GML code proposes the ANSI date number definition: a day-resolution temporal CRS, with a "day"-labeled positive-forward axis whose origin is on the 1st of January, 1601:

<TemporalCRS xmlns="http://www.opengis.net/gml/3.2" id="ansi-date-crs">
    <description>Concrete temporal CRS of days elapsed from 1-Jan-1601 (00h00 UTC).</description>
    <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/crs/OGC/0/_AnsiDate_template</identifier>
    <name>Julian Date</name>
    <remarks>Initial version (0.1)</remarks>
    <scope>not known</scope>
    <timeCS>
        <TimeCS xmlns="http://www.opengis.net/gml/3.2" id="days-cs">
            <description>1D coordinate system containing a time axis measuring days [d].</description>
            <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/cs/OGC/0/Days</identifier>
            <remarks>Initial version (0.1)</remarks>
            <axis>
                <CoordinateSystemAxis xmlns="http://www.opengis.net/gml/3.2" id="day" uom="http://www.opengis.net/def/uom/UCUM/0/d">
                    <description>Coordinate system axis for the recording of days [d].</description>
                    <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/axis/OGC/0/days</identifier>
                    <remarks>Initial version (0.1)</remarks>
                    <axisAbbrev>day</axisAbbrev>
                    <axisDirection codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/axisDirection/OGC/1.0/future</axisDirection>
                </CoordinateSystemAxis>
            </axis>
        </TimeCS>
    </timeCS>
    <temporalDatum>
        <TemporalDatum xmlns="http://www.opengis.net/gml/3.2" id="ansi-td">
            <description>Epoch time for the ANSI date (1-Jan-1601, 00h00 UTC) as day 1.</description>
            <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/datum/OGC/0/AnsiDateDatum</identifier>                        
            <remarks>Initial version (0.1)</remarks>
            <scope>not known</scope>
            <origin>1600-12-31T00:00:00Z</origin>
        </TemporalDatum>
    </temporalDatum>
</TemporalCRS>

Source: http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/AnsiDate . According to ISO specs, this CRS could correspond to the following WKT:

TIMECRS["ANSI Date",
    TDATUM["ANSI epoch", ANCHOR["1600-12-31T00:00:00Z"]],
    CS[temporal,1],
        AXIS["day",future],
        TIMEUNIT["day",86400.0]]
    AUTHORITY["OGC", "AnsiDate"]]

For a full list of URIs for temporal CRSs has been submitted to OGC Naming Authority, see this page.

-- PieroCampalani - 25 Nov 2013

$ Additionally, here are some guidelines on the creation of gml:TemporalCRS elements from Simon Cox: You must explain which branches you want to establish, and what the rules for these are, preferably in terms of path elements that are defined in other collections in the /def/ service. For example: here’s the set of definition types: http://www.opengis.net/def/def-type/. Here’s the set of authorities responsible for particular collections: http://www.opengis.net/def/auth/ - the entries in this collection should be annotated with which def-types each authority can name. Once that is done, you have delegation to make changes to the resource sets themselves, regardless of the technical means used to manage and publish them.

-- PieroCampalani - 06 Aug 2013

Examples of Temporal CRS indexing

• Weakly regular daily data
  • INPUT: e.g. time series of daily aggregates of a certain phenomenon observations (with possible missing data, but this would not be relevant for indexing purposes), starting from 1st January 2013.
  • GML INDEXING: integer indexing by means of notorious date numbers, e.g. Lilian, truncated Julian, or ANSI dates (this is just one amongst several possible solutions). In the latter case a possible time CRS could be http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/AnsiDate, with indexes {150481, 150482, 150483, ... }.
• Daily series with local TRS and hourly precision
  • INPUT: e.g. time series of daily data in a local time reference system from 1st January 2013: if recorded at the start of the day, the regularity can either be 23h, 24h, or 25h. They are indeed regular (1h), but very sparse. They are intended to be daily (e.g. every day at 12h00), but days have uneven lengths when going from and to Daylight Saving Time (DST) .
  • GML INDEXING: such dataset could exploit a parametrized time CRS with hourly precision, and custom origin coinciding with the starting time of the series. For example, referring to CET: http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Temporal?epoch=%222013-01-01T00:00%2B01:00%22, with indexes {12, 36, 60, ... } (again, this is just one amongst other possible solutions, not necessarily involving parametrized TRSs). On 31 Mar 2013 02h00 local time turns to CEST (+1h) so e.g. the indexing would reflect DST by letting 23 units (hours) pass: { ... , 2013-03-30T12:00+01:00, 2013-03-31T12:00+02:00, 2013-04-01T12:00+02:00, ... } = { ... , 2148, 2171, 2195, ... }. The mechanism is fairly straightforward, but this reflects the reduced complexity of having a linear time axis.

-- PieroCampalani - 17 Mar 2013

The associated Name-Type Specification (NTS) document has been accepted by OGC-NA at the TC meeting in Geneva (June 2014).

-- PieroCampalani - 01 Jul 2014

Test datasets

If you have some specific dataset you would like to encode with a TemporalCRS, please fill in the details in TestDatasetDescription. -- PieroCampalani - 17 Mar 2013

TODO list

Work items and suggested deadlines (volunteers needed):

1.	First draft a best practice document.	By Frascati.
2.	Then decide priority of impacted OGC Standards.	At Frascati.
3.	Discuss with OGC Architecture Board (OAB).	Before Mumbai.
4.	Decide whether we need any profile or Change Requests (CRs).	At Mumbai.
5.	Change standards.	After Mumbai, 2014.

The Best Practice (BP) document should then:

1. Describe differences between CRS, Calendar and Notation.
   • notes...
2. List some commonly used calendarsin differing domains, annotated with best practice and quirks and traps.
   • notes...
3. Identify short-comings/errors of existing standards.
   • notes...
4. Recommend BP and their scopes.
   • notes...

-- PieroCampalani - 09 Apr 2013 (from Chris Little's email, 19 Mar 2013)

Related Work

• PostTIME : enhancing PostgreSQL's capabilities to handle the temporal dimension with a focus on processing spatial information (main contact: Peter Broßeit);
• OGP/EPSG : "ISO 19111 and OGC Topic 2 define the concept of a compound CRS, and use ISO19108 as the temporal part. [...] I see a spatio-temporal CRS as a compound CRS consisting of (a spatial CRS + a temporal CRS) where the temporal CRS has its own datum and coordinate system. We (OGP and the oil industry geological sciences) are using the definition of a year from the International Union of Geological Sciences (IUGS) and International Union of Pure and Applied Chemistry (IUPAC), Pure Appl. Chem., Vol. 83, No. 5, pp. 1159–1162, 2011. This defines a fixed year of 31556925.445 seconds", Roger Lott.
• OGC papers:
  • Temporal Features (OGC 06-076)
  • Temporal Filter (OGC 05-093r1)
  • OWS Common Temporal Conventions (OGC 08-121)

-- PieroCampalani - 21 May 2013

• Python's DATETIME64 object, which allows powerful time/calendar functionality in packages such as Pandas.

-- RichSignell - 26 Mar 2014

Discussions list

If we gonna go to fancy data-oriented calendars

When it come to defining calendars we should also consider ones resembling data provision schemes such as the three time per month which does not equal once every ten days but rather follows a Montly on 1st, 11th and 21st approach so it would be recurring but not regular. It can be found on processed satellite products.

-- Main.abeccati - 26 Feb 2013

Which data formats, besides NetCDF should we endorse to exchange spatio-temporal data? (Edzer Pebesma, 22 Feb 2013)

PB: IMHO, concepts need to be defined independently from any format first. With GMLCOV, we have an abstract representation of coverages that allow to carry the information we want, including temporal coordinates and CRS. Also, the "multipart" representation of coverages allows to encode the "pixel payload" in any format, such as NetCDF, HDF, GeoTIFF, down to BMP, while still maintaining all semantic information in its GML header. I can just talk about coverages, can anyone speak up for features? -- PeterBaumann - 08 Mar 2014

Should we provide a set of official time-CRS definitions / which ones ?

Although a user should not be scared by the idea of creating a custom time coordinate reference system that fits its dataset(s), it might well be the case to choose a finite set official URIs and relative GML definitions for some common use cases. Some ideas can be found here and here (e.g. relative Julian date). We might also want to offer templates targeted by parametrizable URIs ( insight) for sort of wild card time CRSs: parametrized origin and/or UoM, axis label.

-- PieroCampalani - 26 Feb 2013

Further issues

...OGC is currently voting on OpenMI as a standard. It seems to use Modified Julian day as its CRS:

"Modified Julian day is the Julian Day minus 2400000.5. A Modified Julian Day represents the number of days since midnight November 17, 1858 Universal Time on the Julian calendar. The Modified Julian Day has been selected as a reference, since few models operate in a time horizon before 1858. Any date before November 17, 1858 will be represented as a negative value.

(See RECOMMENDATION ITU-R TF.457-2. USE OF THE MODIFIED JULIAN DATE BY THE STANDARD-FREQUENCY AND TIME-SIGNAL SERVICES – which may be found at: http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.457-2-199710-I!!PDF-E.pdf )"

Useful links

1. NSG Standards Registry - Time-Space-Position Information (TSPI) .doc] (US reference for spatio-temporal formats).
2. ISO:19108 Temporal Schema.
3. ISO:8601 Date and Time Formats.
4. ISO time UoMs.
5. gml:TemporaCRS .xsd].
6. Unofficial introductory slides and a couple of examples for temporal reference systems definitions.
7. WCS.swg/Coverages.wg "Time series of coverages" discussion archive].
8. geotools-gt2-users discussion on TemporalCRS and calendars archive].
9. OGC OpenMI 2.0 [OGC 11-014r2] candidate standard.
10. WMO Code Lists relevant to time, used in WMO data formats.
11. ...

-- PieroCampalani - 26 Feb 2013

1. NetCDF CF conceptual modelling discussion at cf-conventions@listsNOspamPlease.llnl.gov
2. COARDS climatological time convention for NetCDF http://ferret.wrc.noaa.gov/noaa_coop/coop_cdf_profile.html
3. Calendrical Tabulations 1900-2200, Edward M. Reingold, Nachum Dershowitz. Hardcover: 636 pages. Publisher: Cambridge University Press (16 Sep 2002) Language: English ISBN-10: 0521782538 ISBN-13: 978-0521782531
4. Calendrical Calculations, Nachum Dershowitz, Edward M. Reingold. Paperback: 512 pages. Publisher: Cambridge University Press; 3 edition (10 Dec 2007) Language: English ISBN-10: 0521702380 ISBN-13: 978-0521702386
5. ISO 8601: http://www.iso.org/iso/catalogue_detail?csnumber=40874
6. W3C http://www.w3.org/TR/NOTE-datetime
7. Markus Kuhn is a useful expert http://www.cl.cam.ac.uk/~mgk25/iso-time.html
8. International Union of Geological Sciences (IUGS) & International Union of Pure and Applied Chemistry (IUPAC), Pure Appl. Chem., Vol. 83, No. 5, pp. 1159–1162, 2011 defines a fixed year of 31556925.445 seconds used by oil industry and geology.
9. David Pierce authored the Calcalcs C routines http://meteora.ucsd.edu/~pierce/calcalcs/index.html . This includes a table of Julian/Greorian transition dates for various countries.
10. Python calendar calculations http://code.google.com/p/pycalcal/ .
11. ...

-- PieroCampalani - 09 Apr 2013 (from Chris Little's email, 18 Mar 2013)

1. Section 9.15 of OGC 10-126r4 (WaterML2 2.0.1) contains 'interpolation types' for time series. http://www.opengeospatial.org/standards/waterml

-- DavidBlodgett - 26 Mar 2014

TemporalDWG Web Utilities

• WebTopicList - all topics in alphabetical order
• WebChanges - recent topic changes in this web
• WebNotify - subscribe to an e-mail alert sent when topics change
• WebRss, WebAtom - RSS and ATOM news feeds of topic changes
• WebStatistics - listing popular topics and top contributors
• WebPreferences - preferences of this web