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

[RogerLott]

I feel that something along these lines may be the appropriate way forward. It preserves exactly the existing data model for all CS subtypes, so addresses Martin's principle problem of an additional step, except for temporal CS which is in any case remodelled.

A few (I believe minor) amendments: i) Rename the UnitlessCoordinateSystemAxis as TemporalCoordinateSystemAxis ii) Move the two attributes coordinateType and temporalQuantity from the TemporalCS class to the Unitless/TemporalCoordinateSystemAxis class as they are attributes of the axis. iii) Transpose the cardinality of these two attributes - make temporalQuantity mandatory (analogous to axisUnitID for other CS subtypes) and because of this make coordinateType optional. iv) Move the dateTime attribute from CoordinateDataType to TemporalQuantity. In conjunction with the above this eliminates the current duplication of dateTime for an 8601 string.

The TemporalQuantity (formerly pseudoUnit) class now has an attribute +second, in place of +discreteQuantity. This requires some explanation.

[jetgeo]

I think this would work. However, instead of repeating the axisUnit attribute in TemporalCoordinateSystemAxis, I would prefer to use an abstract class, as shown in the figure bellow. I have not added the "second" value to the CodeList, avaiting your decission on this.

[RogerLott]

The above model would, I believe, result in the three examples in the attached 19111 Annex E4 Examples.docx .

[marqh]

@jetgeo Hi Knut

This (https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-347984611) looks neater to me. A detail point: in the CodeList TemporalQuantity, the entry 'discreteQuantity' is no longer required, it will not be used by TemporalCS instances. However a new entry is required: 'second', as this is no longer available as an UnitOfMeasure.

thank you mark

[RogerLott]

Mark, could you clarify what this second is (SI second, duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom [13th CGPM (1967)] ??) and when it would be used, please.

[marqh]

A consequence of this model is that it is no longer possible to have an OrdinalCS with no unit of measure.

For image space, this is not an issue, as an OrdinalCS with two CoordinateSystemAxis instances, each with an axisUnit of '1' is a good representation of pixels.

However, for pure index space, there really is no valid unit of measure.

I do not have a use case for providing referencing by coordinates where those coordinate values are index values with no valid unit of measure, but I wondered if it was supposed to be in scope. I want to point out that I think this could have been provided for by our previous draft, where as this proposal appears to make that impossible to represent.
Are contributors comfortable with this?

[marqh]

Mark, could you clarify what this second is (SI second, duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom [13th CGPM (1967)] ??) and when it would be used, please.

Yes, this is the SI second.

It would be used to record a time coordinate tuple as a number of seconds since a defined datum. For example, unix time (nowish):

• 1512042333
  • seconds
  • datum
  • origin 1970-01-01T00:00:00Z
  • calendar ProlepticGregorian

[desruisseaux]

This new model is proposed on the basis that temporal quantity based on calendar would not be valid unit of measurement. But is it really the case? A coordinate value is an amount of something since axis origin. The axis unit just said what this "something" is. Having a count of something in calendar case is not so different than other units of measurement. For example:

• The SI "mole" fundamental unit is also a count of something (an amount of substance).
• The Unified Code for Units of Measure (UCUM) defines many units used in medicine or in chemical and biochemical laboratories that are not based on SI units.

One objection was that ISO 19103 UnitOfMeasure defines methods for performing unit conversions and those methods may be inappropriate for calendar units. But in any system of units there is restrictions on the unit conversions that may apply:

• It is illegal to convert units of different dimensions (e.g. metres to seconds) in SI system.
• Even when two units have the same dimension, conversions may still be illegal. For example Energy and Torque have the same dimension (kg.m2/s2) but are nevertheless unconvertible. Angle, sigma-level and salinity are all dimensionless units, but nevertheless unconvertible.

So I don't think that calendar units introduce a greater risk of misuse than other units. I have the feeling that this discussion may exist because we are trying to put too much calendar mechanic in CoordinateSystem. It should not. A CoordinateSystemAxis with "calendar month" unit of measurement can be defined as below:

Case 1:

• CoordinateSystemAxis.axisUnit = calendar month
• CoordinateSystemAxis.minimumValue = 1
• CoordinateSystemAxis.maximumValue = 12
• CoordinateSystemAxis.rangeMeaning = RangeMeaning.exact

In this example, after we reached month 12 we can not move further. There is no month 13, and we do not continue with month 1. This is like latitude axis where there is nothing north of 90°N.

Case 2:

• CoordinateSystemAxis.axisUnit = calendar month
• CoordinateSystemAxis.minimumValue = 1
• CoordinateSystemAxis.maximumValue = 12
• CoordinateSystemAxis.rangeMeaning = RangeMeaning.wraparound

In this example, after we reached month 12, the next month is 1 of no particular year. This is not month 1 of next year. It is like the longitude axis, where after 180°W we wrap to 180°E. So the question about how months relate to other calendar quantities is not needed in this example.

Case 2:

• CoordinateSystemAxis.axisUnit = calendar month
• No maximum value and no range meaning

In this example, after we reached month 12, the next month is 13, then 14, etc.. Contrarily to the two previous examples, in this example the time axis expands to infinity. But there is still no relationship with other calendar quantities here. We are counting the amount of months since axis origin, not some (month, year) tuple.

In summary, it is not clear to me why we need to care about calendar in CoordinateSystem. I understand that we may want to warn the user that a particular "calendar day" unit is not convertible to SI seconds, but I don't think it is an argument for saying that such calendar day is not some kind of unit of measurement (just not SI-related). The fact that some units are not convertible despite having the same dimension occurs even between SI units.

[RogerLott]

We got into this discussion because those interested in temporal CRSs stated that axisUnit.UnitOfMeasure was unsuitable for temporal application, on two grounds: i) term 'unit' is disliked - 'temporal quantity' is preferred. ii) the understanding that UnitOfMeasure requires a ratio to an SI base unit (second for time) and that this was not always possible.

The principle objection to be overcome is (ii).

[desruisseaux]

I don't think that UnitOfMeasure is unsuitable for temporal applications. To me, it seems that we are confusing DateTime and Measure. A DateTime has many fields (day, month, year, etc.) with complicated rules. But coordinate values are single number with a unit. They are not (day, month, year) tuples, and consequently I think that calendar rules are irrelevant to coordinate values.

ISO 19103 defines UnitOfMeasure as "a quantity adopted as a standard of measurement for other quantities of the same kind". I see nothing in this definition that prevent the use of units outside SI. The UnitOfMeasure class has scaleToStandardUnit and offsetToStandardUnit attributes, but they are optional and UML documentation said "conversion to ISO standard unit is not null only is the conversion is a simple scale".

Numerous units without conversions to SI exist. I gave links to units used in medicine or in chemical and biochemical laboratories above. Another example are currencies, which are considered as units of account.

On the objections:

term 'unit' is disliked - 'temporal quantity' is preferred.

They are not the same thing. A temporal quantity can be any value. A unit is a temporal quantity adopted as a standard for measuring other temporal quantities. Maybe the intend was to said "temporal amount" (e.g. "month amount"). I use the word "amount" for consistency with amount of substance (unit mol). I see nothing preventing a user to define an "amount of months" if he wish a quantity distinct from the usual time quantity.

the understanding that UnitOfMeasure requires a ratio to an SI base unit (second for time) and that this was not always possible.

This is not required by ISO 19103 UnitOfMeasure as I read it, and not required by common usage neither as far as I know.

[dr-shorthair]

Yes, I agree. Calendars and clocks use rules to convert a position on a timeline into a multi-element value. An inverse rule can be used to convert back to a temporal coordinate, which has a unit of measure and a datum. Commonly used temporal coordinate systems are

• Unix time - unit-of-measure is seconds since 00:00:00.000 UTC on 1st Jan 1970
• Julian day - unit of measure is days since 1st Jan 4713 BCE
• Geochronologic time - unit of measure is years before 1950

