<div dir="ltr"><div>On the Region front:<br><br></div><div>Going into the STC2 work with Arnold, I always envisioned that the Region <br></div><div>portion would be based on Coordinates, using them as the vertices, etc. and<br></div><div>adding the context of the domain space.<br></div><div> Circle:<br></div><div> + center: CoordValue[2] <-- ties into coordspace/frames<br></div><div> + radius: Quantity<br></div><div><br>However, Pat presented.. not too long ago, a counter example.<br></div><div>caveat: errors in interpretation are purely my own.<br></div><div>In his case, he REALLY doesn't care about the domain context.. just wants<br></div><div>to know if this set of numbers is inside/outside this shape. This flips things<br></div><div>where the coordspace/frame context is on the shape (if at all)<br></div><div> Point:<br></div><div> + x<br></div><div> + y<br></div><div> Circle:<br></div><div> + center: Point<br></div><div> + radius: real<br></div><div><br></div><div>Something like that.. I think it's getting some discussion on the DAL list ( DALI-next ).<br></div><div>I'm not sure if this boils down to something like<br></div><div> "The DALI Shapes implement the Region data model, ignoring the coordinate frame/space context."<br></div><div>or if there is something deeper to coordinate/resolve.<br></div><div><br></div><div>Definitely worth some conversation with Pat in Groningen.<br></div><div><br></div>Mark<br><br><div><br><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2019 at 2:25 PM Laurent MICHEL <<a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Mark & DMers,<br>
<br>
<br>
Le 30/08/2019 à 18:04, CresitelloDittmar, Mark a écrit :<br>
> Laurent,<br>
> <br>
> To answer the primary question:<br>
> Yes, the models do allow for 'discrete' data, and this is exercised <br>
> with the Polarization object.<br>
> The values (coord) are PolCoordValue types from the coordinates <br>
> model, which are Enumerations (matching your second use case).<br>
<br>
That's right. Polarization states and object classes can be both <br>
described by enums.<br>
<br>
> <br>
> My expectation for Source model is that it will define other properties <br>
> which extend Measure in much<br>
> the same way as the current suite ( Position, Velocity, ProperMotion, <br>
> Time, Polarization ). By extending<br>
> Measure, they will automatically be usable in Cube-s.<br>
That exactly the pattern I'm working on. The first STC extension I need <br>
is for the photometric measurements of course.<br>
> <br>
> As for non-numeric data.. it really depends on what the string represents.<br>
> e.g. "Q" = Stokes Polarization<br>
> <br>
> In your examples, a MOC or STC-S string do not equate to Measure.<br>
> STC-S = a standardized serialization for specific sets of STC-1.33 objects.<br>
> o The string itself maps to a set of complex objects, not a single value<br>
> o It spans more of STC-1.33 than is covered by the new component models <br>
> (Coords, Meas, Trans).<br>
> So, while it should be possible to express a Measurement instance as <br>
> an STC-S string, not all STC-S<br>
> strings can be resolved into NEW component model instances. For <br>
> example, STC-S includes Regions<br>
Region are sufficient for my purpose.<br>
> and Intervals, as well as some properties not covered (Spectral) in <br>
> the current Measurement model.<br>
My concern is to build a branch modeling object shapes. Whatever the <br>
chosen option is (MOC, STS region both or anything else) I was wondering <br>
whether a shape can be semantically interpreted as a Measure.<br>
Furthermore and practically, I'd be happy to have one superclass for all <br>
measurements.<br>
But, if I understand well, object shapes are not Measures and the most <br>
reasonable approach would be to have one branch for the Measures and <br>
another for the geometry.<br>
<br>
> <br>
> So, when working the Source model, it'll be important to identify which <br>
> Properties can extend Measure<br>
> (or reuse components thereof), and what concepts are 'missing' (eg: Region).<br>
Sure, the best approach is first to reuse VO stuff as much as possible <br>
and when this is not possible to be inspired by other standards or <br>
proposals and finally thinking to new things.<br>
<br>
Laurent<br>
> <br>
> Mark<br>
> <br>
> <br>
> On Mon, Aug 26, 2019 at 11:26 AM Laurent Michel <br>
> <<a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a> <br>
> <mailto:<a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a>>> wrote:<br>
> <br>
> Hello DMers,<br>
> <br>
> I'm experimenting the use of STC2 (Meas/Cood) for a proposal for a<br>
> generic model for source data.<br>
> <br>
> The idea is to use, as lond as possible, STC2 measures for all<br>
> quantities attached to one source.<br>
> <br>
> My question is to know whether it is possible to have a Measurement<br>
> with non numerical values.<br>
> I've 2 use cases:<br>
> - Object shape: a MOC or a STC string, both being possibly<br>
> serialized as strings<br>
> - Object type: literal<br>
> <br>
> Can I use Generic classes (GenericMeasure and GenericCoord) or<br>
> should I extend meas:Measure with my own stuff?<br>
> <br>
> Best<br>
> Laurent<br>
> <br>
> -- <br>
> jesuischarlie/Tunis/Paris/Bruxelles/Berlin<br>
> <br>
> Laurent Michel<br>
> SSC XMM-Newton<br>
> Tél : +33 (0)3 68 85 24 37<br>
> Fax : +33 (0)3 )3 68 85 24 32<br>
> Université de Strasbourg <<a href="http://www.unistra.fr" rel="noreferrer" target="_blank">http://www.unistra.fr</a>><br>
> Observatoire Astronomique<br>
> 11 Rue de l'Université<br>
> F - 67200 Strasbourg<br>
> <br>
<br>
-- <br>
---- Laurent MICHEL Tel (33 0) 3 68 85 24 37<br>
Observatoire de Strasbourg Fax (33 0) 3 68 85 24 32<br>
11 Rue de l'Universite Mail <a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a><br>
67000 Strasbourg (France) Web <a href="http://astro.u-strasbg.fr/%7Emichel" rel="noreferrer" target="_blank">http://astro.u-strasbg.fr/~michel</a><br>
---<br>
</blockquote></div></div></div>