crs-compound: Support compound CRS including ISO-8601/Gregorian

[jerstlouis]

Currently, Common and Features reference http://www.opengis.net/def/uom/ISO-8601/0/Gregorian as the temporal reference system.

However, that does not resolve with http://www.opengis.net/def/crs-compound as can be seen e.g. with:

http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4326&2=http://www.opengis.net/def/uom/ISO-8601/0/Gregorian

This is preventing to define spatio-temoral reference systems that would be commonly used with OGC API - Coverages.

This may be because that definition is currently mistakenly defined as a unit of measurement rather than a CRS or TRS.

Related to opengeospatial/NamingAuthority#101

[ghobona]

On 2021-09-14 the OGC-NA discussed the http://www.opengis.net/def/crs-compound URI and agreed that:

• The service offered by the http://www.opengis.net/def/crs-compound URI is out of the scope of the OGC-NA's charter since it is not an identifiable or nameable resource. Therefore, the OGC-NA agreed to deprecate it and keep it running for sometime. The deprecated object would be annotated and a solution offered.
• OGC-NA recommended that the Architecture DWG or the Coverages DWG could work with the OGC Infrastructure Office to move the service to a new URI (outside of http://www.opengis.net/def/)

This issue is therefore being transferred to the GitHub repo of the Architecture DWG.

[pebau]

@ghobona

I don't think that this has been assessed properly by OGC-NA. crs-compound is the only way to properly define multi-dimensional CRSs that are not predefined (which is a common case, due to the exponential number of possible combinations).

With the same argument BTW OGC-NA must deprecate the WMS AUTO CRSs - they likewise are not identifying CRSs.

As this so much ignores common sense, is it motivated politically?

[pebau]

Currently, Common and Features reference http://www.opengis.net/def/uom/ISO-8601/0/Gregorian as the temporal reference system.

However, that does not resolve with http://www.opengis.net/def/crs-compound as can be seen e.g. with:

of course not!!

• uom is not crs
• this has never been registered with the resolver, so the resolver obviously cannot know it.

This is preventing to define spatio-temoral reference systems that would be commonly used with OGC API - Coverages.

not at all. Coverages are using time coordinates since many years because the resolver DOES know time CRSs.

[jerstlouis]

@pebau

I don't think that this has been assessed properly by OGC-NA. crs-compound is the only way to properly define multi-dimensional CRSs that are not predefined (which is a common case, due to the exponential number of possible combinations).

and a solution offered.

The way forward would be to support an array of CRSes to compound instead for the srsName, as we are discussing in opengeospatial/coverage-implementation-schema#18 (comment) .

Coverages are using time coordinates since many years because the resolver DOES know time CRSs.

The problem is that we are missing a simple proper CRS for Gregorian time. There are serveral issue with the use of the AnsiDate and UnixTime ones. There was some initial discussion at a recent Members Meeting in the Temporal DWG ( see opengeospatial/NamingAuthority#101 ), I am not sure what the latest status is ( @chris-little ? :) )

[ghobona]

@pebau

The issue is not whether crs-compound is useful or not. The issue is whether crs-compound falls within the scope of the work allowed by the OGC-NA Charter. The OGC-NA considered this and arrived at the decision documented in Issue opengeospatial/NamingAuthority#93 (comment) that crs-compound falls out of scope of the remit specified in the Charter.

So the question then becomes whether a resource that is outside of the scope of the OGC-NA's Charter can be offered through http://www.opengis.net/def . This question is probably answered by the fact that OGC Coverage Implementation Schema with Corrigendum (OGC 09-146r8) references the crs-compound service, so the TC has authorised the crs-compound service to be offered through http://www.opengis.net/def . So there is justification for not changing the URL.

So the next question is, considering the current Charters, which working group/sub-committee should have control over the crs-compound service? I will arrange a joint Architecture DWG and OGC-NA telecon after the December 2021 OGC Member Meeting to discuss this question.

[jerstlouis]

@pebau @ghobona See also opengeospatial/coverage-implementation-schema#7 and opengeospatial/NamingAuthority#119 (comment) for discussion of how crs-compound is not a practical solution going forward, and why it makes sense to deprecate it and maintain it only for backward compatibility reasons.

An array of CRSes (or multiple CRS tags in XML) to be compounded serves the exact same purpose in a way much easier for clients to understand

• without a dependency on accessing a service which doesn't suit either performance or offline scenarios,
• without having to parse some kind of resulting CRS definition,
• without having to parse the query parameter inside of a URI which should really be treated and recognized as an opaque string,
• without the issues plaguing the current crs-compound service where inverting the 1 and 2 query parameter causes errors,
• without a particular service needing to be aware about all possible CRSes to be compounded,
• allowing to simply rely on being able to recognize the URIs of CRSes to be compounded.

I think efforts should focus on finding the proper solution going forward (i.e. what needs to be done with CIS and GML so that multiple CRSes to be compounded can be specified for srsName).

[pebau]

@jerstlouis just in brief, too busy currently: there are a few wrong points above, and some points are already given by the current resolver practice.

Also, not sure we want to impose JSON now everywhere, including situations that have no real need for it. I remember XML trying that years back, and we may not want to repeat the headaches.

[jerstlouis]

@pebau When you have a chance, it would be good to know what is wrong with the points above.

The idea is not to impose JSON everywhere at all: any other encoding would also be able to provide multiple CRSes to be compounded, including XML/GML.

[chris-little]

@jerstlouis As an aside, the view of the Temporal DWG, for a long time, has been that "a Calendar is not a temporal CRS is not a Calendar". E.g. Gregorian is generally a calendar, and not analogous to spatial CRSs, whereas temporal CRSs are things like Unix Time, Julian Days, chronometricGeologicalTime, etc., and have a strong analogy to spatial CRSs.
ISO19111:2019 reflects this by defining temporal reference system which may be a temporal coordinate reference system, or a calendar or an ordinal temporral reference system.

[jerstlouis]

@chris-little The problem I think with all these nuances is that there is a lack of clarity & consistency, and us poor implementers are left with nothing that works in practice.
e.g. it was previously clarified that the http://www.opengis.net/def/trs branch was obsolete and instead TRSes should be defined at http://www.opengis.net/def/crs, but there is still nothing there to specify both Date & Time in a reference system that makes sense to specify as ISO 8601 string (not UnixTime). OGC API - Features - Part 1 and Common - Part 2 (and EDR as well I believe) all reference a "trs". I believe it was also clarified that a date and time (e.g. as in ISO 8601) is a valid way to identify a unique position in a TRS. From OGC API - Features (right below Permission 4):

trs: description: Coordinate reference system of the coordinates in the temporal extent (property interval). The default reference system is the Gregorian calendar. In the Core this is the only supported temporal reference system. Extensions may support additional temporal reference systems and add additional enum values.
type: string
enum:
- 'http://www.opengis.net/def/uom/ISO-8601/0/Gregorian'
default: 'http://www.opengis.net/def/uom/ISO-8601/0/Gregorian'

And here we have the uom / trs confusion.

[chris-little]

@jerstlouis Does this help:

[jerstlouis]

@chris-little Thanks. I would love to say that it does :) Do the bottom boxes derive from the upper ones? To try to make sense of this:

Is it that bottom ISO 19111 box that would be referenced by srsName in CIS or by the interval trs in an OGC API collection temporal or additional dimension extent? And since it doesn't inherit from Calendar, can it still use a Gregorian-based CRS / ISO 8601 strings, as specified by OGC API - Features (and as proper CIS examples would do, if we had such a Gregorian calendar-based TRS)?

[chris-little]

@jerstlouis And since it doesn't inherit from Calendar, can it still use a Gregorian-based CRS / ISO 8601 strings, as specified by OGC API - Features . Strictly no, that is why it was constructed that way.

You could use the ISO8601 notation to describe a proper Temporal CRS i.e. only one UoM (say milliseconds, or years) but the notation strictly would not let you specify a duration of more than 60ish seconds, or more than 30 ish days.
This is one reason why, in OGC API-EDR, we allow the option of either a strict TCRS, specified in WKT (Unix Seconds), or Gregorian/ISO8601 calendar notation.

There was an attempt several years ago to try to decouple the ISO8601 notation from the Gregorian semantics, and extend it to cover some TCRSs, like the WMS1.3 notation for intervals/layers, but it didn't get anywhere.

I think this area could be a useful, but not easy task, for the Temporal DWG in the future providing ISO is amenable too.

I am not sure how the diagram should be interpreted in detail, as I just stole it from the DGGS people. There are no multiplicity indicators etc on the diagram. And I repeat my mantra:

[jerstlouis]

@chris-little The slight problem with that mantra, is that while in theory those are in fact different concepts, in practice the OGC API specifications require a proper temporal reference system supporting a calendar-based notation for date+time :)