A temporal coordinate is a position, not a measure. A temporal duration is a measure.

[RogerLott]

John Herring's view on the meaning of the note attached to UnitOfMeasure "conversion to ISO standard unit is not null only if the conversion is a simple scale" is that in general a conversion to an SI unit is required but not if that conversion is more complex than a scalar value. So axisUnit.UnitOfMeasure can be used for TemporalCS in the same way as for other CS subtypes.

[desruisseaux]

Then, I think that we don't need anything special (no AxisUnit, PseudoUnit or SystemOfUnits). A calendar month can be just an ordinary UnitOfMeasure with conversion factors left to null.

[marqh]

There is nuance here and I can see utility in both perspectives to an extent. We are discussing a subtlety of interpretation and implementation.

A useful reference for terms is JCGM 200:2008 International vocabulary of metrology — Basic and general concepts and associated terms https://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf which defines:

1.9(1.7) measurement unit unit of measurement unit real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the two quantities as a number (p 6)

1.2(1.1,Note 2)
kind of quantity kind aspect common to mutually comparable quantities

1.1(1.1) quantity property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference

The challenge I want to clearly address is that for many temporal quantities, the only way to handle them is to state that they can only be interpreted with respect to a calendar, they can never be expressed as the ratio of the quantities as a number. The location within the calendar has an effect on how size is interpreted, it is not consistent.

My assertion is that the exceptions to this are nuanced and not worth handling and that it is safer and clearer to state that all temporal quantities are independent, not units of measure and that any interpretation needs to use the calendar. This is the case for the ISO Gregorian calendar and is predominantly the case for other calendars that others may want to use (but are out of scope for 19111) This is the core of the proposal that has been in the 19111 draft for some time.

Handling all of these temporal quantities as units of measure and relying on the individual implementations and usage to define each as a UnitOfMeasure with 'null' conversion factors seems risky and prone to errors and inconsistencies to me.

I don't see any way to mandate this and I am concerns that in the real world usage, this will default back to calling these units of measure and treating the calendar as a non-useful aspect.

I think leaving this detail to implementations will undermine the standardisation of temporal coordinate reference system use.

If all of these TemporalQuantities are UnitsOfMeasure there is nothing to limit an implementation from interpreting months as 365.24/12 24 60 * 60 seconds in call cases. This is never a good thing I think the standard should prevent this, not leave it as an implementation detail choice.

I find it preferable to make the clear statement in the standard that all of these quantities are not treated as UnitOfMeasure instances and no conversion between them is standardised.

I would like to be able to make statements such as:

TemporalQuantities are quantities: "properties of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference"

They can be used to size a number line.
They cannot support conversion. To re-interpret a temporal quantity, a calendar calculation is required.

[marqh]

To pick up on the examples in https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-348337417

In each case, the quantity being measured is related in a complicated way to other quantities.

For referencing by coordinates standardisation, I think it is helpful to mandate that temporal quantities may not be converted to other temporal quantities via coordinate conversion.

For each of these examples we can propose unit conversions which are ambiguous, due to calendrical

Unix time - unit-of-measure is seconds since 00:00:00.000 UTC on 1st Jan 1970

3692217600 seconds since 1970-01-01T00:00:00Z in years

Julian day - unit of measure is days since 1st Jan 4713 BCE

2298039 days since 1st Jan 4713 BCE in years

Geochronologic time - unit of measure is years before 1950

2000 years before 1950 in seconds

I think that

A calendar month can be just an ordinary UnitOfMeasure with conversion factors left to null.

is not strong enough

in my view a calendar month must always be unable to be converted, as part of the standard, not left to 'may', as all to often this will be ignored (based on long and varied experience)

[desruisseaux]

The concern about preventing an implementation to interpret months as 365.24/12 24 60 * 60 seconds in call cases is of course fully legitimate, but I think it can be addressed by existing ISO 19103 standard in two ways:

Conversion to ISO null by CRS definition

The first way come from the fact that UnitOfMeasurement is part of the CRS definition. It is not an object that users of a referencing library instantiate themselves. For example a calendar month could be declared in the "Unit of Measure" table of EPSG geodetic database as a row with factor_b and factor_c columns left to null. Likewise, the TIMEUNIT element in WKT definition could have no factor (if we modify WKT specification for allowing that). A referencing library creating TemporalCRS instances from those definitions will give to the users UnitOfMeasurement instances where the "conversion to ISO" attributes are null. It is not the user who decided to set those attributes to null. Consequently the users will not be able to perform unit conversions, at least not through the ISO 19103 API (unless he parses the uomSymbol attribute himself).

Convertible units differentiated by their type

The second way come from class types. Taking the international vocabulary of metrology definitions:

quantity: property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference

The temporal quantity in SI would be time. ISO 19103 defines a Time type as a subtype of Measure. Java standard API for Unit of Measurement (JSR-363) defines a Time interface as a subtype of Quantity.

kind of quantity: aspect common to mutually comparable quantities

In object-oriented model, I interpret that as the type used for representing the quantity:

• a Time instance is a temporal quantity
• the Time class or interface is the kind of quantity

measurement unit: real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the two quantities as a number

A key part of the sentence is other quantity of the same kind. It is has if all UnitOfMeasurement instances had a hidden "kind of quantity" attribute, and conversions are allowed only between to UnitOfMeasurement instances having the same "kind of quantity" attribute value. Actually this information is present in the model, but not as an attribute. In JSR-363, it is represented as a parametrized type:

• Unit<Angle>: may be degrees, radians, etc
• Unit<Time>: may be SI seconds, minutes, etc
• Unit<AmountOfSubstance>: may be moles, micromoles, etc
• Unit<AmountOfMonth>: does not exist in JSR-363 standard, but users are free to define their own AmountOfMonth subtype of Quantity.

In JSR-363, any attempt to convert from Unit<AmountOfMonth> to Unit<Time> results in compiler error. Such errors are detected very early, before execution.

The UML used by ISO standards does not support parametrized types as far as I know. ISO 19103 achieves a similar goal with sub-typing. This is a little bit less safe than parametrized type in this particular case, but nevertheless capture the intend. In ISO 19103 each Measure sub-type has a corresponding UnitOfMeasure sub-type of the same name with the Uom prefix. Examples: Length and UomLength, Time and UomTime, etc.

So the CoordinateSystemAxis.axisUnit attribute, which is of type UnitOfMeasure, should be understood as having the value of one of UnitOfMeasure subtypes: UomAngle, UomLength, UomTime, etc. The rule is that we can convert only between unit of the same type. We can convert from one UomLength to another UomLength, but not from UomLength to UomAngle.

If having "conversion to ISO" attributes left to null is not sufficient, I think that nothing prevent the user to define his own UomAmountOfMonth subtype. Then, by the rule in above paragraph, this unit is not convertible to any UomTime unit.

All of the above is done with ISO 19103 as it stands today, without the need for any additional material in ISO 19111. If this approach is acceptable, then the main action needed for this issue may be to write a good documentation in ISO 19111.

[RogerLott]

Would using axisUnit.UnitOfMeasure for TemporalCS be acceptable if all three bullets below were implemented: i) the 19111 document stated "Axis unit (in the context of a time axis, preferably referred to as axis quantity) uses the datatype of UnitOfMeasure. This is defined in ISO 19103. The class includes a note "conversion ToISOstandardUnit is not null only if the conversion is a simple scale". This requires that a unit shall have a conversion to an SI unit of the same type unless this cannot be represented as a scalar. Temporal measure quantities do not satisfy this criteria and no conversion to the SI base unit of second is required." In this the AxisUnit class would be excluded, UnitOfMeasure returning to the CoordinateSystemAxis class. ii) The current PseudoUnit/TemporalAxisQuantity were excluded from the UML model but made a table in normative clause 10.3 or 10.4. iii) CoordinateDataType codelist remains, with three attributes (dateTime, integer, real).

