Context Navigation

Changes between Version 12 and Version 13 of PetascopeTimeHandling

Timestamp:: Feb 27, 2014, 6:18:57 PM (11 years ago)
Author:: Piero Campalani
Comment:: proof read

Legend:

: Unmodified
: Added
: Removed
: Modified

PetascopeTimeHandling

-              v12
+              v13
    * [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/AnsiDate ANSI date] (`OGC:AnsiDate`) : linear count of days (labelled `'ansi'`) since 1^st^ of January 1601, 00h00 UTC (note that decimal coordinates are possible to reference fraction of the day).
    * [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/AnsiDate ANSI date] (`OGC:Temporal`) : parametrized CRS for the user-friendly definition of a custom T-CRS: it resolves to a concrete definition of T-CRS as long as the ''epoch'' and the ''UoM'' are explicitly set in the query of the URI (and optionally an axis label and an axis direction: defaults are `'t'` and `'future'`). !UoMs can be defines as either [http://unitsofmeasure.org/ucum.html UCUM] `c/s` codes or actionable URIs pointing to valid GML definition of !UoMs; UCUM codes or URIs like http://www.opengis.net/def/uom/UCUM/0/<code> (which the OGC SISSVoc redirects to the UCUM web page) or codes are suggested here: our ISO timestamp parser relies on UCUM codes too.
+   * [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Temporal?expand=none parametrized temporal CRS] (`OGC:Temporal`) : parametrized CRS for the user-friendly definition of a custom T-CRS: it resolves to a concrete definition of T-CRS as long as the ''epoch'' and the ''UoM'' are explicitly set in the query of the URI (and optionally an axis label and an axis direction: defaults are `'t'` and `'future'`). !UoMs can be defined as either [http://unitsofmeasure.org/ucum.html UCUM] `c/s` codes or actionable URIs pointing to valid GML definition of !UoMs; UCUM codes or URIs like ''http://www.opengis.net/def/uom/UCUM/0/<code>'' (which the OGC SISSVoc resolver redirects to the UCUM web page) or codes are suggested here: our ISO timestamp parser relies on UCUM codes too.
 For a full list of time resources under review by OGC-NA please visit [http://external.opengeospatial.org/twiki_public/TemporalDWG/TemporalCrsUris this page] (active participation is also appreciated via [https://lists.opengeospatial.org/mailman/listinfo/temporal mailing list]). After official acknowledgment of such resources, all of them will be provided by our resolver and additionally by the official 'opengis' servers.
+For a full list of time resources under review by OGC-NA please visit [http://external.opengeospatial.org/twiki_public/TemporalDWG/TemporalCrsUris this page] (active participation is also appreciated via [https://lists.opengeospatial.org/mailman/listinfo/temporal mailing list]). After official acknowledgment of such resources, all of them will be provided by our resolver and additionally by the official [http://www.opengis.net/def/crs/ opengis] servers.
 Still, especially thanks to our customizable `OGC:Temporal` CRS, it is possible to start deploying spatio-temporal (but also purely temporal) coverages via `rasdaman`/''Petascope''.
 While all kinds of T-CRS are possible with `OGC:Temporal`, you might decide to create your own definitin so to have a more meaningful URI. This can be easily achieved: in spite of the verbose GML representation, what is actually important for Petascope in a T-CRS is:
+While all kinds of T-CRS are possible with `OGC:Temporal`, you might decide to create your own definition so to have a more meaningful URI. This can be achieved relatively easily in spite of the verbose GML representation. What is actually important for Petascope in a T-CRS is:
    * the datum origin (we assume UTC default)
+   * the datum origin (`gml:origin`) (''we assume UTC as default time zone if that is not specified'')
    * the axis time step (`gml:CoordinateSystemAxis/@uom`)
    * the axis label (`gml:axisAbbrev`)
 …
    * simulation-time : [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/AnsiDate?axis-label=%22simulation_time%22 http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/AnsiDate?axis-label="simulation_time"]
 For further info on CRS parametrization and composition, see the SECORE [SecoreUserGuide user guide] and also [wiki:IndexCrss#Changingaxislabels] section.
+For further info on CRS parametrization and composition, see the SECORE [SecoreUserGuide user guide] and also [wiki:IndexCrss#Changingaxislabels this] section.
 == Using and understanding time in WCS/WCPS
 Once a T-CRS has been successfully embedded in the overall native CRS of a coverage, the WCS/WCPS services will accept both numerical and time coordinates on the time axis/axes.
+Once a T-CRS has been successfully embedded in the overall native CRS of a coverage, the WCS/WCPS services will accept both numerical and alphanumerical time coordinates on the time axis/axes.
 In the first place, one should also be aware of the difference between the time resolution (UoM) of the T-CRS and the adopted ''offset vector'' ruling the spacing along time for the coverage: on 1-norm vectors there is no such difference, however it is perfectly possible to use either a bigger vector (e.g. equal to 7 on a day-resolution T-CRS for weekly data) or a fractional one. For more on offset vectors l please refer to the ''Petascope'' [PetascopeUserGuide user guide].
+In the first place, one should be aware of the difference between the time resolution (UoM) of the T-CRS and the adopted ''offset vector'' ruling the spacing along time for the coverage: with 1-norm vectors there is no such difference, however it is perfectly possible to use either a bigger vector (e.g. equal to 7 on a day-resolution T-CRS for weekly data) or a fractional one. For more on offset vectors please refer to the ''Petascope'' [PetascopeUserGuide user guide].
 As with normal spatial axes, a WCS/WCPS subsets shall define numeric trimming and slicings on a CRS dimension. The [https://portal.opengeospatial.org/files/?artifact_id=50140 standard] however let the subset syntax adhere to EBNF [IETF 2616], allowing ''tokens'' inside double-quotes: on time dimensions then ISO:8601 datetime representations can be used in place of the usually less friendly numeric time coordinates.
+As with normal spatial axes, a WCS/WCPS subsets shall define numeric trimming and slicings on a CRS dimension. The [https://portal.opengeospatial.org/files/?artifact_id=50140 standard] additionally adhere to EBNF syntax [IETF 2616], allowing ''tokens'' inside double-quotes: on time dimensions then ISO:8601 datetime representations can be used in place of the usually less friendly numeric time coordinates.
 Implementation-wise, the support for ISO datetime is extended by ''Petascope'' thanks to the [http://www.joda.org/joda-time/ Joda-Time] Java library. The datetime formatter used to convert literal to numeric time representations is the official ISO date formatter with optional time, which then permits dates only or dates plus time (plus time zone shits). When a time zone is not defined, the library takes the default time zone of the underlying JVM, hence it was decided to instead force a UTC default time zone, to avoid platform-dependent behaviors.
+Implementation-wise, the support for ISO datetime is extended by ''Petascope'' thanks to the [http://www.joda.org/joda-time/ Joda-Time] Java library. The datetime formatter used to convert literal to numeric time representations is the official ISO date formatter with optional time, which then permits dates only or dates plus time (plus time zone shifts). When a time zone is not defined, the library takes the default time zone of the underlying JVM, hence it was decided to force a UTC default time zone instead, to avoid platform-dependent behaviors.
 Formally, the allowed input datetime strings are (taken from [http://www.joda.org/joda-time/apidocs/org/joda/time/format/ISODateTimeFormat.html#dateOptionalTimeParser() Joda-Time API]):
 …
 For practical examples see our related [browser:applications/petascope/src/test/java/petascope/util/TimeUtilTest.java unit tests] or our WCS [browser:systemtest/testcases_services/test_wcs/queries systemtest queries] n.{27-28, 35-37}.
 Regarding the responses to a WCS request, time is encoded in its numerical form. The T-CRS definition is the key to decode the meaning of such numbers: while sometimes well-known T-CRS can be used (as Unix time), the general principle is that the time coordinate `T'` is the representation of `(v_t*T')` time steps (T-CRS UoM) from the epoch of the T-CRS, being `v_t` the scalar norm of the offset vector of the coverage along time.
 In order to ease the user, it is foreseen the use of `gml:EnvelopeWithTimePeriod` (see #678) to additionally provide literals of time in the bbox of a coverage.
+Regarding the responses to a WCS request, time is encoded in its numerical form. The T-CRS definition is the key to decode the meaning of such numbers: while sometimes well-known T-CRS can be used (as Unix time), the general principle is that the time coordinate `T'` is the representation of `(v_t*T')` time steps (i.e. T-CRS !UoMs) from the epoch of the T-CRS, being `v_t` the scalar norm of the offset vector of the coverage along time.
+In order to ease the understanding of a GML response, it is foreseen the use of `gml:EnvelopeWithTimePeriod` (see #678) to additionally provide literals of time in the bbox of a coverage.
 …
 In addition to the inclusion of time in the compound CRS where a coverage is located, importing irregular time series in [PetascopeUserGuide Petascope] is also possible, although this not connected to the definition of perhaps a different T-CRS. The topology of a coverage (along the time dimension in this case) is independent of the way time is measured.
 To import irregular time series you can either manually fill in the so-called vector weighting '''coefficients''' of the offset vector along time (see the ''Petascope'' [PetascopeDevGuide dev-guide]) or otherwise use our ''rasgeo'' component to handle the irregular time series directly with absolute time coordinates via the `'--z-coords'` parameter of `rasimport` (see [RasgeoUserGuide user guide] for more details.
+To import irregular time series you can either manually insert in `petascopedb` the so-called vector weighting '''coefficients''' of the offset vector along time (see the ''Petascope'' [PetascopeDevGuide dev-guide]) or otherwise use our ''rasgeo'' component to handle the irregular time series directly with absolute time coordinates via the `'--z-coords'` parameter of `rasimport` (see [RasgeoUserGuide user guide] for more details).
 To better understand the meaining of (GML) weighting vector [http://schemas.opengis.net/gml/3.3/referenceableGrid.xsd coefficients], the general principle to decode numeric time coordinates is that the time coordinate `T'` is the representation of `[(c_i*v_t) * T']` time steps (T-CRS UoM) from the epoch of the T-CRS, being `v_t` the scalar norm of the offset vector of the coverage along time and `c_i` the coefficient associated to the `i`-th level in time.