I think even if multiple numbers are used (year, month, day, hour, minute, second, milliseconds...) to express a position on the temporal axis, it is still technically a "single coordinate" / "single unit", as it points to a single point in time, just like "Unix seconds since Jan 1, 1970". This is not really different than decimal degres vs. degree/minutes/seconds, except for the extra complexity of dealing with months, leap years & leap seconds.

As long as a fixed set of rules is established as to how to interpret such elements of the temporal coordinate (e.g. from an ISO 8601 notation string), then I hope such a "ISO 8601 / proleptic Gregorian calendar / UTC time scale TRS" should be a proper TRS where the natural notation is ISO 8601, rather than some other arbitrary concept like UnixTime seconds since 1970.

[chris-little]

@jerstlouis The problem is As long as a fixed set of rules is established - leap seconds are only decided about 6 months in advance. And who agrees that the proleptic Gregorian calendar has a year 0? Lots of people do not agree.
And are users aware that dates in documents do not correspond to (proleptic) Gregorian? The date for switching from the Julian calendar could be as late as 1922 in some locations. And of course the year number may increment on 26 March in 1751 in England but 1 January in Scotland. No idea what happened in Canada.
There was a long debate in the CF-NetCDF community about setting up various timescales for "ISO 8601 / proleptic Gregorian calendar / UTC time scale TRS". They could not agree on a single one.