[desruisseaux]

This is fine for me, but I suggest to nuance the "Temporal measure quantities do not satisfy this criteria" sentence. Some temporal units/quantities do not satisfy this requirement and others do. Likewise, I suggest to omit the "(in the context of a time axis, preferably referred to as axis quantity)" note. I think it is appropriate to use "temporal unit" words for units having a simple relationship with SI like seconds, minutes, or even years when defined in the way EPSG:1029 does. Instead, maybe we should remind that year (as well as month, day and others) may be defined in different ways, and when they are defined relative to a calendar, the relationship with SI is no longer simple and "axis quantity" become preferred to "axis unit".

[marqh]

My concern regarding the use of axisUnit.UnitOfMeasure remains the lack of a mandate against conversion for temporal cases. I appreciate that an individual UnitOfMeasure instance may have no: 'nameStandardUnit', 'scaleToStandardUnit', 'offsetToStandardUnit' and 'formula', all of these may be null. I assume that where these are null, all of the operations: 'convert...' would not succeed.
This behaviour is at an instance level, one TemporalCRS may have a unit like this with no conversion defined, the next may have a unit that supports conversion. I think this inconsistency is concerning.

My preference has always been to identify these temporal unit like quantities, as things very much like units, whilst mandating that there is no conversion possible. I do not see a way to model this neatly whilst using the 19103 UnitOfMeasure; it has been suggested in other cases that specialising a class then applying restrictions to its attributes in the subClass is not a preferred modelling route. (suggestions on this are very welcome, of course) The TemporalQuantity proposed by me is in essence a generalisation of UnitOfMeasure where all of the above attributes and operations do not exist.

I have not fully appreciated the desire to preserve the 19103 UnitOfMeasure class for temporal quantities or the benefits this brings. This ticket proposal attempts to address the concern about introducing indirection for units non-temporal cases and lessen the impact to other cases.

Would using axisUnit.UnitOfMeasure for TemporalCS be acceptable if all three bullets below were implemented:

This feels like a solution that lacks significant benefit for temporal cases compared to the one proposed by me in this ticket and the one currently in the draft.

This sentence:

This requires that a unit shall have a conversion to an SI unit of the same type unless this cannot be represented as a scalar. Temporal measure quantities do not satisfy this criteria and no conversion to the SI base unit of second is required." goes part way to addressing the challenge, but by stating that 'no conversion ... is required' the statement is an optional omission, not a mandate that no conversion shall take place. The loss of this mandate is a significant loss to me.

There is also an implication in this sentence that if a conversion to SI can be represented as a scalar, then the unit of measure shall include that conversion. This raises concerns, that in a simplified calendar, temporal units that can be defined with respect to an SI unit must be. This is a challenge for implementation, requiring an explicit choice in each case, and some cases there is not a clear answer to this, in my view.

I want to read an explicit statement in 19111, in text and in UML, that all temporal quantities are related to a calendar and that reinterpretation shall always involve that calendar, and shall not use UnitOfMeasure conversion, which is often impossible to implement and only able to be done using subtle special cases. (Note, in the ISO Grogorian Calendar, no such special cases exist, all reinterpretation or calculation must involve the calendar.)

I think this clarity will be important for future standards implementing 19111. Otherwise, different implementations may easily make inconsistent decisions regarding encoding, with some offering no option for a TimeUnit to be converted, and others leaving this to the definer of the particular TemporalCRS instance. For example, should 19162 TIMEUNIT include scale, offset, formula as optional attributes or should it remove them?

On a detail point; extending the use of UnitOfMeasure subtype to enable month and day to have different subtypes seems intricate and difficult to use to me; I think it would have to be used by the people defining individual TCRS instances.

Also, on a detail point

CoordinateDataType codelist remains, with three attributes (dateTime, integer, real). I do not think there is a valid 'UnitOfMeasure' value for a CoordinateAxis of CoordinateDataType dateTime.

In this case, how would a CoordinateAxis for dateTime string values to be defined with respect to state its mandatory UnitOfMeasure?

Would using axisUnit.UnitOfMeasure for TemporalCS be acceptable if all three bullets below were implemented:

I find it hard to agree to this, I am not sure that it is 'acceptable'. Perhaps there is a path here that may represent compromise, but it comes at significant cost for temporal cases, in my view. I am not content to 'accept' it right now.

I feel that the choice under discussion might be characterised by: a. 19111 mandates that temporal quantities shall not be converted to other temporal quantities via unit conversion b. 19111 enables individual temporal quantities to be defined such that they may be converted to other temporal quantities via unit conversion or such that they may not be converted to other temporal quantities, on a case by case basis, dependent on other caveats. Is this a fair characterisation?

[desruisseaux]

I think the following is an important point to discuss:

I want to read an explicit statement in 19111, in text and in UML, that all temporal quantities are related to a calendar and that reinterpretation shall always involve that calendar, and shall not use UnitOfMeasure conversion, which is often impossible to implement and only able to be done using subtle special cases.

To me, calendars are used only for dates. My argument is that temporal coordinate values are not dates; they are durations. They measure the amount of time elapsed since the axis origin (the temporal datum), regardless any calendar consideration. The conversion from a coordinate value to a date may be a complicated thing involving calendar, but I think it is a separated issue. I think that if such conversion rules are specified, they should be outside CoordinateSystemAxis (e.g. maybe they can be implied by the Calendar associated to the TemporalDatum).

If we accept that temporal coordinates are durations since axis origin, then I think that those values are convertible to SI in the majority of cases. They are typically seconds since January 1st 1970 (on Unix system), or milliseconds since January 1st 1970 (Java), or fixed-length days since January 1st 4712 BC (Julian days), etc. In both NetCDF files (used in oceanography) and GRIB2 files (defined by the World Meteorological Organization), time is expressed as a duration in a standard SI units since the reference time. Only the reference time needs a calendar. Once the reference time is defined (outside the CoordinateSystem), coordinate values do not involve calendar anymore.

I realize that sometime, a user really wants to have a time axis counting calendar quantities. But I think that it happen less often than time axis measuring duration in SI units. At least netCDF CF-conventions and GRIB2 files are structurally designed with time axis as a duration in SI units since a reference date.

I agree that having nameStandardUnit, scaleToStandardUnit, offsetToStandardUnit, etc. set to null may not be strong enough for saying that a unit is not convertible to SI temporal units. A more reliable way is the requirement that conversions are allowed only between quantities of the same kind. In JSR-363, this requirement is modelized quite cleanly with parametrized types. In ISO 19103, having no parametrized types in UML, the authors used sub-typing instead. I agree that this use of sub-typing is not ideal, but I think that the important thing is to communicate the intend — which is to distinguish the different kinds of quantities — and an ISO 19103 implementation may use a more appropriate way when allowed by its target language.

I feel that the choice under discussion might be characterised by: a. 19111 mandates that temporal quantities shall not be converted to other temporal quantities via unit conversion

I don't think it is the case. As explained above, I think that temporal coordinate values are SI temporal quantities in the majority of cases.

b. 19111 enables individual temporal quantities to be defined such that they may be converted to other temporal quantities via unit conversion or such that they may not be converted to other temporal quantities, on a case by case basis, dependent on other caveats. Is this a fair characterisation?

Yes, I think that (b) is closer to how I see it. But I think that non-convertible temporal quantities on a coordinate system axis are less frequent than the use of temporal SI units.

Do we agree of the view of temporal coordinates not as dates, but rather as durations since a reference date?

[RogerLott]

