<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Mark,</p>
    <p>I just checked the Chandra documentation:
      <a class="moz-txt-link-freetext" href="http://cxc.harvard.edu/csc2/columns/master.html">http://cxc.harvard.edu/csc2/columns/master.html</a> and
      <a class="moz-txt-link-freetext" href="http://cxc.harvard.edu/csc2/columns/positions.html#ra_dec">http://cxc.harvard.edu/csc2/columns/positions.html#ra_dec</a></p>
    <p>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).<br>
    </p>
    <p>fx</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Le 02/10/2019 à 19:36, Francois-Xavier
      PINEAU a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:13af7519-3e56-d5ec-15e8-2e9e5229ec94@astro.unistra.fr">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <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"
            &lt;<a href="mailto:mdittmar@cfa.harvard.edu"
              moz-do-not-send="true">mdittmar@cfa.harvard.edu</a>&gt;<br>
            <b>Date:</b> 30 septembre 2019 à 22:06:49 UTC+2<br>
            <b>Destinataire:</b> Data Models mailing list &lt;<a
              href="mailto:dm@ivoa.net" moz-do-not-send="true">dm@ivoa.net</a>&gt;<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>
    </blockquote>
  </body>
</html>