And even Apple could not code the correct algorithm for leap days in 2012.

So "a fixed set of rules" is another work item for the Temporal DWG?

[jerstlouis]

@chris-little

The problem is As long as a fixed set of rules is established - leap seconds are only decided about 6 months in advance.

The fixed rules can simply cite "leap seconds as decided by the relevant authority".

And who agrees that the proleptic Gregorian calendar has a year 0? Lots of people do not agree.

From https://en.wikipedia.org/wiki/ISO_8601 it says

An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[21] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.

I am not sure how accurate that is -- as long as an agreement is made as to how it works, then things can be well defined, and hopefully following the ISO 8601 best practices.

And are users aware that dates in documents do not correspond to (proleptic) Gregorian? The date for switching from the Julian calendar could be as late as 1922 in some locations.

This mostly seems like a documentation / "implementors beware" aspect.
I was not aware the switch happened so late in some places! But the goal being to standardize on one general purpose TRS for everywhere / everywhen on Earth.

There was a long debate in the CF-NetCDF community about setting up various timescales for "ISO 8601 / proleptic Gregorian calendar / UTC time scale TRS". They could not agree on a single one.

It really should be possible to define a TRS based on the most accurate current timekeeping practices, plus standardize one way to handle older dates.

And even Apple could not code the correct algorithm for leap days in 2012.

It should at least be possible to specify it right, even if it is not so straightforward to code.

So "a fixed set of rules" is another work item for the Temporal DWG?

Well, yes, I imagine that this would make up the essence of this general purpose TRS! :)