The current draft of 19111 in 10.3 says: "This document supports three forms of temporal coordinate system: — dateTime strings in the proleptic Gregorian calendar as described in ISO 8601. — a temporal coordinate system using integer count which can be converted to dateTime in the ISO 8601 proleptic Gregorian calendar. — a temporal coordinate system that has a continuous axis expressed as a real number. The origin of the axis may be described with respect to the ISO 8601 proleptic Gregorian calendar but in this document conversions to dateTime in the ISO 8601 proleptic Gregorian calendar are not supported. This is because conversions between temporal quantities are not standardised and context specific calculations are generally required."

This suggests to me that (assuming datum information is present) 1000 hours can be converted to an 8601 string but that conversion of 1000.0 calendar hours is not supported.

If this categorisation is what we want, then it seems to me that we requires some stronger and clearer justification and explanation of the distinction between (ii) and (iii). At one stage in the modelling we used 'temporal count' and 'temporal measure' (respectively) for these: temporal count may be converted to 8601, temporal measure cannot.

A problem I am having with the discussion in previous posts above is that we seem to be focussing on one case - whether or not temporal units/quantities can be converted to 8601 - when (in addition to an 8601 date/Time string) we initially set out to cover two cases, count=integer and measure=real. Marqh has argued that temporal quantities cannot be converted: I do not understand how that maps to the temporal count case (ii).

Marqh said "I feel that the choice under discussion might be characterised by: a. 19111 mandates that temporal quantities shall not be converted to other temporal quantities via unit conversion b. 19111 enables individual temporal quantities to be defined such that they may be converted to other temporal quantities via unit conversion or such that they may not be converted to other temporal quantities, on a case by case basis, dependent on other caveats."

Now there may be some unwritten subtleties in the term 'unit conversion', but if I ignore 'unit' and focus on 'conversion' then (a) does not map to option (ii) of the two documented options (ii) and (iii), so if we have this binary a/b choice then we are left with (b).

Rather than focussing on data type (integer v real), should we not be describing two cases of temporal quantity, those that can v cannot be converted to 8601? Or is (ii) in the 19111 description wrong - it also does not support conversion to dateTime and differs from (ii) by being integer rather than real? In which case, why not reduce these two cases to one and use the data type of number?

[desruisseaux]

I think that the datatype is independent of whether a temporal quantity can be converted to 8601 or not. My comments on the three forms:

dateTime strings in the proleptic Gregorian calendar as described in ISO 8601.

I would prefer to omit the word "strings" in above definition, since I see "dateTime" and a "dateTime string" as 2 different things. To me, a dateTime is a (year, month, day, hour, minute, second) tuple (with more or less fields) stored in whatever internal representation the implementation wishes, while "dateTime string" is the human-readable representation of dateTime in ISO 8601 format.

a temporal coordinate system using integer count which can be converted to dateTime in the ISO 8601 proleptic Gregorian calendar.

I'm not sure what we mean here. Given that this definition does not mention the existence of an origin, how can we convert a single number to a (year, month, day) tuple? For example a coordinate value of "6 months" is the sixth month of which year?

a temporal coordinate system that has a continuous axis expressed as a real number. The origin of the axis may be described with respect to the ISO 8601 proleptic Gregorian calendar but in this document conversions to dateTime in the ISO 8601 proleptic Gregorian calendar are not supported. This is because conversions between temporal quantities are not standardised and context specific calculations are generally required.

The first part of this definition looks fine to me: "a temporal coordinate system that has a continuous axis expressed as a real number. The origin of the axis may be described with respect to the ISO 8601 proleptic Gregorian calendar". But I don't think that the reminding is accurate for three reasons:

• It is often possible to convert to ISO 8601 dates. The formula is more complicated than a scale factor, but nevertheless exists. Leap seconds are a complication, but different conventions in Unix, Java, etc. exist for handling them. For this discussion, I will assume that the value of TemporalDatum.calendar attribute implies a specific convention regarding leap seconds and other calendar complications.
• The only context needed is the TemporalDatum. If datum's calendar is known to the implementation (e.g. it specifies the proleptic Gregorian calendar with a specific way to handle leap seconds), then the datum's temporal origin and the axis units of measurement are everything we need for converting any coordinate value to a dateTime.
• Even if my two above points are wrong, I think that the axis units of measurement is independent of whether temporal coordinate values can be converted to dateTime or not. If a coordinate value means "10 hours after the origin", I can convert that to "600 minutes after the origin" without knowing which date it is. This of course assumes that the conversion is a scalar adopted for duration measurements (like EPSG:1029 definition of year). This is not necessarily the same than the number of seconds separating two fields in a dateTime.

[marqh]

regarding: https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-349077601 (with apologies for epic posting length)

Marqh has argued that temporal quantities cannot be converted: I do not understand how that maps to the temporal count case (ii).

Elements of this are not clear enough, I agree. This interpretation must map effectively if it is to be useful.

I think that a reason I have become confused is the change that dateTime is a temporalQuantity, rather than a CoordinateDataType.

Transpose the cardinality of these two attributes - make temporalQuantity mandatory (analogous to axisUnitID for other CS subtypes) and because of this make coordinateType optional. Move the dateTime attribute from CoordinateDataType to TemporalQuantity. In conjunction with the above this eliminates the current duplication of dateTime for an 8601 string.

Once datetime is a temporalQuantity then it is clear that we want to standardise conversion from one temporalQuantity as an offset from a datetime to another datetime.

The fact that lots of temporalQuantity to temporalQuantity conversion do not make sense without a calendar is not conclusive. There are lots of things I would choose not to support in my software, and I would like to see provision that these are not mandated that they are expected to work.

Temporal quantities can be converted, in some circumstances. My argument was flawed.

I also think it may be useful to use language about what information and behaviour are standardised, rather than what can be implemented, which is a much larger set. Some potential amendments to language in 19111 : 10.3

— dateTime strings in the proleptic Gregorian calendar as described in ISO 8601. — a temporal coordinate system using integer count which can be unambiguously converted to a dateTime in the ISO 8601 proleptic Gregorian calendar as an offset from the datum time origin, another ISO 8601 string. — a temporal coordinate system that has a continuous axis expressed as a real number , which can only be ambiguously converted to a dateTime in the ISO 8601 proleptic Gregorian calendar as an offset from the datum time origin, another ISO 8601 string. Results may differ based on implementation. The origin of the axis may be described with respect to the ISO 8601 proleptic Gregorian calendar but in this document conversions to dateTime in the ISO 8601 proleptic Gregorian calendar are not supported. This is because conversions between temporal quantities are not standardised and context specific calculations are generally required.

I'll try to work by example a little and establish some behavoir.

This suggests to me that (assuming datum information is present) 1000 hours can be converted to an 8601 string

Yes, standardised. The datum includes an 8601 string, and integer arithmetic is standardised within individual elements of the datum 8601 string.

but that conversion of 1000.0 calendar hours is not supported.

No, although I could choose to state 'not standardised' instead of not supported (if that is a helpful distinction, I am not sure). floating point arithmetic is not standardised within individual 'hour' elements of the datum 8601 string, as this is a calendarHour.

Further examples

(1000 seconds, 1000.0 seconds) since datum

Both of these may reinterpreted as an 8601 string as floating point arithmetic and integer arithmetic are standardised.

2012 calendarYear since datum

This may be reinterpreted as an 8601 string, as integer arithmetic is standardised.

2012.27548 calendarYear since datum

This may not be reinterpreted as an unambiguous 8601 string, as floating point arithmetic is not standardised within individual 'calendarYear' elements of the datum 8601 string. Results may differ.

Rather than focussing on data type (integer v real), should we not be describing two cases of temporal quantity, those that can v cannot be converted to 8601?

This seems useful yes. These are our two key cases. Everything is defined as an offset from a datum, an 8601 string. Some cases can return a standard result as an 8601 string as a result: you I and everybody else can agree on the answer. Other cases can return an an 8601 string as a result, but there is guesswork on how leap seconds, month length changes and so on contribute to the calculation of integer and remainder through the element calculation. The result is open to interpretation and implementations may reasonably differ.

