use temporal ISO terminology

[marqh]

the reference objects for time use bespoke syntax

https://github.com/opengeospatial/CoverageJSON/blob/master/standard_template/standard/clause_specification_text.adoc#52-temporal-reference-systems

which shows some inconsistency with terminology used in ISO19111 and ISO19156

e.g.
TemporalRS

i propose aligning terminology in the 1.0 version

this is likely not impacted by #26 as the scope of projjson does not include the temporal aspects available in 19111 and 19156

[jonblower]

Thanks - this is not my area of expertise so if you can suggest new wording for the spec that would be very useful.

It may also be helpful to consider #56 at the same time, as this also relates to time axes

[marqh]

query itf rfc 3339

[jonblower]

Just a note from the telecon - is "2022-03-30Z" legal, i.e. adding a time zone indicator onto a date (not a date-time)

[marqh]

http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#106

[jonblower]

Adding the "1.0" label as would be useful to resolve this for a first release. This could be a breaking change, so might affect existing usage (although perhaps it's better to make this change now rather than post-1.0).

[marqh]

The referencing by coordinates standard defines a Temporal Coordinate Reference System
http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#30

which is defined to consist of 1 Temporal coordinate system
http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#44
and 1 temporal datum
http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#54

the DateTimeTemporalCS: coordinate values are dateTimes in the proleptic Gregorian calendar as described in ISO 8601 is consistent with the proposed CoverJSON use of datetime strings

this recognises that the 8601 datetime string is a form of coordinate, useful for referencing by coordinates

i think it is sensible to adopt this terminology, and to treat the referencing by time coordiantes using the same standardisation as referencing by spatial coordinates

ISO19111 uses the term TemporalCRS whilst ISO19162 uses the term TIMECRS. i think either is suitable for use here.
perferences?

a minimal JSON encoding of the information structure could be

{
  "type": "TemporalCRS",
  "datum" : {
    "type": "TemporalDatum",
    "calendar": "prolepticGregorian" 
  },
  "coordinate_system": {
  "type": "TemporalDateTime",
  "axis": [
  { "name": "time",
    "abbreviation": "t",
    "direction": "future"
  }
  ]
  }
}

this proposal would require the standardisation of the following terms within coverageJSON, from ISO19111

• TemporalCRS
• TemporalDatum
• TemporalDateTime

I am aware that this is many more characters than the current encoding proposal, a common consequence of adopting standardised structures

[marqh]

an alternative that we could explore is to encourage OGC naming authority to publish a controlled WKT definition of the prolepticGregorian temporalCRS and default to using that via id as with other CRSs

if (e.g.)
http://www.opengis.net/def/crs/OGC/time/gregorian

returned the payload

TIMECRS["DateTime",
  TDATUM["Gregorian Calendar",CALENDAR["proleptic Gregorian"]],
  CS[TemporalDateTime,1],AXIS["Time (T)",future]
             ]

or

TIMECRS["DateTime",TDATUM["Gregorian Calendar",CALENDAR["proleptic Gregorian"]],CS[TemporalDateTime,1],AXIS["Time (T)",future]]

then we could just use the id mechanism and all share this useful standardised definitIon

(then, look to adopt a useful and extensible JSON encoding as part of the projjson CRS encoding at version 1.x)

[chris-little]

Just a note from the telecon - is "2022-03-30Z" legal, i.e. adding a time zone indicator onto a date (not a date-time)

@jonblower @marqh My reading of the specs is that Z is a qualifier of time, so if there is no time, no Z. Then the date retains some ambiguity depending on location., and local time zone adjustment for daylight savings. So it is understandable that "2022-03-30Z" is needed.

Maybe this should be raised with ISO. :-(

[jonblower]

An extra bit of information for this discussion: the definition of "TemporalRS" in the CoverageJSON context seems to be taken from the INSPIRE glossary. See the context.jsonld of the CoverageJSON specification (https://github.com/covjson/specification/tree/master/contexts).

[marqh]

An alternative option that may be worth consideration is to expand the normative standard text to assert equivalence between the specific encoding of temporal reference system

the current coverage json syntax of TemporalRS can be said to be equivalent to the definition of a TemporalDateTime

TIMECRS["DateTime",
  TDATUM["Gregorian Calendar",CALENDAR["proleptic Gregorian"]],
  CS[TemporalDateTime,1],AXIS["Time (T)",future]
             ]

[jonblower]

@marqh I agree with this approach

[chris-little]

query itf rfc 3339

@marqh Just to clarify, IETF RFC 3339 is preferred to ISO8601, as it is a highly restrictive profile ISO8601. ISO8601 is much too flexible a notation and syntax to program fully. IETF RFC 3339 also very carefully does not mention calculating durations, only that the time stamps can be placed in monotonically increasing order. And of course the timestamps are only truly comparable if using the same clock, or coordinated clocks.

[jonblower]

Just a reminder that CoverageJSON doesn't import the whole of ISO8601, but defines a restricted subset. I don't know if this subset corresponds with RFC3339

[chris-little]

@jonblower The restricted subset of ISO8601 used by CoverageJSON is conformant to IETF RFC 3339.

[jonblower]

Presumably RFC 3339 is a superset of the CoverageJSON syntax? I'm just wondering how it would be explained in the specification text (if at all)

[chris-little]

@jonblower As COverageJSON seems to be an even stricter subset of RFC 3339, I do not think theres is a problem. E.g. RFC3339 says it is based on ISO8601, but then goes and optionally allows blank instead of 'T' as the spacer between data and time! I haven't had time to work through the BNF definition. I think that as long as the text same something liek 'based upon', 'uses' etc rather than 'strictly conforms to' we are safe as a comunity standard.
Do you have any way of checking strict adherence to either notation?

[jonblower]

@chris-little currently the phrase used is "ISO8601-based". I guess we could say "RFC 3339-based" but I think the word "based" is doing most of the hard work here - I think this implies that we've based the format on ISO, but are not claiming complete conformance to the whole thing. My sense is therefore that the text is good enough as-is. What do you think?

I also notice that we only say that time coordinates SHOULD use this syntax. I wonder if this is a bit weak and we should go as far as MUST? Technically someone could use their own date/time serialisation and I don't know how we'd know how to deserialise it. Thoughts, @letmaik?

[letmaik]

RFC 3339 doesn't support ±XYYYY which may be useful for climatological time or similar things (Jon, you know the terms better than me).
Regarding "SHOULD", I think this came from the possibility of numeric time values that may be supported through more concrete CRS definitions.

[jonblower]

Good point regarding XYYYY. I think we should leave the text as-is without attempting to claim conformance to any standard.

Regarding numeric time values, I guess we could only use these if we had a full TemporalCRS with a datum and spacing (e.g. "days since YYYY-MM-DD"). I wonder if the following would work:

1. In the current formulation, with a TemporalRS and a calendar, date-times MUST be in the string representation.
2. In a future formulation, we might support TemporalCRS with a datum/spacing, which MUST have a numeric representation.

So in future a CoverageJSON provider might have the choice between an RS and a CRS.

@marqh this also makes me wonder whether the formulation you have above is valid - you are using the DATUM as a way to hold the calendar, but a calendar is not a datum.

[chris-little]

@jonblower @marqh @letmaik I support leaving the "conformance" text based upon as is, as suggested by Jon. Future work has already been identified for temporal aspects. @jonblower will produce a PR leaving normative text as-is, but strengthen statement for use use of Gregorian calendars.

[chris-little]

@jonblower there is probably a mistake in the CoverageJSON schema. @m-burgoyne spotted that TemporalRS is mandatory not optional in schema., in that coordinates are expected to be values AND a string.

[letmaik]

@chris-little It's not clear to me what you're saying about TemporalRS being mandatory. Can you go into more details? I don't see an issue at the moment.

[m-burgoyne]

@letmaik @chris-little on reading the comments in the schema, I suspect the problem may be caused by my using the Trajectory domainType incorrectly. I have been using it to describe the heights along a route, I suspect this will have be changed to a Point series.

[jonblower]

@m-burgoyne I guess that if "height" is the thing that's being measured, then it would be encoded as the range (not the domain), unless I'm misunderstanding? This is how a DEM would usually be recorded.

This might be a bit off-topic for this thread, so do feel free to raise another issue if you want to discuss further.

[m-burgoyne]

@jonblower yes I was returning the data with the height as the range value but defining the axes as a composite with just x and y coordinates.

[jonblower]

If you have height as a function of x and y only then maybe a MultiPoint is the best domain type?

[chris-little]

agreed to merge at 2022-05-18 meeting and relabelled for v1.x development.

[chris-little]

Just a note from the telecon - is "2022-03-30Z" legal, i.e. adding a time zone indicator onto a date (not a date-time)

@jonblower Better late than never, https://www.w3schools.com/xml/schema_dtypes_date.asp allows 'Z'

[jonblower]

Are arbitrary timezones also legal, e.g. "2022-03-30+01:00" also legal? Does there need to be a "T" in there?

[chris-little]

Yes ttime zones are allowed with a data. Of course this is strictly from an XML xsd schema defing data types and using ISO8601 notation, but the examples include:

<xs:element name="start" type="xs:date"/>
<start>2002-09-24</start>
<start>2002-09-24Z</start>
<start>2002-09-24-06:00</start>
<start>2002-09-24+06:00</start>

T only needed if it is a dateTime:
<xs:element name="startdate" type="xs:dateTime"/>
<startdate>2002-05-30T09:00:00</startdate>
<startdate>2002-05-30T09:30:10.5</startdate>

So it is a good foundaton for normative statements