[cube] - relation to STC
mdittmar at cfa.harvard.edu
Fri Feb 3 23:56:32 CET 2017
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.
First.. the bulk of my changes to NDCube w.r.t. STC recently has been to
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.
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
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)
ra dec spectral flux flux_error
axes: [@ra, @dec, @spectral]
dependent_axes: [@flux, @flux_error]
long_error: 2 mas
lat_error: 5 mas
min: 2e-7 m
max: 4e-7 m
value_error: 1e-10 m
Photometry annotation (I've not actually looked at PhotDM, so this is
-- 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm