String Measurement with STC2

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Fri Aug 30 22:06:50 CEST 2019


On the Region front:

Going into the STC2 work with Arnold, I always envisioned that the Region
portion would be based on Coordinates, using them as the vertices, etc. and
adding the context of the domain space.
   Circle:
      + center: CoordValue[2]   <-- ties into coordspace/frames
      + radius: Quantity

However, Pat presented.. not too long ago, a counter example.
caveat: errors in interpretation are purely my own.
In his case, he REALLY doesn't care about the domain context.. just wants
to know if this set of numbers is inside/outside this shape.  This flips
things
where the coordspace/frame context is on the shape (if at all)
   Point:
      + x
      + y
   Circle:
      + center: Point
      + radius: real

Something like that.. I think it's getting some discussion on the DAL list
( DALI-next ).
I'm not sure if this boils down to something like
  "The DALI Shapes implement the Region data model, ignoring the coordinate
frame/space context."
or if there is something deeper to coordinate/resolve.

Definitely worth some conversation with Pat in Groningen.

Mark




On Fri, Aug 30, 2019 at 2:25 PM Laurent MICHEL <
laurent.michel at astro.unistra.fr> wrote:

> Mark & DMers,
>
>
> Le 30/08/2019 à 18:04, CresitelloDittmar, Mark a écrit :
> > Laurent,
> >
> > To answer the primary question:
> >    Yes, the models do allow for 'discrete' data, and this is exercised
> > with the Polarization object.
> >    The values (coord) are PolCoordValue types from the coordinates
> > model, which are Enumerations (matching your second use case).
>
> That's right. Polarization states and object classes can be both
> described by enums.
>
> >
> > My expectation for Source model is that it will define other properties
> > which extend Measure in much
> > the same way as the current suite ( Position, Velocity, ProperMotion,
> > Time, Polarization ).  By extending
> > Measure, they will automatically be usable in Cube-s.
> That exactly the pattern I'm working on. The first STC extension I need
> is for the photometric measurements of course.
> >
> > As for non-numeric data.. it really depends on what the string
> represents.
> >    e.g. "Q" =  Stokes Polarization
> >
> > In your examples, a MOC or STC-S string do not equate to Measure.
> > STC-S = a standardized serialization for specific sets of STC-1.33
> objects.
> > o The string itself maps to a set of complex objects, not a single value
> > o  It spans more of STC-1.33 than is covered by the new component models
> > (Coords, Meas, Trans).
> >     So, while it should be possible to express a Measurement instance as
> > an STC-S string, not all STC-S
> >     strings can be resolved into NEW component model instances.  For
> > example, STC-S includes Regions
> Region are sufficient for my purpose.
> >     and Intervals, as well as some properties not covered (Spectral) in
> > the current Measurement model.
> My concern is to build a branch modeling object shapes. Whatever the
> chosen option is (MOC, STS region both or anything else) I was wondering
> whether a shape can be semantically interpreted as a Measure.
> Furthermore and practically, I'd be happy to have one superclass for all
> measurements.
> But, if I understand well, object shapes are not Measures and the most
> reasonable approach would be to have one  branch for the Measures and
> another for the geometry.
>
> >
> > So, when working the Source model, it'll be important to identify which
> > Properties can extend Measure
> > (or reuse components thereof), and what concepts are 'missing' (eg:
> Region).
> Sure, the best approach is first to reuse VO stuff as much as possible
> and when this is not possible to be inspired by other standards or
> proposals and finally thinking to new things.
>
> Laurent
> >
> > Mark
> >
> >
> > On Mon, Aug 26, 2019 at 11:26 AM Laurent Michel
> > <laurent.michel at astro.unistra.fr
> > <mailto:laurent.michel at astro.unistra.fr>> wrote:
> >
> >     Hello DMers,
> >
> >     I'm experimenting the use of STC2 (Meas/Cood) for a proposal for a
> >     generic model for source data.
> >
> >     The idea is to use, as lond as possible,  STC2 measures for all
> >     quantities attached to one source.
> >
> >     My question is to know whether it is possible to have a Measurement
> >     with non numerical values.
> >     I've 2 use cases:
> >     - Object shape: a MOC or a STC string, both being possibly
> >     serialized as strings
> >     - Object type: literal
> >
> >     Can I use Generic classes (GenericMeasure and GenericCoord) or
> >     should I extend meas:Measure with my own stuff?
> >
> >     Best
> >     Laurent
> >
> >     --
> >     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
> >
>
> --
> ---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
>       Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
>       11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
>       67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
> ---
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190830/611f386a/attachment-0001.html>


More information about the dm mailing list