Fwd: [meas] RFC comments - FXP

[Francois-Xavier PINEAU]

> In my opinion, the current model can't accurately describe the Chandra 
> positional errors
>
Unless the proper conversions are made in the mapping...

>
> 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/112beebb/attachment-0001.html>