Epcoh mapping in Coords:SpaceFrame

[lmichel]

In the context of the EpochPosition property, there are 2 ways to declare the observation date:

1. By using the mango:EpochPostion.obsDate attribute. This has to be used especially when the observation date is given in a specific column.
2. By setting the epoch field in the space coord system which is imported from coords (coords:SpaceFrame)

The problem occurs when want to set an epoch to a space system that has a standard reference position such as BARYCENTER.

As shown above, working with a standard reference position requires using the StdRefLocation class, which has no epoch attribute. To set an epoch, we must work with the CustomRefLocation class, which requires the reference location to be given as a coords:Point. This is nearly impossible for the standard positions.

There are two options to work around this issue:

1. Derive a specific mango:SpaceSys class from coords:SpaceFrame arranged in a way the epoch can coexist with standard reference positions.
2. Update the current spec to recommand not using the CustomRefLocation version of coords:SpaceFrame and using preferably the mango:EpochPostion.obsDate to specify the epoch.

[lmichel]

I vote for the option 2 for its simplicity.

[loumir]

the second option seems also ok for me : it states explicitly the epoch as a date in the peculiar class EpochPosition .
Consistent with the Epoch Position use-case .

[mcdittmar]

@lmichel / all, I'm just seeing this today (yesterday was a holiday here).

The 'epoch' on coords:CustomRefLocation is the epoch of the Reference Location data. There is no connection to the 'epoch' of the Measure-d data (eg meas:Position). So, there is no conflict there.

The former EpochPosition.epoch, now Epoch.obsDate would map to a Measure attribute to indicate the epoch of that Measure.
This was held back from Measurements v1.0, pending a proper use case to work out where/how exactly it fits into the model. (similar to confidence level).

A handy reference to the mapping of EpochPosition (previous iteration) to the full Measurements/Coordinates descriptions is in my Malta presentation: https://wiki.ivoa.net/internal/IVOA/InterOpNov2024DM/modelOverlap_Nov2024.pdf

However, the current description as 'Observation Date' rather blurs the purpose. Possibly being confused with the "Date of the Observation" metadata.. from Characterization. There is an open discussion on this in Spectrum (ivoa-std/SpectrumDM#8). This is a broader, static term which would not necessarily be the same as the Measurement epoch.

I don't think that Characterization comes into play with the MANGO use cases, so is probably fine. That's just what I think of when I see Observation Date.

[lmichel]

The 'epoch' on coords:CustomRefLocation is the epoch of the Reference Location data. There is no connection to the 'epoch' of the Measure-d data (eg meas:Position). So, there is no conflict there.

Thank you, this was not clear for me.

The former EpochPosition.epoch, now Epoch.obsDate would....

With the EpochPosition, we have a (very) good use-case. This attribute should be common (super-class) for all measurements classes.
In your Malta presentation (P18+) you tag the link with a question mark with is consistent with the previous section.

However, the current description ...

Observation date (obsDate) is a basic term not tied to a specific context. It simply indicates the date on which the quantity was measured (or observed). I don't think it conflicts with characterization or spectrum DM either. Perhaps @loumir could tell us more about this.

I propose to let it as it is