Fwd: [meas] RFC comments - FXP
Francois-Xavier PINEAU
francois-xavier.pineau at astro.unistra.fr
Thu Oct 3 14:20:56 CEST 2019
> 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>
More information about the dm
mailing list