[cube] - relation to STC

[CresitelloDittmar, Mark]

I'm extracting this thread from the other message (Roadmap - checkpoint)
since it might generate some discussion.

I'll respond here.. the original is included below for reference.

Markus,
  First.. the bulk of my changes to NDCube w.r.t. STC recently has been to
pull out/refine
  the relation between the two models.. making it much more generic.  I
don' t have extensive
  stc content in my model which needs to be kept in sync.

  Second..  I don't see how I would be able to remove the dependence on
STC.  We are developing
  a set of models, each of which handles a certain area of interest in the
big picture.  This allows us
  to re-use content and increase interoperability.  The model we lovingly
refer to as "STC (space-time coordinates)"
  handles the concepts/patterns for coordinate frames, systems, axes,
coordinates, and transforms.
  And it handles them *for all domains*.

  Currently, this content is broken into 3 sub-models (coordsys, coords,
trans) as requested in Trieste.
  These models define patterns for Frames and Coordinates, and implements
that pattern for each of
  the primary domains we have seen in existing models and that are required
for the example files
  in the Cube work.

  In your response, you acknowledge that NDCube needs to "define which axes
belong together" and
  "describe arrays and sparse arrays" (a.k.a. coordinates).

  Those things "axes", "coordinates" are defined in the dependent models..
so Cube must refer to them.

  As we move to other models, which need additional and/or different
domains/coordinates etc, we have a choice
    1) let it implement the patterns defined in the appropriate source
model (coordsys, coords) internally
    2) update the source model with the new domain implementation
  either one would work, and either would be interoperable because they
stem from the same pattern.

  I look forward to seeing Jiri's proposal.

Mark




Markus wrote:
======================================================================
On Mon, Jan 30, 2017 at 12:32:22PM -0500, CresitelloDittmar, Mark wrote:
> + DatasetMetadata/NDCube
>    o continued working PR requirements (examples/validation)
>    o integrate vo-dml and stc2 changes as needed

That's another point for why I'm trying to get you to pull out all of
STC (and indeed, other axis metadata) from NDCube -- this thing will
never finish if it depends on these DMs.

Can't we restrict NDCube to just defining which axes belong together
to form the cube and describe arrays and sparse arrays in a
consistent framework?

The actual axes would be directly described by extra metadata that
NDcube wouldn't need to worry about.

Jiri and I have been trying to make that happen for time series based
on NDCube as far as we could work it out, and I hope Jiri will
put out a proposal soon.  Meanwhile, the sketch would be, in the
table case (keeping out referencing array axes)

Table:

ra dec spectral flux flux_error

Dataset annotation
  pubDid...

NDCube annotation
  axes: [@ra, @dec, @spectral]
  dependent_axes: [@flux, @flux_error]

STC annotation
  2dspherical
    long: @ra
    long_error: 2 mas
    lat: @dec
    lat_error: 5 mas
    frame: ICRS
    ...

Spectral annotation
  frame: ..
  min: 2e-7 m
  max: 4e-7 m
  value: @spectral
  value_error: 1e-10 m

Photometry annotation  (I've not actually looked at PhotDM, so this is
fantasy)
  flux: @flux
  flux_error: @flux_error
  spec_window_center: @spectral
  spec_window_width: 1e-10


-- isn't it nice how it all nicely separates the various DMs?  You
could even have annotation of several different versions of a DM in
one file and for one set of columns -- and clients only understanding
photometry without having an idea of NDcube could still use whatever
information it can pull out of the photometry part.

VO-DML and the new annotation actually lets us pull this scheme off.
Any chance I can move you to adopt this kind of thing and pull the
DMs apart?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170203/1fae4aac/attachment.html>