standardised 8601 string result

	integer	real
second (SI)	yes	yes
calendarMinute	yes	no
calendarHour	yes	no
calendarDay	yes	no
calendarMonth	yes	no
calendarYear	yes	no
dateTime (yes)	N/A	N/A

This is a different and more important use case than the use case where an offset using one temporalQuantity is requested as another offset from the same origin as a different temporalQuantity (I do not have a requirement for the latter).

I think it is important that any definition of a temporalQuantity may be defined independently, without any nameStandardUnit, scale, offset etc.

I do not have a use case to support defining any temporalQuantity except seconds as a unitOfMeasure related to SI.

I do not think that 19103 UnitOfMeasure provides the mechanism to relate calendarHour to calendarMinute as neither are a 'standardUnit'.

I would not define a TCRS TCS with an axisUnit of hour defined with respect to seconds. If I received one of these, I would not know whether to ignore this definition and include a leap second or take the definition at face value and ignore potential leap seconds. Hence I thought to gain a statement from 19111 that these would not appear and all numerical relations would be calculated via the datum, which is always a datetime and the calendar relations.

For these reasons I find the model in https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-347984611 compelling.

returning to @RogerLott: https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-348577833

1. the 19111 document stated "Axis unit (in the context of a time axis, preferably referred to as axis quantity) uses the datatype of UnitOfMeasure. This is defined in ISO 19103. The class includes a note "conversion ToISOstandardUnit is not null only if the conversion is a simple scale". This requires that a unit shall have a conversion to an SI unit of the same type unless this cannot be represented as a scalar. Temporal measure quantities do not satisfy this criteria and no conversion to the SI base unit of second is required." In this the AxisUnit class would be excluded, UnitOfMeasure returning to the CoordinateSystemAxis class.

This is helpful. The language provides scope for the conversion and base not to be included.

Perhaps 'This requires that a unit shall have a conversion to an SI unit of the same type unless this cannot be represented as a scalar.' is still too strong. Is it too lax to simply allow ToISOstandardUnit to be null when it does not apply?

This note does not provide advice on what to do if a conversion is provided. Does this get used in preference to conducting calendar arithmetic with the quoted quantity, or shall implementations use calendar calculations even if the result could differ from a calculation? Or, should the standard state that in these cases the result is open to interpretation and that implementations may differ?

2 The current PseudoUnit/TemporalAxisQuantity were excluded from the UML model but made a table in normative clause 10.3 or 10.4.

This would be useful.

3 CoordinateDataType codelist remains, with three attributes (dateTime, integer, real).

This would be required, as dateTime may not be a unitOfMeasure

I find this latter solution less suitable for my uses, and my understanding, but I think that it can be made to be functional, as you have described. I will not further block progress on this issue if mine is the only voice of support for the temporalQuantity element, even though I prefer it. Some language to describe recommendations and supply information to implementers about key behaviour to provide and what may be left as ambiguous would be helpful.

[marqh]

One further detail on:

3 CoordinateDataType codelist remains, with three attributes (dateTime, integer, real).

This would be required, as dateTime may not be a unitOfMeasure

As I mentioned previously, there is no valid UnitOfMeasure for a dataType of dataTime.
Is it reasonable to relax the mandate on there being an axisUnit (UnitOfMeasure), such that in the dataType=dateTime case, axisUnit is null?

[desruisseaux]

I think the new language for 19111 §10.3 is an improvement. But would the following amendments be acceptable?

dateTime strings in the proleptic Gregorian calendar as described in ISO 8601.

dateTime is a type of its own, distinct from its CharacterSequence representation. It can make a difference when ordering values: 2017-01-01T00:00Z may be interpreted as a date-time before 2017-01-01T00:00:12Z. But when comparing their string representations, we get the opposite order because "Z" is after ":" in ASCII table.

On the next two items — "a temporal coordinate system using integer count which can be unambiguously converted to a dateTime" and "a temporal coordinate system that has a continuous axis expressed as a real number , which can only be ambiguously converted to a dateTime" — it seems to me that the fact of using integers or real numbers is independent of the fact that a conversion is ambiguous or not. We may be counting seconds since January 1st 1970, in which case we are subject to the same ambiguity regarding leap seconds than if we were using real numbers. Or maybe you intended to restrict the integer case to days or longer units? If yes, then what about the following?

a temporal coordinate system using integer count of days or longer temporal units, which can be unambiguously converted to a dateTime in the ISO 8601 proleptic Gregorian calendar as an offset from the datum time origin, another dateTime ISO 8601 string.

I omitted "ISO 8601" because in my understanding, that standard does not define the Gregorian calendar; it only defines a characters representation, which does not need to be applied to coordinate values here. The standard summary said: "ISO 8601:2004 does not assign any particular meaning or interpretation to any data element that uses representations in accordance with ISO 8601:2004. Such meaning will be determined by the context of the application."

a temporal coordinate system that has a continuous axis expressed as real numbers, which can only may be ambiguously converted to a dateTime in the ISO 8601 proleptic Gregorian calendar as an offset from the datum time origin, another dateTime ISO 8601 string. Results may differ based on implementation.

I replaced "can only" by "may" because some languages define precisely their rules for converting such numbers to dates, including their behavior regarding leap seconds. One example is the UTC with Smoothed Leap Seconds (UTC-SLS) approach, adopted by the Java language since 2014.

I think it is important that any definition of a temporalQuantity may be defined independently, without any nameStandardUnit, scale, offset etc.

I wonder which data we are talking about? I do not remember having seen calendar quantity in time series except for climatology data (e.g. average January temperature of no particular year). Could you provide us an example of time series using calendar quantities?

I do not have a use case to support defining any temporalQuantity except seconds as a unitOfMeasure related to SI.

Isn't the opposite situation, many time series using elapsed time in minutes, hours, days or other temporal units since an epoch? For example in netCDF files, the units attribute of time axis is something like "hours since 1980-01-01T00:00Z". In WMO GRIB2 files, a single reference time is given as a (year, month, day, etc.) tuple for the whole file, then from that point the time of every data slice is given using a single temporal units since that reference time. In above paragraph, does "use case" means something else than supporting netCDF, GRIB2 and other file formats?

I would not define a TCRS TCS with an axisUnit of hour defined with respect to seconds. If I received one of these, I would not know whether to ignore this definition and include a leap second or take the definition at face value and ignore potential leap seconds.

But then, how are we supposed to read netCDF, GRIB2 and other files? I think that the common practice is to ignore leap seconds for three reasons:

• The time series are usually not long enough for leap seconds to become significant. After some period (e.g. one year) we reach end of file. A new netCDF or GRIB file is then created for the next year, with a new reference date in ISO 8601 format.
• If we nevertheless have very long time series, the UTC with Smoothed Leap Seconds approach is one way to handle the problem at the cost of a maximal inaccuracy of one second compared to UTC clock.
• It seems to me that using calendars would make very difficult to perform time series analysis like spectral analysis. The Fast Fourier Transform (FFT) algorithm that I have learn needs a constant step between each sample value.

In summary, I think that the core point where we have different views is about whether calendar arithmetic on time axis should be common or rare. I think they may be common in other contexts, but rare on the time axis. If this is the case, should we try to list some use cases?

[pebau]

Hi all,

again my 2 cents from someone deailing with space/time coordinates all the time ;-) in practice.

On 12/06/2017 12:58 AM, Martin Desruisseaux wrote:

I think the new language for 19111 §10.3 is an improvement. But would the following amendments be acceptable?

|dateTime| strings in the proleptic Gregorian calendar as described in ISO
8601.

|dateTime| is a type of its own, distinct from its |CharacterSequence| representation. It can make a difference when ordering values: 2017-01-01T00:00Z may be interpreted as a date-time before 2017-01-01T00:00:12Z. But when comparing their string representations, we get the opposite order because "Z" is after ":" in ASCII table.

