<div dir="ltr">Right,<div><br></div><div>Keep in mind, that source catalogues are not in the use case(s) for this iteration of the models.</div><div>This version is to support the Cube model which is focused on Sparse Cubes (Event list) and Images.</div><div><br></div><div>It is meant to set the framework for exploring catalogues, time series, etc which will feed more </div><div>requirements down to the Meas/Coords models.. like other properties, improved error modeling, etc.</div><div><br></div><div>This is why I&#39;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 &#39;next&#39; category).</div><div><br></div><div>Mark</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2019 at 8:21 AM Francois-Xavier PINEAU &lt;<a href="mailto:francois-xavier.pineau@astro.unistra.fr">francois-xavier.pineau@astro.unistra.fr</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <br>
    <br>
    <blockquote type="cite">
      <p>In my opinion, the current model can&#39;t accurately describe the
        Chandra positional errors <br>
      </p>
    </blockquote>
    <p>Unless the proper conversions are made in the mapping...</p>
    <blockquote type="cite">
      <p><br>
      </p>
      <div>Le 02/10/2019 à 19:36,
        Francois-Xavier PINEAU a écrit :<br>
      </div>
      <blockquote type="cite">
        
        <blockquote type="cite">
          <blockquote type="cite">
            <div dir="ltr"><b>Expéditeur:</b> &quot;CresitelloDittmar, Mark&quot;
              &lt;<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">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" target="_blank">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&#39;
                                    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&#39;t know how to describe the XMM (or GALEX) positional
          error.</p>
        <p>I also have the feeling that it does not cover the
          &quot;complexity&quot; of the Gaia (or Hipparcos) astrometry.<br>
        </p>
        <blockquote type="cite">
          <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&#39; 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 &quot;Matrix2x2&quot;:</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">
          <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 &#39;next&#39; 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 &#39;next&#39; phase will be compatible
        with the current one, right?<br>
        <blockquote type="cite">
          <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
                          &#39;confidence level&#39;.  Laurent has also
                          mentioned this.<br>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </blockquote>
        </blockquote>
        &#39;Confidence level&#39; or multiplication factor to get &#39;1 sigma&#39;.<br>
        <blockquote type="cite">
          <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
                          &#39;next&#39; 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&#39;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 &#39;radius&#39; the
          Symmetrical uncertainty value:</p>
        <p>A - is it the 1 sigma error of the distribution on the polar
          &#39;r&#39; coordinate?<br>
        </p>
        <p>B - is it the 1 sigma value of the distributions on each
          independent (&#39;x&#39;, &#39;y&#39;, ...) 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&#39;t know how to describe the XMM (or GALEX) positional
          error in the current version of the model.<br>
        </p>
        <blockquote type="cite">
          <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 &#39;stat&#39; and &#39;rand&#39;.. I&#39;m fine with
                      that.<br>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </blockquote>
        </blockquote>
        Ok<br>
        <blockquote type="cite">
          <blockquote type="cite">
            <div dir="ltr">
              <div dir="ltr">
                <div dir="ltr">
                  <div>   + definition of Ellipse.posAngle<br>
                  </div>
                        - I&#39;d like the definition to match the common
                  usage.. but I was under the impression that &quot;East of
                  North&quot; was a counter-clockwise direction.  Pulling
                  from wikipedia (yeah.. I know);  &quot;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.&quot;</div>
              </div>
            </div>
          </blockquote>
        </blockquote>
        <p>Well, &quot;counter-clockwise&quot; 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: &quot;counter-clockwise from the
          positive direction of the FIRST axis of the associated
          Coordinate&quot;</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">
          <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&#39;m trying to expose the &#39;properties&#39;
                        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
                        &quot;(ra,dec)&quot; vs &quot;(l,b)&quot; 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&#39;s an ra/dec or l/b
                        or lon/lat of an observatory.  That&#39;s extra
                        steps.  Maybe that isn&#39;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">
          <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>
    </blockquote>
  </div>

</blockquote></div>