Fwd: [meas] RFC comments - FXP
Laurent Michel
laurent.michel at astro.unistra.fr
Fri Oct 4 12:31:37 CEST 2019
Hi,
The fact that the model is not able to provide a fine-grained description of the errors for some major catalogs is a real issue
that need further investigations.
In practice, this means that people mapping e.g. Wise sources on Meas will have to recompute errors to make them matching the
model. This is furthermore not always possible.
This also impacts the CAB-MSD (source model) I'm working on, especially for the XMatch use case of course.
As it seems clear the Meas V1 likely won't evolve in this area, I think that readers must be warned on this point.
The 4th bullet in the introduction has to be reworded as well as the requirement [meas.06] at least.
Cheers
LM
The restrictions, risen by F.X. Pineau
Le 03/10/2019 à 23:19, CresitelloDittmar, Mark a écrit :
> Right,
>
> Keep in mind, that source catalogues are not in the use case(s) for this iteration of the models.
> This version is to support the Cube model which is focused on Sparse Cubes (Event list) and Images.
>
> It is meant to set the framework for exploring catalogues, time series, etc which will feed more
> requirements down to the Meas/Coords models.. like other properties, improved error modeling, etc.
>
> This is why I'm interested in separating things that are modeled incorrectly (so we can fix or remove them from this version),
> versus things which are OK, but need refining to be more broadly useful (which can be put in a 'next' category).
>
> Mark
>
>
> On Thu, Oct 3, 2019 at 8:21 AM Francois-Xavier PINEAU <francois-xavier.pineau at astro.unistra.fr
> <mailto:francois-xavier.pineau at astro.unistra.fr>> wrote:
>
>
>
>> 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
>
--
jesuischarlie/Tunis/Paris/Bruxelles/Berlin
Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
More information about the dm
mailing list