absolutely supported - "string" is not the adequate type, 8601 syntax follows own rules.

On the next two items — /"a temporal coordinate system using integer count which can be unambiguously converted to a |dateTime|"/ and /"a temporal coordinate system that has a continuous axis expressed as a real number , which can only be ambiguously converted to a |dateTime|"/ — it seems to me that the fact of using integers or real numbers is independent of the fact that a conversion is ambiguous or not. We may be counting seconds since January 1st 1970, in which case we are subject to the same ambiguity regarding leap seconds than if we were using real numbers. Or maybe you intended to restrict the integer case to days or longer units? If yes, then what about the following?

a temporal coordinate system using integer count of days or longer
temporal units, which can be unambiguously converted to a |dateTime| in
the ISO 8601 proleptic Gregorian calendar as an offset from the datum time
origin, another |dateTime| ISO 8601 string.

I continue to be bewildered by having int and real distinction for the same thing - it will be very hard to motivate to the communities to have such a counterintuitive, overcomplicating definition.

I omitted "ISO 8601" because in my understanding, that standard does not define the Gregorian calendar; it only defines a characters representation, which does not need to be applied to coordinate values here. The standard summary https://www.iso.org/standard/40874.html said: /"ISO 8601:2004 does not assign any particular meaning or interpretation to any data element that uses representations in accordance with ISO 8601:2004. Such meaning will be determined by the context of the application."/

this is in line with one of the outcomes of the OGC Temporal.DWG: 8601 defines syntax, but not semantics. Calendars have not been addressed yet, therefore everybody silently assumes it is Gregorian-Proleptic. This will change in future.

a temporal coordinate system that has a continuous axis expressed as real
numbers, which can only may be ambiguously converted to a dateTime in the
ISO 8601 proleptic Gregorian calendar as an offset from the datum time
origin, another |dateTime| ISO 8601 string. Results may differ based on
implementation.

I replaced "can only" by "may" because some languages define precisely their rules for converting such numbers to dates, including their behavior regarding leap seconds. One example is the UTC with Smoothed Leap Seconds (UTC-SLS) http://www.cl.cam.ac.uk/%7Emgk25/time/utc-sls/ approach, adopted by the Java language since 2014.

I think it is important that any definition of a temporalQuantity may be
defined independently, without any nameStandardUnit, scale, offset etc.

I wonder which data we are talking about? I do not remember having seen calendar quantity in time series except for climatology data (e.g. average January temperature of no particular year). Could you provide us an example of time series using calendar quantities?

I do not have a use case to support defining any temporalQuantity except
seconds as a unitOfMeasure related to SI.

Isn't the opposite situation, many time series using elapsed time in minutes, hours, days or other temporal units since an epoch? For example in netCDF files, the |units| attribute of time axis is something like "hours since 1980-01-01T00:00Z". In WMO GRIB2 files, a single reference time is given as a (year, month, day, /etc./) tuple for the whole file, then from that point the time of every data slice is given using a single temporal units since that reference time. In above paragraph, does "use case" means something else than supporting netCDF, GRIB2 and other file formats?

I would not define a TCRS TCS with an axisUnit of hour defined with
respect to seconds. If I received one of these, I would not know whether
to ignore this definition and include a leap second or take the definition
at face value and ignore potential leap seconds.

But then, how are we supposed to read netCDF, GRIB2 and other files? I think that the common practice is to ignore leap seconds for three reasons:

• The time series are usually not long enough for leap seconds to become significant. After some period (e.g. one year) we reach end of file. A new netCDF or GRIB file is then created for the next year, with a new reference date in ISO 8601 format.
• If we nevertheless have very long time series, the /UTC with Smoothed Leap Seconds/ approach is one way to handle the problem at the cost of a maximal inaccuracy of one second compared to UTC clock.
• It seems to me that using calendars would make very difficult to perform time series analysis like spectral analysis. The Fast Fourier Transform (FFT) algorithm that I have learn needs a constant step between each sample value.

In summary, I think that the core point where we have different views is about whether calendar arithmetic on time axis should be common or rare. I think they may be common in other contexts, but rare on the time axis. If this is the case, should we try to list some use cases?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-349482407, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejv0TMBp5KPMc0bx0tlCiEwW__QcYks5s9diwgaJpZM4QvJHA.

19111 is in danger of becoming a weird definition as far as time is concerned, driven by traditional horizontal Earth surface concepts which do not transpose into this new dimension. We need to accept that time has its own behavior that transcends floats (such as non-trivial parsing and date arithmetics). Martin has made excellent points here, and I do hope that he will get heard, for the sake of us users out there.

-Peter

-- Dr. Peter Baumann

• Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
• Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."

[marqh]

In response to https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-349482407

I think the new language for 19111 §10.3 is an improvement. But would the following amendments be acceptable?

dateTime ~~strings~~ in the proleptic Gregorian calendar as described in ISO 8601.

dateTime is a type of its own, distinct from its CharacterSequence representation. It can make a difference when ordering values: 2017-01-01T00:00Z may be interpreted as a date-time before 2017-01-01T00:00:12Z. But when comparing their string representations, we get the opposite order because "Z" is after ":" in ASCII table.

This seems fine to me.

a temporal coordinate system using integer count of days or longer temporal units, which can be unambiguously converted to a dateTime in the ISO 8601 proleptic Gregorian calendar as an offset from the datum time origin, another dateTime ISO 8601 string.

I omitted "ISO 8601" because in my understanding, that standard does not define the Gregorian calendar; it only defines a characters representation,

This makes sense, I agree.

a temporal coordinate system that has a continuous axis expressed as real numbers, which can only may be ambiguously converted to a dateTime in the ISO 8601 proleptic Gregorian calendar as an offset from the datum time origin, another dateTime ISO 8601 string. Results may differ based on implementation.

This is also a sensible change, I agree

[marqh]

There is lots of confusion regarding my statements in https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-349482407. My apologies, clearly my statements were not at all clear. I add examples in each case to try to illustrate my intent; each statement was intended with a very limited scope.

think it is important that any definition of a temporalQuantity may be defined independently, without any nameStandardUnit, scale, offset etc.

• A year (or calendarYear) may be defined without any reference to second.
• An hour (or calendarHour) may be defined without any reference to second.
• A day (or calendarDay) may be defined without any reference to second.

I do not have a use case to support defining any temporalQuantity except seconds as a unitOfMeasure related to SI.

• second[baseUnit=second, scaleFactor=1.0]
  • would be fine to use for me
• day[baseUnit=second, scaleFactor=86400.0]
  • I don't have a reason to ever use this

just because I don't have a use case, doesn't mean it shouldn't be allowed. Perhaps it is helpful for someone, perhaps it is legacy use.

I would not define a TCRS TCS with an axisUnit of hour defined with respect to seconds. If I received one of these, I would not know whether to ignore this definition and include a leap second or take the definition at face value and ignore potential leap seconds.

• 365 days[nameStandardUnit=second, scaleToStandardUnit=86400.0], datum.origin=2016-01-01T00:00:00.0

  • the answer to this is open to interpretation

• 24 hours[nameStandardUnit=second, scaleToStandardUnit=86400.0], datum.origin=2016-12-31T00:00:0.0

  • the answer to this is open to interpretation

• however integer arithmetic makes this case easy to agree upon:

  • 25 months, datum.origin=2012-01 as a dateTime
  • 2014-02

[desruisseaux]

day[baseUnit=second, scaleFactor=86400.0] I don't have a reason to ever use this

This is where I'm puzzled. For me, quite the opposite this is used a lot. In netCDF and GRIB files among others but not only. This is not legacy; at the contrarily this is rather the norm. This is also used for Julian days, this is how spreadsheets like Excel handle date-times (days since December 30th, 1899), etc.

