Proper motions: modeling

[mcdittmar]

There are currently 2 use cases whose data includes proper motions.
* Precise Astrometry: includes ra, dec, pm_ra, pm_dec, radial velocity, parallax
* Column Groupings: includes ra, dec, 'total' pm, radial velocity

My question has to do with the modeling of proper motion.
The Measurements model currently has ProperMotion( longitude, latitude ); which corresponds to the Precise Astrometry case. The other appears to be ProperMotion( magnitude, position_angle ) where the position angle is missing (perhaps because it is not relevant to the Column Groupings use case).

Questions:

1. am I interpreting this correctly?
2. are we going to want to support both representations of ProperMotion?

[lmichel]

1. The column_grouping case is focused on (RV, q_RV, o_RV, r_RV)
   PMs are out of the case scope.

2. In column_grouping, the pm is given as a simple angular velocity, without direction.
   

   dm-usecases/usecases/column_grouping/raw_data/vizier_grouped_col.xml

   Line 91 in 0b0b469

   <FIELD name="pm" ucd="pos.pm" datatype="short" width="4" unit="mas/yr"><!-- ucd="POS_EQ_PM" -->

   
   Not sure it worth to implement it

[msdemlei]

On Thu, Mar 04, 2021 at 07:02:19AM -0800, Mark Cresitello-Dittmar wrote: The Measurements model currently has ProperMotion( longitude, latitude ); which corresponds to the Precise Astrometry case. The other appears to be ProperMotion( magnitude, position_angle ) where the position angle is missing (perhaps because it is not relevant to the Column Groupings use case). Questions: 1. am I interpreting this correctly? 2. are we going to want to support both representations of ProperMotion?

While I won't comment on the concrete case, I'd say *if* we want to be explicit on vectors, then allowing both catesian and polar representations (that's what it is here) would sound prudent, regardless whether it's proper motions or something else. With proper motions as such, however, there is an extra trick that would make me want to deal with them in STC not as a generic vector: PMs are mostly given in the tangential plane, which for pm in RA in effect means "multiply with cos(delta)", although a certain tradition (cough) just gives the temporal derivatives. I *suspect* we'll need both variants. And that's so funky that I'd probably have a custom spherical position in STC that links together time, longitude, latitude, distance/parallax (not sure yet what I'd call it), and the temporal derivatives with an option for tangential plane or not. This would kill PMs given in polar coordinates, but I expect we could postpone that until we better understand a more general framework. Sure, having this spherical position as a special case is a bit ugly, but building a general framework that lets us do this orthogonally seems hard to me. On the other hand, just having this thing would let us annotate the positions and proper motions in the overwhelming majority of astronomical catalogues at least in my data center, and probably in VizieR (say), too. So, special-casing this seems a good deal to me.

[mcdittmar]

Laurent, I'm not planning on annotating the PM in that use case, but one of our goals here is to evaluate the compatibility of the M|C|T models for 'real world data'. Since the file for the Groupings case happens to have a PM which is different from the one in the Astrometry case, it seems like a good splinter discussion since the current model for PM won't support this form (assuming the angle is available somewhere).

…

On Thu, Mar 4, 2021 at 11:51 AM Laurent MICHEL ***@***.***> wrote: 1. The column_grouping case is focused on (RV, q_RV, o_RV, r_RV) PMs are out of the case scope. 2. In column_grouping, the pm is given as a simple angular velocity, without direction. https://github.com/ivoa/dm-usecases/blob/0b0b4696a6571760bdddd316d37ffb35078eecf7/usecases/column_grouping/raw_data/vizier_grouped_col.xml#L91 Not sure it worth to implement it — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMLJCWXLC75OKPUMF43RRLTB63ALANCNFSM4YTNCYZQ> .

[lmichel]

Mark
I agree, it is not required to map PM in this case, but the issue of the exotic data serializations must be kept open.

Not sure that in our sample the angle is available somewhere. People might be only interested in PM modulus which is enough to compute an error cone.

[lmichel]

Markus,

The way to support different representations for a particular measure must be well documented in the context of that measure.

Managing cos(delta) is a real a trick. It has been added and then removed from Mango on the behalf that almost all catalogues have PM.RAs natively including this correction. This assumption must however by confirmed by data providers.

In my opinion, it would be wise to raise a flag when cos(delta) has been applied.

About the combination of pos/pn/vr/parallax, we kept focused on the cross-match use case for wich we need to combine errors. This is the purpose of MANGO error extension. The error combination is based on the associatedParameters UCDs(see mango:exterrors package).
X-match is a big challenge for out exercise because this is the case where we need a perfect interoperability.

[mcdittmar]

Laurent:

> added then removed from Mango

• the Mango model doesn't include ProperMotion, right?, that is in Measurements. There, we have have not (yet) added any indication whether or not the cos(delta) is applied, leaving it to the usage thread to specify the expectations.

the x-match case is sounding very interesting!

[lmichel]

Mango do use meas:ProperMotion actually.
The question of tagging the use of cos(delta) would have imply to extend that class.

added then removed from Mango:
This was in the description of the complex errors which is not par of meas