<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr"><b>Expéditeur:</b> "CresitelloDittmar, Mark" <<a
href="mailto:mdittmar@cfa.harvard.edu"
moz-do-not-send="true">mdittmar@cfa.harvard.edu</a>><br>
<b>Date:</b> 30 septembre 2019 à 22:06:49 UTC+2<br>
<b>Destinataire:</b> Data Models mailing list <<a
href="mailto:dm@ivoa.net" moz-do-not-send="true">dm@ivoa.net</a>><br>
<b>Objet:</b> <b>[meas] RFC comments - FXP</b><br>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Francois-Xavier,<br>
<br>
</div>
Thanks for posting your comments on
the measurement model RFC page.<br>
</div>
I suppose this comment/request applies
to both yours and Markus' comments...<br>
</div>
<br>
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.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<p>Mark,<br>
</p>
<p>See here after: with the current version of the model, I don't
know how to describe the XMM (or GALEX) positional error.</p>
<p>I also have the feeling that it does not cover the "complexity"
of the Gaia (or Hipparcos) astrometry.<br>
</p>
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
If I read your points correctly it looks
like:<br>
</div>
+ the error matrix component is very likely
to be problematic as currently modeled
(seconding Markus' comments).<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<p>I am not sure if the problem comes from the model or from the
mapping of the model to catalogue data.</p>
<p>For example, in "Matrix2x2":</p>
<p>1 - m11 and m22 are variances while in catalogues we usually find
standard deviations.<br>
</p>
<p>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.</p>
<p>Is the model trying to describe all the possible mappings?</p>
<p>1 - if yes, standard deviation, correlation, co-sigma are missing<br>
</p>
<p>2- if not, Ellipse and Ellipsoid may be redundant with
CovarianceMatrix2x2 and 3x3 if we consider standard 1 sigma errors
in each dimension.</p>
<p>(Why not a generic CovarianceMatrix with a dimension having the
dimension of the measurement?)</p>
<p><br>
</p>
<p>May a measurement be a composition of measurements?</p>
<p>Considering Gaia (letting aside plx and Vr so far to simplify):</p>
<p>- 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.<br>
</p>
<p>- 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</p>
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div> 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.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
But we have to ensure that the 'next' phase will be compatible with
the current one, right?<br>
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>
<div>
<div> + Elliptical, Ellipsoid are compatible, but
could be enhanced by the addition of 'confidence
level'. Laurent has also mentioned this.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
'Confidence level' or multiplication factor to get '1 sigma'.<br>
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>
<div>
<div> This I would also prefer to push to a
'next' phase working a use-case which contains
them.<br>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<p>In this case, the document should probably state what can/can't
be describe in its current version.</p>
<p>Is a symmetrical uncertainty allowed to describe a radial error?</p>
<p>Explanations: I see a possible confusion naming 'radius' the
Symmetrical uncertainty value:</p>
<p>A - is it the 1 sigma error of the distribution on the polar 'r'
coordinate?<br>
</p>
<p>B - is it the 1 sigma value of the distributions on each
independent ('x', 'y', ...) coordinate?</p>
<p>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.</p>
<p>So I don't know how to describe the XMM (or GALEX) positional
error in the current version of the model.<br>
</p>
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>
<div>The others are more
straightforward/clarifications:<br>
</div>
+ drop one of 'stat' and 'rand'.. I'm fine with
that.<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
Ok<br>
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div> + definition of Ellipse.posAngle<br>
</div>
- 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."</div>
</div>
</div>
</blockquote>
</blockquote>
<p>Well, "counter-clockwise" depends if one looks from the interior
or from the exterior of the unit sphere. <br>
</p>
<p>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.<br>
</p>
<p>The Meas document definition is: "counter-clockwise from the
positive direction of the FIRST axis of the associated Coordinate"</p>
<p>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).<br>
</p>
<p>(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?).<br>
</p>
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>
<div> + re: Equatorial, Galactic, Ecliptic
positions..<br>
</div>
<div> 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?<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<p>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[).</p>
<p>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, ... ?).<br>
</p>
<p>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.<br>
</p>
<p>(Like mentioned by Markus, I also prefer to prevent possible
incoherence by replacing the duplicated classes EquatorialPos,
GalacticPos and EclipticPos by a single class). <br>
</p>
<blockquote type="cite"
cite="mid:F442E35D-6F94-481B-8AF0-19D0FC2E1882@astro.unistra.fr">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>
<div><br>
</div>
<div>Mark<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
fx<br>
</body>
</html>