24 hours[nameStandardUnit=second, scaleToStandardUnit=86400.0], datum.origin=2016-12-31T00:00:0.0 the answer to this is open to interpretation

I presume the different interpretations depend on whether a leap second is added or not. But does the ambiguity really exists in practice? The 2001 edition of POSIX.1 standard uses a time scale as if all days where exactly 86400 seconds long, and defines the adjustment to apply during leap seconds for preserving this characteristic. Another way to preserve this characteristic is the UTC with Smoothed Leap Seconds approach that I mentioned above, also mentioned on the IETF leap seconds list page:

Some systems implement leap seconds by amortizing the leap second over the last few minutes of the day. The frequency of the local clock is decreased (or increased) to realize the positive (or negative) leap second. This method removes the time step described above. Although the long-term behavior of the time scale is correct in this case, this method introduces an error during the adjustment period both in time and in frequency with respect to the official definition of UTC.

The maximal error during the adjustment period is one second.

So in summary, it seems to me that common practice is to perform calculations as if all days where exactly 86400 seconds long, with different strategies for handling leap seconds. Those different strategies differ by at most 1 second in the few last minutes of years having a leap second. If we accept that as an established practice, would it solve the perceived ambiguity of SI temporal units?

[marqh]

Following discussions within the standards working group meeting today, the committee have agreed to adopt the model with explicit classes for the different temporal cases and the use of UnitOfMeasure for all cases except dateTime(removing TemporalQuantity)

It is recognised that a UnitOfMeasure instance may be defined with respect to an SI base unit, or it may be defined independent of any other unit, if required. For example, defining a UnitOfMeasure 'hours' with no reference to this being a defined number of SI seconds.

@jetgeo Please may you review this model adaption for us and feedback any thoughts you have on it. Is it suitable for inclusion as the updated https://github.com/ISO-TC211/ISO19111/blob/master/Figures/Coordinate%20Systems.png ? Is it clear what has changed, as this diagram is an abridged version of the original?

[desruisseaux]

The CoordinateSystem → CoordinateSystemAxis association would need to be changed to a CoordinateSystem → GeneralCoordinateSystemAxis association for allowing the TemporalCS → TemporalCoordinateSystemAxis association (because TemporalCoordinateSystemAxis is not a CoordinateSystemAxis subtype).

[desruisseaux]

Given that all types having a coordinateDataType attribute in above diagram allow only one value, do we still need to the CoordinateDataType code list? At least, it does not make sense to have it as a code list instead than an enumeration if there is no place where a user-defined value could be applied.

[RogerLott]

1. I do not think the coordinateDataType codelist is necessary now. But if it is removed, should not all of the +coordinateDataType attributes (four occurrences) be changed to something from 19103 - +dataType??
2. Should not the cardinality of the association from TemporalCS to TemporalCoordinateSystemAxis be 1 (so not ordered)?
3. Can we shorten the names of the three new classes: DateTimeCSaxis, TemporalCountCSaxis and TemporalMeasureCSaxis?
4. The coordinate type in TemporalCountCSaxis should be written in full - integer.

[marqh]

additionally, i think it is slightly odd to see coordinateDataType used in an OrdinalCS, but used in TemporalCoordinateSystemAxis otherwise.

I suggest making a OrdinalCSAxis with coordinateDataType=integer to maintain this in a more consistent fashion

[marqh]

I have left

I do not think the coordinateDataType codelist is necessary now. But if it is removed, should not all of the +coordinateDataType attributes (four occurrences) be changed to something from 19103 - +dataType??

as an enumeration whilst I await some 19103 feedback, i have implemented all of the other edit suggestions:

regarding

The CoordinateSystem → CoordinateSystemAxis association would need to be changed to a CoordinateSystem → GeneralCoordinateSystemAxis association for allowing the TemporalCS → TemporalCoordinateSystemAxis association (because TemporalCoordinateSystemAxis is not a CoordinateSystemAxis subtype).

this was explicit in @jetgeo 's suggested amendments: https://github.com/ISO-TC211/ISO19111/issues/36#issuecomment-347984611 I have followed @desruisseaux 's suggestion @jetgeo please may you comment on this detail?

updated diagram:

[desruisseaux]

If I remember correctly, the reason why coordinateType was defined in OrdinalCS instead than in the axis is because it applies to the coordinate system as a whole, i.e. to all axes. If we accept this argument, then the coordinateType in various temporal axis subtypes should be defined in TemporalCS instead. Even if in the particular case of one-dimensional CS the two locations are equivalent, having coordinateType in TemporalCS would be consistent with OrdinalCS.

I worry that CoordinateSystemAxis hierarchy become complex for supporting one relatively uncommon case (non-SI temporal units) at the expanse of all other cases, including both non-spatial CS and the most common (in my opinion) temporal CS case. This is because the axisUnit attribute is no longer accessible directly from the CoordinateSystem associations. It is rather dispatched in three subtypes - CoordinateSystemAxis, TemporalMeasureCSAxis and TemporalCountCSAxis - which will force users to perform many if (axis instanceof XYZ) checks. Would the following simplifications be acceptable?

• TemporalMeasureCSAxis is conceptually equivalent to CoordinateSystemAxis (it uses of real numbers associated to SI units) except for its TemporalCSAxis parent. Can we remove TemporalCSAxis? It would allow us to remove TemporalMeasureCSAxis too since it would now be fully equivalent to CoordinateSystemAxis. This way, axisUnit would be defined in a single place instead of three.
• We already have a class hierarchy with various CoordinateSystem subtypes. Maybe we should exploit more this hierarchy before to introduce a new one with axes? In particular if we accept that coordinateType should be defined in the CS class because it applies to the coordinate system as a whole, then we could define CalendarCS as a subtype of TemporalCS where coordinateTye = dateTime. This would allow us to remove DatatimeCSAxis.

[jetgeo]

Ok, so I have finally had some time again to look at this. Sorry for the delay.

• First: @desruisseaux is right - the "axis" association must go to GeneralCoordinateSystemAxis, I didn't see this when I created the first diagram. Without this connection, it can't be specialized further down.

• Secondly: I think @desruisseaux is right about the complexity too. Isn't all of the information in the TemporalCSAxis subclasses valid for the whole CS, as TemporalCS is one-dimentional? If so, I believe the information could be at the CS instead of on the axis, as it was before. As far as I can see, DatetimeCSAxis is the only class without axisUnit, is it a problem to have axisUnit mandatory for it as well?

[jetgeo]

Suggested new model, based on my comments above. Brings us almost back to where we started?

[desruisseaux]

Thanks for the new schema, it is helpful for trying to converge. I think we need to disallow axisUnit when coordinateType is dateTime, but I hope we can achieve that goal with something between this schema and Mark's proposal above. The attendance in last week OGC meeting also expressed a desire to enforce axisUnit and coordinateType constraints with type hierarchy. But if possible, I would like to achieve this goal with more CoordinateSystem hierarchy and less CoordinateSystemAxis hierarchy. Would the following be acceptable?

