temporal backwards compatibility for 19162

[marqh]

The aim of this ticket is to propose a comment to the 19111 editing committee raising this issue for discussion.

In order to support backwards compatibility for 19162, I would like to propose a way to interpret the use of TIMEUNIT which is consistent with the current 19111 proposal.

The text below is a way that this could be achieved. If this interpretation is deemed suitable then my view is that a change to 19111 is not required. I would like this interpretation discussed in teh editing committee, to validate or counter my view that no 19111 change is necessary.

WKT-CRS vn1.0 12-063r5 
14.4 Example of WKT describing a temporal CRS

TIMECRS[“GPS Time”,
        TDATUM[“Time origin”,
        TIMEORIGIN[1980-01-01T00:00:00.0Z]],
    CS[temporal,1],AXIS[“time”,future],TIMEUNIT[“day”,86400.0]]

Example coordinate values
[0.0, 31.0, 59.0]

Note: the use of TIMEUNIT is supported, for backwards compatibility
with ealier versions of this standard.  However, the recommendation is
to use a TEMPORALQUANTITY instead where possible, as this is explicity
defined within the 19111 model.  A TIMEUNIT is always interpreted as
semantically equivalent to a TIMEQUANTITY[measure,"second"] with the
coordinate values multiplied appropriately given the conversion factor
provided.
A TIMEUNIT is not equivalent to a TIMECOUNT.
Calendrical calculations using a TIMEUNIT are not
standardised, context specific information is generally required to
implement calendrical calculations.
If CALENDAR is not specified , it is assumed to be,
CALENDAR[prolepticGregorian].  It is recommended that CALENDAR
is always specified.

The semantically equivalent encoding for the above example using a
TIMEQUANTITY, with appropriately scaled coordinate values:

TIMECRS[“GPS Time”,
        TDATUM[“Time origin”,
        TIMEORIGIN[1980-01-01T00:00:00.0Z],CALENDAR[prolepticGregorian]],
    CS[temporal,1],AXIS[“time”,future],
        TIMEQUANTITY[measure,“second”]
        TIMEMEASURE["second"]
    ]

Example coordinate values
[0.0, 2678400.0, 5097600.0]

[RogerLott]

Agree that this could be included in the 19111 text and that no change is needed to the model in this area.

[jetgeo]

Closed, after discussion with @RogerLott.