Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Column Groups: Question on coordinate systems involved #8

Open
mcdittmar opened this issue Mar 4, 2021 · 5 comments
Open

Column Groups: Question on coordinate systems involved #8

mcdittmar opened this issue Mar 4, 2021 · 5 comments

Comments

@mcdittmar
Copy link
Collaborator

I have a question about the coordinate systems involved in this case.
The file has COOSYS element for FK4 with equinox=B1950
* the RA,DEC columns refer to this system

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
* Radial Velocity ucd and description both say this is "HELIOCENTRIC"
and my understanding is that FK4 origin is the BARYCENTER, not the HELIOCENTER.

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.

<FIELD name="RV" ucd="spect.dopplerVeloc;pos.heliocentric" datatype="float" width="6" precision="1" unit="km/s"><!-- ucd="VELOC_HC" -->
<DESCRIPTION>? Heliocentric radial velocity</DESCRIPTION>
<VALUES null="NaN" />
</FIELD>

@lmichel
Copy link
Collaborator

lmichel commented Mar 4, 2021

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.

@mcdittmar
Copy link
Collaborator Author

True.. it isn't the focus of the use case, I was just wanting to annotate the file as correctly as possible.

@lmichel
Copy link
Collaborator

lmichel commented Mar 5, 2021

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.

@mcdittmar
Copy link
Collaborator Author

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.

@lmichel
Copy link
Collaborator

lmichel commented Mar 10, 2021

SC_FIELD is out of the scope our data challenge.
For your records, it is very similar to .
It provides the location of a quantity in a table but with no other meta data than those of the element.
This might be useful for a smart client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants