UNIXTime with different epoch / different celestial body

[jerstlouis]

Am I correct in understanding that although the validTime is limited to UNIXTime in the Time logical model of GeoPose 1.0, this is not actually defined as time in milliseconds since 00:00 UTC Jan 1, 1970 on Earth, but as a concept of time expressed in milliseconds since the epoch specified in the Temporal Reference Frame?

With a non-Earth-based temporal reference frame, would the temporal element be capable of supporting describing objects in their local frame of reference far away from Earth, and/or moving at high velocity where relativistic effects are significant?

[3DXScape]

The SWG made the Unix time choice early in the process for 1.0, where the focus was on a simple, no choices solution for the common use cases. There are multiple complexities in time:

• specification of a temporal frame,
• temporal resolution (fixed at 1 msec),
• clock error correction,
• accounting for light travel time,
• stellar aberration,
• special and general relativistic effects.

The SWG chose to ignore/postpone all of these for a future version. That does not mean that these do not have any effect. For example, the solarpose demo service silently applies a light travel time correction to produce results correct near the earth.
A change request with a proposal for addressing one or more of these is welcome.

[jerstlouis]

@3DXScape Thank you. To clarify my question, would it be correct to say that there is no inherent limitation to what the validTime could represent, its meaning could depend on the specified temporal reference frame i.e., the value is not limited to the traditional UNIXTime when a TRS is specified?

[3DXScape]

It's probably not the answer you want, but no, in version 1.0 validTime is only defined as Unix/POSIX time in seconds, counted from the epoch 1 January 1970 UTC, and (our choice) multiplied by 1 000 to give a precision of 1 millisecond. Use of any other TRS/epoch/precision is outside the scope of GeoPose 1.0 and requires a conversion, if available. The convoluted specification of milliseconds as "seconds x 1 000" arises because Unix time is the number of seconds, without any specification of representation or precision.

The short reason for a "no" is that we give you no way to select a TRS: validTime is just an integer with a specific interpretation.

Unix time is commonly provided with precisions of 1 second, 0.001 second, 0.000 001 second, and 0.000 000 001 second. We chose 0.001 seconds, which, in retrospect, is not adequate even for some of our core use cases. For example, an object in near-earth orbit moves about 7 m during on "tick" of our seconds x 1 000 precision. Future versions of GeoPose might address

• • specification of alternate temporal reference systems
• • precision of the time coordinate
• • accuracy of the time coordinate
• • clock error correction
• • light-time offsets
• stellar aberration
• special and general relativistic effects

In my opinion, GeoPose should also continue to offer a simple, compact alternative, as in the 1.0 Basic GeoPoses, where all of the selectable properties - spatial CRS, temporal TRS, spatial and temporal precision and accuracy - are pre-defined and implicit.

[jerstlouis]

Thanks @3DXScape . My thoughts on this:

The short reason for a "no" is that we give you no way to select a TRS: validTime is just an integer with a specific interpretation.

In my opinion, GeoPose should also continue to offer a simple, compact alternative, as in the 1.0 Basic GeoPoses, where all of the selectable properties - spatial CRS, temporal TRS, spatial and temporal precision and accuracy - are pre-defined and implicit.

I agree with the compact / simple and pre-defined / implicit.

But if extensibility is planned in from the start, it allows for the more advanced capabilities to appear like a natural extension of the basic GeoPose, rather than something completely different as the Draft Standard currently stands for the Advanced Poses.

For example, a property like trs could appear in the 1.0 core conformance class, with a definition explaining that if this is defined, the validTime is to be interpreted based on that trs and/or on a future version and/or other conformance class. If it is not defined, then the implied default applies (which is perfectly fine and a good thing).

Similar thing for the other advanced geo pose capabilities: if the frameSpecification is not present, then LTP-ENU on Earth is assumed. It should be possible to re-use the basic GeoPose lat, lon, h position parameters for LTP-ENU on the Moon or Mars instead by simply adding a frameSpecification and/or crs property.

It should be possible to add time to those simple GeoPoses.

It should be possible to define inner pose transformations together with those simple GeoPoses, without having to switch to a completely different encoding. (see also #70)

This way things remain both simple and extensible.

This is huge from an implementation perspective. I don't want to write and maintain 5 different parsers / writers in our code base for each of those different encodings -- I wouldn't bother implementing any of them if the basic one + extensions doesn't suit the use cases.

[jerstlouis]

Regarding:

The convoluted specification of milliseconds as "seconds x 1 000" arises because Unix time is the number of seconds, without any specification of representation or precision.

It seems to me that the natural choice would be to allow for real numbers, allowing for arbitrary precision while sticking to the UNIX Time definition being seconds. (though I realize there can be precision issues associated with floating-point timestamps)

[3DXScape]

You have identified part of the argument for using an integer and defining the scaling (x 1 000): it gives an expectation for precision. A second factor was the the SWG started with proposals based on milliseconds. I definitely support revisiting this since milliseconds are too coarse for many applications by several orders of magnitude.

[3DXScape]

Just as I pressed the Comment button I had an idea that fits with what @jerstlouis said about using real numbers. This time precision problem is analogous to the use of "decimal" numbers with currency amounts. Internally there can be any sort of representation but the visible representation splits the value into the integral part (left of the separator character, usually ',' or '.') and the fractional part to the right with the number of digits conveying the precision. In other words, the character for looks like a real number but has both a fraction and precision information conveyed by the digits to the right of the separator.

We could do this in a backwards compatible way by adding specification that the Unix time is either a sequence of decimal digits, representing milliseconds (backwards compatible and maybe deprecated), or a sequence of digits, a separator, and a sequence of digits: (\d+|\d+[.,]\d*) as a regular expression.

For example, now it is 1674509656923 (backwards compatible) or 1674509656,923 or 1674509656.923 (obviously with ms precision).