Open mcdittmar opened 3 years ago
The column_grouping case must provide serializations where RV, q_RV, o_RV and r_RV are grouped whatever their coordinate systems. This does not mean that the VR system issue is not interesting. The role of the data provider (then the annoter) is to inform clients about the actual data frames. After this, dealing or not with this little difference (VRh vs VRb) is the reponsability of the client.
True.. it isn't the focus of the use case, I was just wanting to annotate the file as correctly as possible.
Considering the huge diversity of data serializations one can find in the landscape, it is fair to consider at some point that a mapping system do fail in a particular case. When this happens, the mapping syntax should be able at least to refer to the unsupported serialization. This is the goal of the SC_FIELD element in my syntax. It tells where is the searched measure in the data table but it does not expose it in a interoperable way.
I don't follow you here.. but also don't want to side-track the topic. If a system is not annotated, then the client does not know what system the element is in (eg: the radial velocity here). I'm not familiar enough with your syntax; don't recognize SC_FIELD and it isn't used in your annotation of this case.
SC_FIELD is out of the scope our data challenge.
For your records, it is very similar to
I have a question about the coordinate systems involved in this case. The file has COOSYS element for FK4 with equinox=B1950
The file also has Proper Motion, and Radial Velocity elements, which do not reference any coordinate system. I expect that they share the same system as the Position.. but
A little help sorting this out would be appreciated. In AstroPy, the Position, Proper Motion, and Radial Velocity are all contained within the same Frame, so I'm curious how these would reconcile into an AstroPy instance.
https://github.com/ivoa/dm-usecases/blob/0b0b4696a6571760bdddd316d37ffb35078eecf7/usecases/column_grouping/raw_data/vizier_grouped_col.xml#L98-L101