TemporalQuantity

[marqh]

The handling of temporal quantities linked to calendars could be taken out of CoordinateSystemAxis and provided only for TemporalCS entities.

As long as it were possible to have axisUnit able to be null in these cases, this would allow temporal special cases linked to calendars to be handled separately from unitOfMeasure specifications.

This approach could simplify axisUnit, providing functionality in a very similar way to ISO19111:2007, apart from in the new temporal case.

An adapted (and abridged) Coordinate Systems Package UML Diagram for this could be:

Preceding discussions on an alternative proposal for AxisUnit simplification: #34

[marqh]

But all this only addresses whether or not an axis unit is required. We need a decision on whether, and if so how, the rules for temporal CS 'units' having a scalar conversion to SI second needs to be shown in the UML, or are simply described through text.

I agree with this analysis. I think that it is reasonable to describe this and the consequences of the decisions in the text, rather than putting these rules into the UML model.

This is partly motivated by my concern that it is difficult to model.

[RogerLott]

Re @marqh comment "Can we make use of 19103:2015 types directly (do we use a defined namespace for this?)"

19103 is a normative reference so I would have thought that the data types 'integer', 'real' and 'dateTime' need no further clarification.

[RogerLott]

Re @marqh comment "I think the CodeList for CoordinateDataType is not required"

Is an attribute of +coordinateType: [integer/real/dateTime] correct? Is this not a constraint rather than an attribute? And is it constraining coordinateType (something now unexplained) or axisUnit?

[marqh]

Re @marqh comment "I think the CodeList for CoordinateDataType is not required"

Is an attribute of +coordinateType: [integer/real/dateTime] correct? Is this not a constraint rather than an attribute? And is it constraining coordinateType (something now unexplained) or axisUnit?

I think that this is not a constraint on axisUnit.

I think this is about coordinateType, the data type of the coordinate tuple value. I don't think this can be a constraint within the UML, as there is not a thing to constrain within this package.

[marqh]

we could potentially investigate a conditional constraint on individual elements of CoordinateTuples within the CoordinateSet https://github.com/ISO-TC211/ISO19111/blob/master/Figures/Coordinate%20Set%20and%20Metadata.png

but this seemed like a complicated thing to implement to me

[marqh]

a plausible update to https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-350998499 with typing used as discussed:

[jetgeo]

I'm confused. First: On the axisUnit multiplicity: There are many ways of doing this. The point is that we want to have it mandatory for all except the TemporalCS with coordinateDataType=dateTime. We can do it like in the last figure from @marqh , if we are going to have subclasses of TemporalCS.

Second: on the use of 19103-types: I believed the values in coordinateDataType was not the actual data type, but a string explaining what kind of data type is used?

Third: shall the subtypes be of CoordinateSystem or of TemporalCS? Shall TemporalCS be abstract?

[jetgeo]

[marqh]

@jetgeo the update in https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-351058850 makes sense to me. I am content with this model

I think that CoordinateSystemAxis should not be abstract though.

Second: on the use of 19103-types: I believed the values in coordinateDataType was not the actual data type, but a string explaining what kind of data type is used?

I hadn't made this distinction. I am content to keep the codelist if this facet is helpful.

[jetgeo]

Good. Yes, CoordinateSystemAxis must be concrete. I missed that one.

[RogerLott]

Just seen another minor correction needed. In 19111:2007 the CoordinateSystemAxis class attribute was axisUnitID, not axisUnit as in yesterday's version of the model above. Do we have any good reason to change this? I suggest it should be as in 2007, +axisUnitID:UnitOfMeasure.

[jetgeo]

Ok, done.

[desruisseaux]

About axisUnitID: I'm not sure what the "ID" stands for? This attribute is not an identifier, it is an object with more capabilities (conversions, etc.). On a more minor aspect, I'm not sure neither why "axis" is repeated in the attribute name since it is implied by the context (this attribute is defined in a class named CoordinateSystemAxis and there is no other units in this context it could be confused with). What about axisUnit or just unit? I'm neutral about the axis prefix, but I think that the ID suffix is not accurate.

About the CS hierarchy: do we need TemporalMeasureCS since it is practically identical to TemporalCS? We could remove the coordinateType attribute from TemporalCS. I would interpret that as a CS like all others CS (using real numbers and SI-convertible units). Only TemporalCountCS and DateTimeTemporalCS introduce a departure from this general pattern.

About the axis hierarchy: do we need the DateTimeCoordinateSystemAxis subtype? Could DateTimeTemporalCS just uses its association to GeneralCoordinateSystemAxis?

About axis association in non-temporal CS: do we override the axis association in all CS except DateTimeTemporalCS in order to replace (specialize) the target from GeneralCoordinateSystemAxis to CoordinateSystemAxis?

Can we find another name for GeneralCoordinateSystemAxis? Something which would suggest a mathematical line (not necessarily spatial) whose coordinates are not necessarily numeric?

[RogerLott]

