Fwd: [meas] RFC comments - FXP

[Francois-Xavier PINEAU]

Mark,

I just checked the Chandra documentation: 
http://cxc.harvard.edu/csc2/columns/master.html and 
http://cxc.harvard.edu/csc2/columns/positions.html#ra_dec

In my opinion, the current model can't accurately describe the Chandra 
positional errors because "The radii of the semi-major and semi-minor 
axes correspond to the 95% confidence intervals along these axes" while 
ellipses obtained from the eigenvalue decomposition of covariance 
matrices provide 68.xx% confidence intervals (and 39.xx% if we consider 
the inside of the ellipse instead of each individual axis).

fx


Le 02/10/2019 à 19:36, Francois-Xavier PINEAU a écrit :
>>> *Expéditeur:* "CresitelloDittmar, Mark" <mdittmar at cfa.harvard.edu 
>>> <mailto:mdittmar at cfa.harvard.edu>>
>>> *Date:* 30 septembre 2019 à 22:06:49 UTC+2
>>> *Destinataire:* Data Models mailing list <dm at ivoa.net 
>>> <mailto:dm at ivoa.net>>
>>> *Objet:* *[meas] RFC comments - FXP*
>>>
>>> Francois-Xavier,
>>>
>>> Thanks for posting your comments on the measurement model RFC page.
>>> I suppose this comment/request applies to both yours and Markus' 
>>> comments...
>>>
>>> Can you make a statement about whether you see a fundamental 
>>> conflict in the model with the applications you are considering (eg: 
>>> Gaia), or if the content is compatible, but would need 
>>> enhancing/refining to accommodate your case better or more fully.
>
> Mark,
>
> See here after: with the current version of the model, I don't know 
> how to describe the XMM (or GALEX) positional error.
>
> I also have the feeling that it does not cover the "complexity" of the 
> Gaia (or Hipparcos) astrometry.
>
>>>
>>> If I read your points correctly it looks like:
>>>   + the error matrix component is very likely to be problematic as 
>>> currently modeled (seconding Markus' comments).
>
> I am not sure if the problem comes from the model or from the mapping 
> of the model to catalogue data.
>
> For example, in "Matrix2x2":
>
> 1 - m11 and m22 are variances while in catalogues we usually find 
> standard deviations.
>
> 2 - m12(=m21) are co-variances while in practice the co-variance is 
> often the product of 3 columns (2 std dev + correlation): rho * sigma1 
> * sigma2.
>
> Is the model trying to describe all the possible mappings?
>
> 1 - if yes, standard deviation, correlation, co-sigma are missing
>
> 2-  if not, Ellipse and Ellipsoid may be redundant with 
> CovarianceMatrix2x2 and 3x3 if we consider standard 1 sigma errors in 
> each dimension.
>
> (Why not a generic CovarianceMatrix with a dimension having the 
> dimension of the measurement?)
>
>
> May a measurement be a composition of measurements?
>
> Considering Gaia (letting aside plx and Vr so far to simplify):
>
> - like it is already possible with the current model, we could 
> describe a Pos(+err) measurement and a PM(+err) measurement: a lot of 
> tools will be happy just with Pos, Aladin will also use PM with an 
> epoch slider.
>
> - increasing the complexity for more advanced/precise tools, we could 
> additionally describe and Astrometric (?) measurement being made of 
> the composition of Pos(+err) + PM(+err)  + correlations between Pos 
> and PM errors
>
>>>      So, I fully expect to push that element to a 'next' phase where 
>>> the Gaia usage might be a good thread to exercise it more directly.
> But we have to ensure that the 'next' phase will be compatible with 
> the current one, right?
>>>    + Elliptical, Ellipsoid are compatible, but could be enhanced by 
>>> the addition of 'confidence level'.  Laurent has also mentioned this.
> 'Confidence level' or multiplication factor to get '1 sigma'.
>>>       This I would also prefer to push to a 'next' phase working a 
>>> use-case which contains them.
>>>
> In this case, the document should probably state what can/can't be 
> describe in its current version.
>
> Is a symmetrical uncertainty allowed to describe a radial error?
>
> Explanations: I see a possible confusion naming 'radius' the 
> Symmetrical uncertainty value:
>
> A - is it the 1 sigma error of the distribution on the polar 'r' 
> coordinate?
>
> B - is it the 1 sigma value of the distributions on each independent 
> ('x', 'y', ...) coordinate?
>
> I understand from the definition in 10.2(.1) that the document 
> describe case B, but some catalogues (like XMM) provide a value 
> corresponding to case A.
>
> So I don't know how to describe the XMM (or GALEX) positional error in 
> the current version of the model.
>
>>> The others are more straightforward/clarifications:
>>>    + drop one of 'stat' and 'rand'.. I'm fine with that.
> Ok
>>>    + definition of Ellipse.posAngle
>>>       - I'd like the definition to match the common usage.. but I 
>>> was under the impression that "East of North" was a 
>>> counter-clockwise direction.  Pulling from wikipedia (yeah.. I 
>>> know);  "The International Astronomical Union defines it as the 
>>> angle measured relative to the north celestial pole (NCP), turning 
>>> positive into the direction of the right ascension. In the standard 
>>> (non-flipped) images this is a counterclockwise measure relative to 
>>> the axis into the direction of positive declination."
>
> Well, "counter-clockwise" depends if one looks from the interior or 
> from the exterior of the unit sphere.
>
> Taking the East as the x-axis and the North as the y-axis in a regular 
> frame representation (x increasing in the right direction and y 
> increasing in the top direction), East of North is clockwise.
>
> The Meas document definition is: "counter-clockwise from the positive 
> direction of the FIRST axis of the associated Coordinate"
>
> I may miss-interpret, but I consider the FIRST axis to be the local 
> East while the position angle is defined from the North axis).
>
> (By-the-way, do we agree that the errors associated to Lon and Lat are 
> actually the errors in the local frame, i.e., to make it simple, the 
> ones associated to Lon*cos(Lat) and Lat?).
>
>>>    + re: Equatorial, Galactic, Ecliptic positions..
>>>       Yes, this is a bit orthogonal to Cartesian.  The motivation is 
>>> that at this level, I'm trying to expose the 'properties' that occur 
>>> most often in our data which we would want to identify quickly and 
>>> easily.  Setting a basis which can be expanded on in the Source 
>>> properties thread.  I have expected that "(ra,dec)" vs "(l,b)" might 
>>> be an important distinction despite them both being Spherical.  If I 
>>> open a cube, catalog or whatever and find SphericalPosition-s, then 
>>> still have to go to the Frame to determine if it's an ra/dec or l/b 
>>> or lon/lat of an observatory.  That's extra steps.  Maybe that isn't 
>>> so important?
>
> When I see (l,b), I think: those are the longitude and latitude in 
> galactic (with the difference that in galactic the longitude may be in 
> ]-180, 180] instead of [0, 360[).
>
> The column names (l, b), (ra, dec), (elon, elat) all implicitly 
> describe longitude and latitude (in degrees or in sexagesimal) 
> providing additional information on the coordinate system (with 
> ambiguities in the case of (ra, dec): FK5, ICRS, ... ?).
>
> As far as the model provides the coordinate system associated to a 
> position, I (so far) do not understand the need to explicitly have the 
> different column names in duplicated classes.
>
> (Like mentioned by Markus, I also prefer to prevent possible 
> incoherence by replacing the duplicated classes EquatorialPos, 
> GalacticPos and EclipticPos by a single class).
>
>>>
>>> Mark
> fx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20191003/f19b574c/attachment.html>