• CalendarCS as a subtype of TemporalCS with the following constraints:
  • coordinateType = dateTime
  • count(axis.axisUnit) = 0 (not sure if this is the way to write. I mean "the axisUnit attribute of all axis associations).
• TemporalCountCS as a TemporalCS subtype with the following constraint:
  • coordinateType = integer
  • An explanatory text saying that axisUnit may not be convertible to SI.

In order to support the CalendarCS case, we would need to apply one of the following possibilities:

1. Change axisUnit cardinality in CoordinateSystem from mandatory to conditional, where the condition is that the unit is mandatory if coordinateType is real. It would be the easiest approach.
2. Change axisUnit cardinality in CoordinateSystem from mandatory to optional. Then in all CoordinateSystem subtypes except TemporalCS, add the following constraint: count(axis.axisUnit) = 1 (needs tuning - I'm not sure how to interpret count if there is more than one axis).
3. Define a GeneralCoordinateSystemAxis parent type as suggested by Mark. The SWG has agreed on something like this in last week meeting (but I don't know if this is a firm choice). If we go with this approach, we could declare an association to GeneralCoordinateSystemAxis in CoordinateSystem, and restrict that association to CoordinateSystemAxis in all CoordinateSystem subtypes except TemporalCS.

[RogerLott]

@jetgeo's latest is effectively option 3 presented in Mark's paper discussed last Thursday (Wednesday in EU). During that meeting I thought we agreed that it effectively was the same as option 5 (above, repeated here for clarity) but there was a very slight preference for option 5 because of its detail. Option 3 was to be presented in Annex D. A potential problem with making axisUnit mandatory for all TemporalCS including dateTime is that dateTime is not a unit but is a representation of a compound unit that comprises years, months, days, hours, minutes and seconds to some resolution all contained in a single formatted string. So this definitely has to use the 19103 exception to omit unit conversion (not a simple scalar to SI seconds).

On reflection, I wonder whether we should reverse these: the simplicity of @jetgeo's latest is appealing! So use it in the harmonised model, but show expanded option 5 in Annex D and use the the expanded names in WKT ?

Mark's diagram is incorrect to show the cardinallity for ordinalCS to CSaxis to be be 1, it should be 1..*.
I agree with Martin's assertion that the reason why coordinateType was defined in OrdinalCS instead of in the axis is because it applies to the coordinate system as a whole, i.e. to all axes. However is not this achieved whether coordinateType is in CS or CSAxis?

[desruisseaux]

I also though about putting the simpler model in the main document and the detailed one in annex. I think it would also be safer because it may give more freedom to future ISO 19111 revision group to make some adjustments to the model.

About coordinateType being defined in CS or in axis, it makes no difference for a one-dimensional CS. But for a two or more dimensional CS, having coordinateType in the CoordinateSystemAxis class would allow users to put different values for different axes of the same coordinate system (unless we document a restriction somewhere).

[jetgeo]

Question: @RogerLott writes:

...incorrect to show the cardinallity for ordinalCS to CSaxis to be be 1, it should be 1..*.

This is a change from the existing model, where the multiplicity of the attribute 'coordinateType' on the class 'OrdinalCS' is 1. Does it mean that 'OrdinalCS' may have axis with different datatypes? If so, we should probably use a subclass of 'CoordinateSystemAxis' (or of 'GeneralCoordinateSystemAxis').

On @desruisseaux 's proposal with subclasses of 'TemporalCS': That would make the complexity of the model at about the same level as with subclasses of 'CoordinateSystemAxis' (or of 'GeneralCoordinateSystemAxis'). If we need to separate between different axis approaches for TemporalCS, I think we should do that in axis classes. I will try to work out a new model, going back again in the loop.

[marqh]

regarding @RogerLott's comments

is incorrect to show the cardinallity for ordinalCS to CSaxis to be be 1, it should be 1..*.

I agree, this is an editorial mistake by me

I agree with Martin's assertion that the reason why coordinateType was defined in OrdinalCS instead of in the axis is because it applies to the coordinate system as a whole, i.e. to all axes. However is not this achieved whether coordinateType is in CS or CSAxis?

Yes, this is achieved the same either way, as the coordinateDataType is set to be integer, it is not optional or open to change

regarding @jetgeo's comments

This is a change from the existing model, where the multiplicity of the attribute 'coordinateType' on the class 'OrdinalCS' is 1.

The multiplicity is wrong, it should be 1..*

Does it mean that 'OrdinalCS' may have axis with different datatypes? If so, we should probably use a subclass of 'CoordinateSystemAxis' (or of 'GeneralCoordinateSystemAxis').

No, the value of coordinateType is fixed, it may only be integer

[jetgeo]

The attribute 'OrdinalCS.coordinateType' is constained to have value 'integer'. Having 1.* in multiplicity for an attribute that is fixed to one value gives no meaning. Either, the attribute should have multiplicity 1..1, or we should use an axis subclass for 'OrdinalCS'. This would then mean that each axis for a 'OrdinalCS' gets an attribute 'coordinateType' with value 'integer'. From a modelling point of view it gives more sense to have one attribute, placed on the 'OrdinalCS' class.

[jetgeo]

Here is a new model proposal.

• I have set the multiplicity for 'axisUnit' to 0..1, but used a constraint to say that it is mandatory
• In the axis subclass 'TemporalCSAsxis', a new constraint is introduced, saying that 'axisUnit' shall not be used it the 'coordinateType' is 'dateTime'.
• 'OrdinalCS.coordinateType' is kept as an attribute, based on the comment above.
• The multiplicity for the 'axis' association from 'TemporalCS' is 1..1, as a 'TemporalCS' is one-dimentional.

[marqh]

hi @jetgeo

I understand the approach being considered here

the reason this was cautioned against in the meeting last week is that coordinateType exists on a CS in the OrdinalCS case but on a CSAxis in the TemporalCSAxis case. This inconsistency could cause problems

in your last draft, I think that coordinateType may just as easily be an attribute on TemporalCS. Would this make sense to you?

mark

[jetgeo]

Yes, that makes sense. The constraint could then also be on TemporalCS. ("oclAsType" has been removed, as this is not type, it is a value from a codelist)

[desruisseaux]

I agree with Mark proposal to put coordinateType in TemporalCS.

The various CoordinateSystemAxis subtypes proposed by Mark were intended to provide some type safety, for example by reducing the risk that a user attempts conversions to SI with an axis where such conversions make no sense. I value this goal. If we still want to achieve it, maybe we can try with CoordinateSystem subtypes? (I think it would have less impact on non-spatial CS than with CoordinateSystemAxis subtypes). If so, then should we define a CalendarCS as a TemporalCS subtype and put there the constraints currently documented in TemporalCS?

[marqh]

I think that the presentation of specialisation classes for the 3 temporal cases is valuable, as highlighted in the meeting last week.

Having 3 classes, perhaps: DateTimeCS, TemporalCountCS, TemporalMeasureCS and mandating the value of coordinateType in each case is preferable, in my view, to having the attribute value to set.

I have now properly consulted 19103:2015 and (as @RogerLott suggested) the types Integer Real and DateTime are all defined, so I think the CodeList for CoordinateDataType is not required. This is easier to manage (I think) if the specification of coordinateType is mandated by class.

Can we make use of 19103:2015 types directly (do we use a defined namespace for this?) and simply state the attribute and value, without using a constraint?

• DateTimeCS

  • coordinateType = (19103)_DateTime
  • constraint count(axis.axisUnit) = 0
  • note: how do we handle this constraint clash with CoordinateSystemAxis: count(axis.axisUnit) = 1

• TemporalCountCS

  • coordinateType = (19103)_Integer

• TemporalMeasureCS

  • coordinateType = (19103)_Real

• OrdinalCS

  • coordinateType = (19103)_Integer

[RogerLott]

I think a class called CalendarCS would be an unfortunate choice of name. We have said that calendars are out of scope of 19111. We should not confuse. If subtyping is needed, choose another name.

With axisUnit.UnitOfMeasure we need to be separating two things: (i) whether an axisUnit is required, and (ii) whether the 19103 rules for conversion to an SI are unit are applicable. The discussion above seems to focus on (i) when the real issue might be (ii). It could be argued an axisUnit is always required, even for dateTime. For dateTime that 'unit' is a compound string representation according to 8601 syntax, but it is still required. Conversion to seconds is not possible (because it involves calendars). An alternative arguement is that a compound representation is not a unit and then the model above would be appropriate.

Regarding the CoordinateSystemAxis class axisUnit cardinallity. Having this as 0..1 and then a constaint of 1 looks rather strange. Is it possible to allow the constraint on TemporalCS and have axisUnit cardinallity of 1 as before?

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.