About axisUnitID: I have no idea why ID is there. This is how it is in 19111:2007. I want to change 19111:2007 only if it is essental because it is definitely wrong. Here I don't think that is the case. I agree with your sentiment regarding the prefix axis too, and the same applies to axisAbbreviation and axisDirection. Indeed I don't know why axisAbbreviation is actually necessary as IdentifiedObject.alias could be used, but I suppose this makes it clearer that it is something different to an alternative name. Again these are all artefacts from 19111:2007 which I see no compelling reason to change.

"do we need TemporalMeasureCS since it is practically identical to TemporalCS? ... I would interpret that as a CS like all others CS (using real numbers and SI-convertible units)". TemporalMeasure is NOT convertable to SI. Which I think is why we need the class. I find it helpful to have the three subtypes of temporalCS shown. @marqh is re-writing the text around this. I suggest we await for that, which I aim to circulate this week.

"do we need the DateTimeCoordinateSystemAxis subtype?". Removing it would leave the CoordinateSystemAxis class as the only subtype of GeneralCoordinateSystemAxis. Does that make sense? It is tantamount to returning axisUnitID to the same class as the other CSAxis attributes, which we have visited several times already. Even if strictly not necessary, if it does no harm being there (@jetgeo to confirm, please) I think it helps show that dateTime is different to other coordinates.

"do we override the axis association in all CS except DateTimeTemporalCS...?". It is not clear to me how this model requires a CS to have an axisUnitID. Should the CS to GeneralCoordinateSystemAxis association be 0.. with each of the subtypes being associated with CoordinateSystemAxis 1..? Is this what you are suggesting? I leave it to @jetgeo to advise.

Re GeneralCoordinateSystemAxis name. As this is a new class we can call it anything we like. But as a supertype of CoordinateSystemAxis (from 19111:2007) and DateTimeCoordinateSystemAxis, calling it General... is consistent with the use of General... in the Operations package (and for that matter in the GeneralDerivedCRS from 19111:2007 which we have removed).

Time on my (analogue) clock seems to go around and around. These discussions need to stop going around in circles.

[desruisseaux]

DateTimeTemporalCS and TemporalCountCS units are not convertible to SI, but I thought that TemporalMeasureCS has units convertible to SI. If not, which one of those CS subtypes has temporal units convertible to SI?

[desruisseaux]

Indeed, we are going in circles. Can we try to clarify the use cases?

Temporal count:

• Climatological data (not convertible to date)

Temporal SI units:

• NetCDF format (oceanographical data)
• GRIB format (meteorological data)
• Spreadsheets like Excel (even if their dates look like dateTime, they actually use SI units)
• MatLab and other tools performing analysis (spectral analysis, etc.)

DateTime:

• CSV files - but they are often exports of another format using SI units (above list).
• XML and JSON files - used for exchange on the web, but usually not the original data format.

With the two above formats, the implementations I'm aware of (C/C++ and Java) typically convert immediately those dateTime into SI units, with different solutions for leap seconds problem (POSIX standard in C/C++). Could we clarify what else we have as use cases for dateTime coordinates? I do not question that coordinate system axis with dateTime coordinates are valuable. But before to choose a model having an impact on all other CS, I just wonder if we have correctly evaluated the extent of the need for that model (given that alternatives exist - all with different inconvenient)?

[marqh]

on @RogerLott's detail question

It is not clear to me how this model requires a CS to have an axisUnitID.

In the model posted by @jetgeo GeneralCoordinateSystemAxis is abstract where as CoordinateSystemAxis is concrete, so all users of GeneralCoordinateSystemAxis are required to select a subtype, either CoordinateSystemAxis, which mandates axisUnitID or DatetimeCoordinateSystemAxis, which has no axisUnitID available

[desruisseaux]

In the model posted by @jetgeo GeneralCoordinateSystemAxis is abstract where as CoordinateSystemAxis is concrete, so all users of GeneralCoordinateSystemAxis are required to select a subtype, either CoordinateSystemAxis, which mandates axisUnitID or DatetimeCoordinateSystemAxis, which has no axisUnitID available

Indeed, but in current model there is nothing forcing e.g. a CartesianCS to use a CoordinateSystemAxis (unless it is stated in the text somewhere, but it does not appear in the UML). CartesianCS could be associated to DatetimeCoordinateSystemAxis (I agree it make no sense, but above UML does not prevent that) or to another GeneralCoordinateSystemAxis subtype invented by the user. In the later case there is nothing forcing the user to declare a unit in his custom subtype.

If we want the model to require all non-temporal CS to have unit of measurement, we can redeclare (override) the axis association in all those CS, forcing them to point specifically to CoordinateSystemAxis instead than GeneralCoordinateSystemAxis. It would have to be done for all non-temporal CS in ISO 19111. Custom CS defined by users may also need to do something similar.

[pebau]

Another DateTime use case is the whole universe of coverages, supported by many tools and also by the INSPIRE European regulatory framework. Sample temporal subsetting request:

http://www.acme.com/ows ? SERVICE=WCS & VERSION=2.0 & REQUEST=GetCoverage & COVERAGEID=c001 & SUBSET=Long(100,120) & SUBSET=Lat(50,60) & SUBSET=time("2009-11-06T23:20:52","2011-10-06T23:20:52")

Applications include orthoimagery, image timeseries, elevation, atmospheric data + weather forecasts, thematic products, and many more. Petabytes of data are meantime accessible via WCS/WCPS.

-Peter

[desruisseaux]

@pebau yes, but I wonder if our difficulties in this thread is partially caused by a confusion between (spatial or temporal) coordinate and string representation of that coordinate? The "2009-11-06T23:20:52" character sequence can be two things:

• A dateTime structure with 6 fields (year, month, etc.) having values 2009, 11, 6, 23, 30 and 52. The ISO 8601 string representation of that data structure is "2009-11-06T23:20:52".
• An ISO 19103:2015 TimeMeasure structure associated to an ISO 19103 UomTime of "days" and a single numerical value of 14554.9728240741 (assuming POSIX epoch). The string representation of that TimeMeasure can be "2009-11-06T23:20:52" as well (at implementation choice).

For those using Java, the former is a java.time.LocalDateTime instance and the later is a java.time.Instant instance. Both are fundamentally different data structures despite having (almost) the same string representation.

My claim is that almost all spatio-temporal coordinate values used in common data cubes are fundamentally ISO 19103 Measure, e.g. lengths or durations measured since axis origin (ignoring the discrete nature of rasters for this discussion). All those measures are associated to an ISO 19103 UnitOfMeasure. I claim that this is true even for temporal axes. In my handling of spatio-temporal data (first as an oceanographer), I have seen dateTime in metadata or datum definition but rarely on temporal axis except in climatology (months or weeks without year). It does not means that temporal coordinates are shown to the users as numbers; the values are typically converted to some date/time format at rendering time. For example when Excel plots a XY graph with a time axis, the X axis values are days since December 31th, 1899 but are rendered by Excel as dates. I think that ISO 19111 should focus on what the coordinates are fundamentally (i.e. single numbers) and not on how they are rendered to the users.

Please correct me if I'm wrong, but I would bet that in RASDAMAN too, when you receive the "2009-11-06T23:20:52" string, one of the very first processes applied by RASDAMAN is to convert that string into a single numerical value (not a dateTime structure with 6 fields) on a time axis of your choice, so you can use that number like any other dimensions in indexes, envelopes, computing intersections, etc.

For WCS/WCPS, my proposal would be that a spatio-temporal CRS should be specified with a time axis with an origin and a unit of measurement (e.g. "days since 1980-01-01T00:00:00Z") like any other axis. Then for the SUBSET=time(…) part, users could have two choices:

1. (S)he can use days as specified by the TemporalCRS if (s)he wish, e.g. SUBSET=time(1000, 1250). This is more convenient than dates if (s)he wants to iterate over data with a step of 500 days for instance.
2. (S)he can use dates if (s)he prefer, e.g. SUBSET=time("2009-11-06T23:20:52", "2011-10-06T23:20:52"). In such case it is server's responsibility to convert those string representations into days since 1980-01-01 before to proceed. Note that this conversion is non-ambiguous with POSIX standard even in the presence of leap seconds, but the server is free to use another standard than POSIX if it wishes.

In some cases ISO 8601 dates are not convertible to the UomTime used by the TemporalCS. Then we have a choice:

• The time is a count of something, e.g. climatological months, not convertible to any SI units. This is the TemporalCountCS in above UML. In such cases only the example 1 above (using numbers) is allowed by a WCS server, and the example 2 (using dates) is disallowed.
• The time is a not a single number but instead a (year, month, etc.) tuple on something different than the Gregorian calendar (if it was Gregorian calendar, we would know how to convert it to POSIX time). This is the DateTimeTemporalCS case in above UML. In such case only the example 2 above (using dates) is allowed by a WCS server, and the example 1 (using numbers) is disallowed.

Part of the complexity in this thread come from attempts to support the DateTimeTemporalCS case. My question is: is it really worth all the difficulties given that I think temporal axis are almost never - at the fundamentally level - DateTimeCoordinateSystemAxis? Keeping in mind that in Peter's example the temporal axis is still fundamentally an axis of numerical values (usually) and the ISO 8601 dates are just an alternative string representation to be converted by the server?

[RogerLott]

In going through the 19111 document ahead of circulating a final draft to the EC for their review, I had some trouble with definitions for some of the temporal-related classes and attributes. I have come to the view that a half-way position between some of the models above is appropriate. This model needs to be read in conjunction with the definitions and now significantly rewritten text and examples in 19111, particularly in annex D and annex E.4, so please look at these descriptions. The real problem is incorporating a DateTime string in accordance with ISO 8601 - and that is going to be the majority use case of a time dimension so it is important that it is supported. But to also support the temporal count and temporal measure cases (which can be modelled like other CS types) I think we need these as separate subtypes of temporalCS - as described in the 19111 text which you have yet to see - hopefully circulated later today. Other than modifying the cardinallity of axisUnitID so that it can be subtyped for DateTime and the compensating the additional constraint as originally suggested by @jetgeo , the CoordinateSystemAxis class is now back to how it is in 19111:2007. This is the version that will be in the soon to be circulated updated 19111 draft.