►
From YouTube: SunPy Coordination Meeting - Tuesday
Description
A streamed community meeting, haven't seen one of these in a while. This time it's because it's a test event for pyastro
A
Kind
of
the
implementation
of
the
data
side
is
a
topic
for
another
day
and
the
metadata
is
why
I'm
going
to
talk
about
so
we
saw
that
in
a
metatext
object,
which
is
essentially
a
dictionary,
that's
a
few
other
add-ons,
so
it
has
case
and
sensitive
indexing
and
it
now
tracks
any
changes
that
are
made
to
it.
Those
are
the
two
big
things
I
can
think
of
in
my
head
and
then
we
also
have
a
dictionary
of
plot
settings
which
tell
the
map
how
it
wants
to
be
plotted.
A
A
And
so
just
having
a
dictionary
of
fits
metadata
is
kind
of
not
the
most
user-friendly
way
to
do
it.
So
on
top
of
this,
we
have
a
load
of
properties
on
the
map
which
basically
provide
an
abstraction
layer,
above
this
dictionary,
so
kind
of
taking
the
metadata,
which
is
all
in
strings
and
returning
python
objects.
So,
for
example,
coordinate
frame
will
return,
it
won't
return,
a
sky
chord,
I've
just
rise,
but
it'll
return,
a
coordinate
frame,
object
and
the
date
will
return.
Astrophy
time
objects
or
the
exposure
time
will
return
a
astrophy
quantity.
A
And
so,
as
well
as
being
user-friendly,
one
of
the
advantages
of
adding
this
abstraction
layer
is
that
it's
in
theory,
agnostic
to
the
implementation
underneath.
So
if
a
new
standard
comes
along,
that
supersedes
fits
not
that
it
will
any
time
soon.
But
if
it
does,
we
could
keep
this
layer
the
api
of
this
layer,
the
same
but
just
swap
out
how
we
handle
the
metadata
under
the
hood.
A
So,
very
briefly,
some
issues
we've
had
with
this
approach.
So
senpai
often
internally
modifies
the
metadata.
We
do
our
map
sources
and
so,
for
example,
down
here,
I've
got
an
example
of
loading,
a
hmi
map,
and
previously
there
was
no
way
to
see
what
some
pi
was
doing,
what
was
being
changed
until
senpai
3.0,
and
so
we
added
the
ability
to
track
these
changes.
A
So
you
can
see
at
the
bottom,
in
our
hmi
map
source,
we're
removing
some
nand
values
because
they're
not
consistent
with
the
fit
standard
and
otherwise
astropy
would
raise
a
warning
if
we
didn't
get
rid
of
these
and
we're
also
correcting
the
b
unit
value.
So
in
the
original
file,
this
is
a
gauss,
but
that's
not
a
fixed
standard
unit
string.
So
we
just
correct
that
to
capital
g,
so
that
is
a
change.
That's
recently
happened
to
metadata
and
then
two
other
issues.
A
A
A
So
this
is
still
the
current
case,
so
I
guess
maybe
okay
added
values
has
been
overwritten.
Values
are
perhaps
not
good
examples,
but
there
are,
I
guess
my
point
is
there
are
different
categories
of
metadata
as
well.
So,
for
example,
there
might
be
information
about
processing
history
of
the
map,
which
is
a
different
type
of
metadata
to
the
fits
wcs
metadata
and
at
the
moment,
there's
no
way
of
distinguishing
between
those.
A
C
E
C
D
A
A
A
B
A
So
I
guess
we
so
the
moment
all
the
properties
are
drawn
directly
from
the
fits
metadata
when
you
request
the
properties
right.
So
when
I
access
the
wcs
for
map,
the
property
will
go
in
into
every
time,
we'll
go
into
the
fits
metadata
and
construct
that
when
you
request
that
property,
whereas
what
I'm
proposing
is
we
create
a
wcs
object
as
soon
as
the
map
is
created
and
then
ignore
the
fits
metadata
from
then
on.
C
B
Yeah,
I
just
want
to
add
or
ask
another
a
question.
So
if
say,
you
create
a
wcs
object
and
that
you
know
and
a
standalone
and
it
doesn't
refer
back
to
the
fit
metadata
every
time
is
the
idea
going
back
to
the
previous
slide
or
actually
on
that
slide,
where
you
said
the
ground
truth,
like
you,
keep
the
original
metadata,
then
as
a
ground
truth
that
you
can
refer
back
to
like
you
could
do
reset
metadata
or
something,
and
you
could
just
reinstantiate
everything
if
you
have
done
change
upon
change
upon
change.
B
G
So
is
the
idea
that,
like
you
would
have
say,
like
dot,
observer
coordinates
and
it
wouldn't
you
know
that
then
we
could
change
that
easily
without
having
to
worry
about
how
the
different
specific
fit
files
are
written,
so
that
for
aia
it
would
be
easy
to
change
without
having
to
know
that
it
doesn't
use.
The
html,
like
those
keywords,
is
that
the
idea
yeah?
Okay,
that's
cool.
G
A
I
think
so
yeah,
so
you
we
will
have
to
write
a
set
of
code
that
would
translate
from
the
python
objects
back
to
the
fixed
metadata.
But,
for
example,
if
you
loaded
in
an
aia
map-
and
we
took
the
coordinate
information
from
saber
from
the
keys,
we
know
are
correct
at
the
moment
and
then
saved
it
back.
We
would
you
wouldn't
get
the
same
header
that
you
read
in
if
that
makes
sense,
yeah
yeah,
so
we
would,
I
guess,
consistently
write.
Carrington
coordinates
for
the
observer
coordinate
if
we
were
saving
the
map.
A
C
B
C
C
You
can
construct
an
astrophy
wcs
object
and
pass
it
to
the
map
factory,
but
what
the
map
factory
does
is
convert
it
back
to
a
header
and
then
pass
it
to
the
map,
which
then
makes
a
new
fist
of
your
cs
object.
Every
time
you
ask
for
it,
I
see
okay.
So
what
you
can't
do,
for
instance,
is
pass
a
gwcs
object
into
the
map
constructor,
because
there's
no
way
for
it
to
serialize
that
to
a
fits
header
and
pass
it
through.
C
B
B
C
C
Is
you
could
put
a
map
inside
a
nasda
file
but
anywhere
in
the
asda
file,
because
the
azdev
file
is
now
between
tree?
So
it's
not
as
simple
to
read
as
like
a
fits
header,
you
would
have
to
load
the
asda
file
and
then
look
through
this
thing
that
you've
just
loaded
to
see
whether
there
was
a
map
instance
in
it.
B
Yeah,
I
don't
know
if
this
is
something
that's
obvious
or
that's
something
that's
very
controversial,
but
I
mean
we're
talking
about
map
meta
here
right.
What
about
like?
Sunpi,
meadow
or
solar
meta,
or
whatever
you
know
I
mean,
is
their
scope
for
their
being,
like
you
know,
like
a
standard
method
api
for,
like
it
doesn't
matter
whether
it's
map
or
time
series,
but
time
series
is
always
a
little
bit
of
a
of
an
outlier.
But
you
know
like
spectrogram
or.
B
So
if
we
talk
about
map
meta,
do
we
actually
again?
This
was
asked
about
scope.
Is
the
scope
actually
just
a
general
like
some
pi
metadata
object,
then
we
can
then
give
to
you
know
a
spectrogram
or
an
image
or
an
image
cube,
or
you
know
an
image
collection
of
past
bands
and
stuff
and
and
effectively
it's
just
an
array,
coordinate
transformations.
C
D
C
Map
and
other
spectrogram
objects,
or
other
things
want
to
subclass
that
and
add
more
add,
more
metadata
properties
which
return
different
python
objects,
but
yeah.
I
think
the
other
biggest
thing
that
we
haven't
really
spoken
about
yet
here,
which
is
where
the
complexity
comes
in
and
will
probably
remain
maps
specific,
at
least
in
the
short
term,
is
there
are
methods
on
map
specifically
rotate
as
the
main
example
where
the
metadata
needs
to
be
modified
under
some
transform
and
those
modifications.
B
You
could
still
have
like,
like
an
image
meta
object
that
inherits
from
basic
senpai
meta.
That
has
all
like
the
things
that
we
think
always
needed,
and
you
can
have
all
these
mix-ins,
like
you
know
where
you
have
like
spectral
matter
and
image
matter
and
temporal
matter
or
whatever,
and
so,
depending
on
what
physical
properties
you
have
depending
on
the
type
of
instrument,
you
can
sort
of
build
up.
B
This
meta
object
and
a
lot
of
the
complexity,
and
you
know
these
are,
would
you
know
we'd
sort
of
try
and
standardize
these
names
in
the
same
way
that
a
lot
of
these
properties
on
map
are
effectively
metadata
abstraction
layers,
but
just
put
it
on
a
dot
meta
object,
rather
than
on
the
on
the
data
class
itself
that
doesn't
seem
incompatible.
It
seems
like
it's
just
shifting
it
to
a
slightly
different
location,
which
makes
it
a
lot
more
easily
separable.
If
you
want
it
to
be.
A
A
I
like
the
idea-
I
do
like
the
idea,
though,
that
you
know
you
have
pieces
of
metadata
that
are
specific
to
a
2d
image
taken
as
taken
over
a
finite
amount
of
exposure.
Time
and
those
pieces
of
metadata
are
different
to
say,
piece
of
metadata.
You
would
have
for
a
spectrum,
so
having
different
objects.
Is
that,
where
you're
trying
to
get
out
having
like
different
objects
for
different
sub
sets
of
dimensions
in
ndq,.
B
Yeah,
that's
that's
consistent,
I
think,
with
what
I'm
I'm
saying,
I
guess
my
like
so
to
first
order.
What
I'm
kind
of
saying
is
to
make
a
more
stark
separation
between
the
date
and
metadata,
in
the
sense
that
we
have
like
a
data
object
that
has
a
metadata
object
attached
and
so,
instead
of
saying,
okay,
this
data
object
has
properties
that
refers
to
this
fit
sticks.
B
If
it's
dictionary
you
know
and
having
that
on
the
data
object
itself.
You
know
the
user
always
know
okay
metadata,
I
do
dot
meta
dot
whatever,
and
then
you
that
gives
you
the
scope
to
have.
You
know
various
mixins
of
metadata
objects
and
so
yeah
you
can
mix
and
match,
and
to
go
back
to
what
you
said.
You
know
to
have
sets
that
are
specific
to
your
different
physical
axes
or
your
specific
instruments
or
specific
epochs
or
you
know,
whatever
is
needed.
B
D
C
Then
there's
the
serialization
and
deserialization
part
which
is
reading
it
from
a
file
into
that
metadata,
object
and
saving
that
metadata
object
back
to
a
file.
The
types
of
those
two
files
do
not
have
to
be
the
same.
There
is
no
reason
why
you
couldn't
read
a
fits
header
and
then
save
a
bunch
of
python
objects
into
an
asdif,
not
as
a
fits
header.
C
So
you
could
read
an
as
defile
and
get
a
gw
cs
object
as
your
wcs,
which
is
fully
814
compliant
and
therefore
some
pi
will
work
with
it
perfectly
fine,
but
there's
no
way
to
save
that
gwcs
back
to
a
fixed
file.
So
you
can
you
can't
serialize
that
to
fit.
So
if
you
try
to
save
it
to
effect,
you'd
have
to
throw
an
error
going.
You
have
a
thing
that
can't
be
saved
to
a
fix.
I
can't
save
it
to
a
fix.
Would
you
like
to
save
it
to
an
asdif
file
instead,.
D
C
Do
we
need
to
to
do
that?
I
don't
know
I
don't
necessarily
need.
I
don't
necessarily
think
that
untying
the
serialization
to
fits
is
necessarily
a
high
priority
like
I
don't
think
there
are
many
things.
There
are
many
maps
in
the
world
that
aren't
coming
from
a
fits
file,
but
what
what
we
want
to
do
is
we
want
to,
at
the
moment,
map
maps,
operations,
rotate
etc,
as
well
as
loading
and
all
manner
of
other
things,
that
the
underlying
data
model
is
a
fit
serialization.
D
Well,
I
think
david's
suggestion
of
having
you
know
enabling
some
sort
of
like
getter
setter
functionality
from
modifying
the
metadata.
I
mean
that
goes
a
long
way
towards
solving
those
problems
such
that
our
dot,
rotate
or
free
sample
or
whatever
methods
don't
care.
Whether
metadata
is
is
fits
or
not.
They're
modifying
the
relevant
bit
of
derived
metadata
and
then,
if
it's
and
then
we're
dealing
with
fixed
keywords,
underneath
then
that
will
be
taken
care
of
by
the
metadata
layer
and
not
that
specific
method.
C
Yes
agreed
with
one
caveat,
which
is
applying
rotate
to
a
wcs
as
an
example
of
a
really
gnarly
thing
to
do.
Applying
rotate
to
a
wcs
is
implementation
specific
to
that
wcs
type
right.
If
you
apply
rotate
to
a
fixed
wcs,
you
change
the
pcij
matrix
on
the
fitzwcs
object
and
then
you've
rotated
it.
If
you
want
to
apply
rotate
to
a
gwcs
object
that
is
more
complicated
and
may
not
be
possible.
D
Well
like
in
in
that
case,
okay,
so
then
this
might
still
be
an
issue,
but
like
say,
then
you
would
modify
like
when
we
do
a
dot
rotate
and
you
you
align
your
pixel
world
coordinates.
Then
you
set
your
like
rotation.
We
already
have
like
the
derived
rotation
matrix
right,
so
you
set
your
rotation
matrix
to
the
identity
right
and
then
it's
up
to
the
the
underlying
metadata
model.
To
say
how
does
that
setter
correspond
with
the
the
underlying.
C
C
D
Yeah,
like
I
think
I
mean
david,
you
can
tell
me
if
I'm
wrong,
but
I
think
like
that
that,
in
your
in
your
like
proposed
solution,
then
like
it's
just,
it
would
be
rep
in
in
all
of
our
methods.
It's
replacing
those
those
all
those
lines
where
we're
setting
fits
keywords,
because
all
of
our
properties
derive
from
fits
keywords.
Where
then,
we're
then
setting
properties
instead
and
then
we're
deferring
those
the
the
the
details
of
how
that
translates
to
the
underlying
metadata
to
some
other
layer.
A
D
But
yeah,
I
think
that's
what
I
mean
is
that
our
our
then
our
map
methods
have
no
concept
of
they.
Don't
care
like
what
a
pcij
matrix
is
right,
that
that
that
level
of
granularity
is
deferred
to
the
metadata
level
and
not
to
our
like
the
operations
like
the
data
operations
on
the
map,
I
guess
that
they're
modifying
a
a
derived
like
rotation,
matrix
property
and
then
that
the
metadata
layer
differentiates
between
pcij
and
whatever
the
gwcs
equivalent
would
be
in
like
this,
I
guess
in
the
center.
C
C
C
G
D
A
Yeah,
I
definitely
think
I
think
I
even
might
have
an
issue
open
on
astrophy
or
senpai
about
yeah
separating
given
a
fits
header.
Can
you
just
tell
me
all
the
keywords
that
are
wcs
specific,
so
I
can
separate
this
out
from
the
rest
to
interpret
the
coordinate
system
so
yeah.
I
definitely
think
that
is
a
valuable
thing
to
do.
C
But
that
that
would
be
the
job
of
the
fifth
d
serializer,
that
for
the
for
the
meta
object
right,
we
would
have.
We
would
have
a
meta
object
and
we
would
have
a
fixed
d
serializer
that
takes
a
fits
header
and
returns
a
meta
object
and
inside
that
deserializer
it
would
have
to
construct
various
objects
and
remove
or
move
the
metadata
keys
from
the
fits
header
that
it
used
to
construct
those
objects,
because
that
specific
operation
of
converting
some
fits
keys
into
a
fits
wcs
object
is
a
fit
specific
problem.
A
Yeah,
but
I
think
it's
worth
some
nice
seagulls
in
the
background
and
yeah,
I
thought
I'd
kill
him
but
yeah
if
you're,
but
that
yeah,
I
guess
that's
another.
That's
an
advantage
of
relying
on
python
objects.
Is
that
you
can,
you
can
take,
you
can
take
a
fit
sub,
ucs
or
gwcs
independently
from
the
rest
of
the.
A
C
B
C
B
C
There
is
extra
work
to
be
done
there
to
make
the
deserialization
permanent,
rather
than
a
view
into
the
fits
wca
into
the
fits
metadata
right.
At
the
moment,
our
deserialization
is
deserialization
on
the
fly,
as
opposed
to
a
transformation
of
that
metadata
right.
The
metadata
is
not
transformed
upon
deserialize,
it
is,
it
is
asked
questions
of
too
dearly
deserialize
it
right.
C
Yeah,
so
coming
back
to
it
that
aia
observer
example
is
a
is
an
excellent
demonstration
of
the
point
I'm
trying
to
make
here
right
is
at
the
moment
we
calculate
observer,
coordinate
by
looking
at
the
fits
header
and
going
that's
an
observer,
coordinate
there
you
go.
The
d
serializer
into
a
metadata
object
would
have
to
check
the
header
for
every
single
supported
observer,
coordinate
pick
which
one
it
wanted
deserialize
it
and
then
delete
the
rest,
and
it's
that
last
step
that
we're
not
doing
at
the
moment.
A
H
Yeah
I
mean
I
mean
I've
never
tried
to
take
the
observer,
coordinates
that
are
in
the
fitz
foils
and
convert
them
all
to
see
if
they're
all
the
same.
But
I
would
imagine
that
you'll
probably
find
some
inconsistencies
where
you
know.
Sometimes
you
can
have
the
observer
location
in
multiple
coordinate
systems
in
the
headers,
oh
yeah,
and
so
then
you'd
like
read
it
in
from
the
one
that
you
trust.
C
B
B
D
H
D
H
H
D
G
So
I
guess,
if
you
had
that
metadata
like
object,
that
had
everything
in
it
that
you
needed
to
make
a
map
and
then
just
write
that
out
and
then
it
should
be
easy
to
read
back
in
there.
Is
that
the
idea
like
at
the
moment?
Can
you
take
a
map?
And
you
I
mean?
I
don't
think
you
can
do
this.
You
could
just
print
out
the
keywords
that
it's
actually
using
to
generate
the
map
and
to
do
everything
with
it.
Is
that
a
thing
you
can
do
at
the
moment?
G
B
H
Yeah
I
mean
like
for
fdl:
that's
what
basically,
what
half
the
project
was
reading
in
a
bunch
of
a
hmi
images,
d,
project,
rotate
them
and
then
write
them
back
out
to
fits
because
that
takes
a
long
time.
You
don't
have
to
do
it
over
and
over
now
I
wouldn't
mind
serializing
out
to
asdf
or
an
fcaf
like
it.
Doesn't
it
doesn't
bother
me
what
what's
written,
but
you
definitely
want
to
be
able
to
save
maps
after
you
do
stuff
to
them.
G
D
I
mean
I
will
say
that
being
able
to
construct
a
map
from
like
a
data
array
plus
essentially
a
dictionary,
does
make
serialization
to
other
formats
extremely
easy.
Like
say:
if
you
want
to
stick
these
in
an
hdf5
file
or
something
like
that,
that's
you
know
dead,
simple
to
do
and
then
you
can
you
can
you
can
do
I
mean
you
have
to
do
that
yourself?
G
But
like
just
the
silly
question,
if
you
have
a
map-
and
you
have
it
in
this
nice
format,
where
you
have
your
meta
object-
that
contains
all
the
necessary
information,
it
doesn't
matter
how
you
write
it
in,
but
it
all
kind
of
reads.
It
reads
into
this
thing:
why
would
it
be
so
hard
to
write
that
out
to
if
it's
file.
G
G
B
Apart
from
that,
I
think
all
the
meta,
all
this
sort
of
non-coordinate,
all
the
other
metadata
right
say,
say
all
the
wcs
metadata
information
is
like
you
know
it's
up
in
a
separate
space
like
wcs
right.
Everything
that's
left
is
if
it's
come
from,
fits
it's
effectively
a
dictionary
right,
yeah,
so.
C
C
B
I
guess
what
I
was
trying
to
lead
towards
was
that
you
only
support
writing
out
a
map
to
fits.
If
you
know
if
the
wcs
is
is
a
fixed
ucs,
in
which
case
it's
kind
of
like
the
infrastructure's
there
to
make
it
fits
without
that
much
trouble.
And
if
the
user
changes
that
well,
then
that's
you
know,
that's
you
know
you
got
to
know
what
you're
doing
sorry.
C
Yeah,
I
I
think
that's
true,
I
think
I
am
there
would
be
a
fit
serializer
which
takes
a
senpai
metadata
object.
It
looks
at
the
objects
that
that
metadata
object
contains
so
like
a
wcs
object.
It
looks
at
that.
The
type
of
that
wcs
object
and
goes
do
I
know
how
to
save
this
to
a
fit
header,
and
if
it
goes
no,
it
throws
an
error
going.
I
D
We're
at
the
hour
right
now
and
we
have
like
a
30
minute
break
in
the
schedule
before
we
start
the
ndq
2.0
discussion,
but
one
of
our
outcomes
or
that
we
wanted
was
decide
and
document
internal
structure
for
storing
maps
plus
metadata.
I
think-
maybe
I
don't.
I
guess
I
mean.
Obviously
we
have
focus
on
david's
student
slides,
but
maybe
we
should
think
about
kind
of
more
concretely
the
plans
for
implementation
in
the
next
session
about
how
this
would
work
and
turn.
C
D
J
H
B
I
B
C
F
H
Yeah
I
mean
as
a
concrete
example.
I
know
that
all
of
the
solar
orbiter
fixed
files
have
a
requirement
to
have
the
observer
position
in
a
set
of
different
coordinates
like
it's
a
requirement
when
we
make
the
fixed
files,
even
though
they
might
be
wrong.
In
fact,
it
should
all
be
there
so
yeah
I
mean
someone
might
be
relying
on
them
in
a
certain
coordinate
system
and
if
we
dump
them
out,
they
might
not
be
happy
and.
F
Of
course,
that's
a
that's
actually
a
tricky
one,
because
at
least
for
some
duration,
solar
orbiter
actually
has
the
wrong
chord
information
for
one
of
his
friends,
and
so
what
do?
What's
our
responsibility
for
preserving
that
or
like
creating
to
working
with
that?
Do
we
always
offer
it
up?
Do
we
just
strip
it
all
out
and
say
this?
Is
the
trusted
friend
it's
the
only
one
we're
going
to
put
out
kind
of,
like,
I
think,
laura
made
a
comment
about
like
preserving
only
the
metadata.
That's
like
that's
necessary
to
reinstantiate
the
map
class.
C
Two
comments
come
to
mind
immediately.
One
is
if
your
solar
orbiter-
and
you
want
to
save
your
observer,
coordinate
out
in
many
different
ways.
You
could
subclass
the
serializer
and
always
use
that
specific
instance
of
the
serializer
and
the
other
thing
is
like
to
me.
The
untrusted
unknown
metadata
thing
is
fine
to
be
carried
around
and
saved
back
out
again
until
you've
done
something
like
rotate,
in
which
case.
C
F
Well,
I
mean,
ideally,
I
would
say
every
instrument
team
should
be
saying
what
they
want,
somebody
to
be
spitting
out.
I
don't
like
what
you're
saying
about
subclass
and
be
serializer
right.
If
we
had
that
kind
of
engagement
for
every
single
instrument
source,
then
this
would
be
fine
right.
Every
every
team
gets
to
makes
his
own
decisions
about
what
does
the
safe
method
actually
preserve
problem
right
now
we
don't
have
that
level
of
engagement.
C
G
B
B
You
know
now
that
still
doesn't
fix
everything
because
you're
still
going
to
serialize
and
deserialize,
but
how
much
like
I
mean
unless
I
miss
integrity,
laura
you
told
me
like
right
trying
to
write
out
the
full
history
like
okay,
you
went
from
this
file,
I'm
going
to
tell
you
in
like
some
kind
of
like
comment
section.
This
is
how
we
got
to.
G
No,
I
mean
literally
just
having
like
this
was
written
out
using
some
like
mac
dot
save
so
that
people
are
aware.
It's
not
the
original
thought,
but
I
mean
people
should
be
aware
anyway,
just
by
reading
it,
but
I
mean
not,
I
mean
the
same
problem.
If
someone
could
read
in
a
fitzvah
at
the
moment,
change
all
the
metadata
and
write
it
out
and
it's
still
wrong
right.
It's
just
it's
up
to
the
user.
I
guess
to
be
aware
of:
what's
going
on.
E
B
A
H
D
C
H
B
I
kind
of
actually
I
kind
of
wrote
that
I
don't
know
why
I
didn't
sort
of
bring
this
up
earlier,
but
like
when
I
originally
sort
of
wrote
this.
I
had
in
mind
as
this
being
like,
like
a
sandbox
almost
for
something
that
might
be
applicable
more
broadly
in
senpai.
But
you
know
this
meta
abc
is
an
attempt
to
try
and
like
define
okay,
what
are
the
things?
What
are
the
tags
that
are
going
to
be
common
to?
Basically
everything?
B
Module
which
is
in
inside
the
instrument
sub
package,
there
is
a
spice
meta
data
that
inherits
from
one
of
these
abcs
and
inside
this
you've
just
got.
You
know
these
these
sort
of
hidden
methods
that
just
translate
from
you
know
the
fits
header
to
you
know
into
you
know
into
this
api,
and
so
you
access,
whereas
some
of
these
sorts
of
things
might
be
available
on
map
dot,
observer
or
map
dot
instrument.
In
this
case,
they're
available
on
you
know,
spectrogram.metadot
instrument.
B
C
D
B
And
what
this
means
is
that
you
have
you
have
a
generic
like
a
spectrogram
object
which
happens
to
have
a
spice
metadata
object,
so
everything
on
the
data
is
sort
of
generic
and
then
basically
everything
that
is
in
this
particular
example.
Everything
that
is
instrument
specific
is
on
the
metadata
object.
But
again
this
is
inherited
from
a
spectrograph
metadata
object.
So
you
have
this
subset
of
all
spectrograph
instruments
or
data
types.
We'll
want
these
keywords,
and
this
in
turn
inherits
from
you
know
this
remote
sensing
one.
B
So
you
end
up
like
cascading
from
the
most
general,
which
is
you
know
like
instrument,
for
example,
you
know
or
observer
location.
You
know
these
are,
like
you
know,
fairly
general.
You
can
argue
about
these
specific
ones,
but
you
know
the
principle.
Is
you
cascade
all
the
way
down
to,
like
you
know
the
most
specific
data
type
and
then
finally,
you
implement
that
in
an
instrument,
specific
version,
so
you
will
again
have
as
well
as
all
the
ones
you've
inherited.
You
can
create.
I'm
trying
to
think
yes
spice
observation
id.
B
This
is
clearly
not
an
inherited
one.
This
is
something
that
is
specific
to
a
spice
metadata
object,
so
you
can
end
up
having
the
data
type
is
generic,
but
attached
to
it
is
an
instrument
specific
or
source
specific,
or
you
know,
data
type,
specific
metadata
object
and
you
can
have
all
sorts
of
methods
and
things
attached
to
that
based
on
what
you
need,
but
it
separates
those
two.
The
data
and
the
metadata.
F
C
C
A
A
B
Because,
then,
you
end
up
having,
I
think,
you're
restricting
the
scope
of
the
problem
right
so
like.
If,
if
you
want
to,
you,
then
have
to
have
like
source
specific
data
objects
when
inherently
the
data
is
treated
all
the
same,
like
you
know,
it's
a
it's
a
numpy
array
or
a
dash
array
or
whatever
the
only
thing.
That's
different
from
instrument
to
instrument
in
this
example
is
just
how
you
sort
of
read
and
translate
and
handle
the
met
data.
B
F
Well,
I
will
say
that
you
know
not
that
sky
core
should
ever
be
the
model,
necessarily
how
you'd
ever
want
to
do
anything,
but
you
could
bring
the
attributes
up
right.
They
don't
have
to
be
literally
declared
on
the
ndq
class.
Whatever
your
metadata
class
has
and
the
properties
it
has
to
be
elevated
up,
so
you
can
actually
get.
D
Them
at
the
the
map
level
yeah
like
there's,
why
why
would
you
have
or
from
just
from
an
api
perspective?
That
seems
just
more
more
things
to
type
in
between
my
object
and
the
thing
that
I
want
everything.
Is
I'm
sticking
dot
meta
in
between
all
these
things
like
why?
Why
is
the
user?
Do?
I
need
to
know
explicitly
that
these
things
are
on
the
underlying
metadata
object,
instead
of
just
the
thing
that
I'm
using
because.
C
Facetious
answer
which
is
like
it,
I
think
it
allows
us
to
be
more
flexible
with
what
we
want
map
to
be
like
steve,
and
I
had
many
discussions
over
many
years
about
having
physical
type
based
maps.
So
you
have
a
different
map
for
a
magnetogram
than
you
have
for
an
intensity
gram
or
whatever,
and
I
think
if
you've
moved
the
metadata
properties
out
of
the
map
api,
it
gives
you
much
more
scope
for
customizing
the
map
api,
because
the
metadata
api
is
the
same.
D
C
Not
need
to
have
this
discussion
now
we
should.
This
is
like
not
even
an
implementation
question,
because,
as
albert
says,
we
can
implement
it
in
a
backwards
compatible
way
and
then
have
the
argument
afterwards.
So
we
are
so
far
away
from
having
to
make
a
decision
on
this
point
that
we
should
not
discuss
it
much
further.
I
don't
think.
I
C
Yeah,
I'm
keen,
I
will
say
that
I
posted
in
the
chat
is
lsst.
Have
a
version
of
these
deserializers,
which
I
looked
into
many
moons
ago,
and
I
think,
is
if
not
a
promising
dependency
is
a
promising
bit
of
inspiration
for
how
I
envisage
the
deserializers
working.
So
people
want
to
have
a
look
at
that.
It's
worth
looking
at.
B
Great
okay
yep,
so,
let's
like
we're
only
just
getting
started
with
all
this
fun,
so
yeah,
I'm
what
I'm
going
to
do
in
this
few
slides
I'm
going
to
give
a
rapidly
introduction
to
ndcube.
I
know
it
gets
talked
about
a
lot,
but
I
also
know
that
you
know
details
get
missed
and
things
can
be
confusing
so
I'll
very
quickly
reintroduce
this.
B
All
to
that
I'll
give
a
quick
update
on
where
2.0
is
at,
and
then
I
will
talk
about
mapping
map
to
ndq,
by
which
I
mean
you
know
what
are
the.
If
you
want
to
do
something
with
that
you're
used
to
doing
in
map.
How
would
you
do
it
with
nd
cube
and
then
I
just
want
to
throw
open
the
discussion
for
a
proposed
map
which
is
which
inherits
from
nd
cube.
C
Do
you
just
mind
me
butting
in
quickly,
of
course,
please
do
just
so
that
people
keep
it
in
their
mind.
What
I
had
envisaged
the
outcome
of
the
next
hour
and
40
minutes
being
is
general
agreement
on
the
content
on
the
contents
of
a
sep,
which
would
be
a
proposal
for
the
required
api
changes
to
map
to
make
this
work.
Well,
I'm
not
proposing
we
actually
write
it,
but
if
we're
all
vaguely
on
the
same
page
about
what
potential
api
changes
we're
looking
at
for
map
to
make
this
inheritance
work.
B
Thanks,
laura
okay,
all
right
so
very
quickly,
ndcube
the
package.
The
point
is
to
provide
a
standard
api
for
handling
generic
nd,
astro
and
solar
observations.
To
do
this,
it
provides
three
basic
data
classes,
ndq
being
the
fundamental
one,
which
is
for
basically
a
data
array
plus
wcs.
That's
all
you
need
ndcube
sequence,
which
is
for
basically
an
ordered
set
of
nd
cubes
and
then
also,
which
was
relatively
new,
is
nd
collection,
which
is
effectively
an
unordered
set
of
nd
cubes.
B
There
are
three
primary
sets
of
functionalities
that
this
provides.
All
of
these
are
agnostic
to
the
actual
physical,
the
actual
data
types,
but
you
know
a
very
common
and
I'm
going
to
use
over
and
over
again,
the
first
one
is
extracting
and
identifying
regions
of
interest.
So
this
is
done
through
slicing
indexing
and
cropping
to
inspect
and
quick
look
the
data.
B
So
you
know
we
have
visualization
tools
based
on
that
leverage,
the
wcs
and
the
data
array
and
then
also
mapping
array
elements
to
real
world
coordinates,
and
so
we
have
coordinate
transformations
that
heavily
lean
on
the
wcs
object,
and
the
hope
is
that
this
simplifies
and
speeds
up.
The
workflow
of
either
pipelines
or
of
you
know
people's
analysis
and
also
reduces
mistakes,
because
these
things
are
done
over
and
over
again,
if
we
just
rigorously
develop
them
in
one
place
and
everyone
else
uses
them,
you
know
we're
more
likely
to
do
things
faster
and
more
accurately.
B
So
just
what
exactly
is
an
ndq
object
here,
you
sort
of
see.
What's
inside,
we
have
sort
of
four
main
things
we
have
arrays,
which
you
see
in
blue.
We
have
coordinate
objects
that
you
see
in
red.
We
have
metadata
that
you
see
in
green
and
then
visualization
and
data
inspection
methods
that
are
there
in
yellow.
So
ndcube
has
a
data
array,
an
uncertainty
array
or
uncertainty
object
and
a
data
mask.
B
We
have
the
wcs
transformations
which
of
course,
we're
all
aware
of.
In
addition
to
just
wcs,
ndcube
has
two
other
coordinate
objects,
first
of
all
x
records
which
is
sort
of
serves
two
purposes
more
recently.
Firstly,
if
you
want
to
work
with
coordinates
that
are
like
arrays,
rather
than
you
know,
sort
of
continuous
functional
coordinate
systems
like
wcs.
B
If
you
really
want
arrays,
then
extra
chords
hopefully
provides
you
an
easier
way
of
internalizing
those
into
your
data,
object
and
slicing
them
and
all
the
rest
of
it,
but
also
as
of
nd
cube,
2.0
x
records
can
as
well
but
doesn't
have
to
be
represented
as
a
second
wcs,
and
so
you
know
we
can.
We
can
link
w
extra
chords
into
various
wcs
frameworks
if
we
want
to
so
the
third
coordinate
object.
There
is
global
chords.
This
is
envisioned
as
an
object
to
handle
scalar
coordinates
that
don't
correspond
to
any
particular
axis.
B
So
an
example
of
this
might
be.
If
you
have
a
2d
map,
you
have
a
timestamp,
you
know,
that's,
obviously
a
coordinate
in
real
world
in
you
know
some
real
world
space,
but
you
know
there's
no
third
time
axis,
so
it
doesn't
correspond
to
an
axis.
So
a
scalar
time
object
would
be
an
a
great
example
of
something
going
into
global
chords.
B
So
just
as
a
very
quick
example,
one
of
the
benefits
by
the
way
people
interrupt
if
I've
said
something,
that's
confusing
or
you
want
a
clarification,
but
just
just
as
a
very
quick
example
as
to
what
benefit
this
can
provide.
If
we
have
this
container
object
called
ndq,
which
has
all
these
things
together,
we
can
build
functionalities
that
handle
everything
in
a
logical
and
quick
way.
B
Yes,
so
this
comes
to
the
point
of
this
actually
comes
to
something
I
want
to
say
about
ndq
2.0,
and
that
is
the
main
motivation
was
the
adoption
of
the
astropy
wcs
api,
namely
814,
and
one
of
the
things
this
has
enabled
us
to
do
is
to
upstream
a
number
of
features.
One
of
them
is
slicing
wcs,
so
now
so
long
as
and
ndcube
requires
an
814,
compliant
wcs,
and
so
the
slicing
of
the
wss
object
is
actually
upstream
now
to
astropyte.
B
B
But
to
facilitate
this,
it
required
a
number
of
breaking
changes
for
ndcube,
and
so
this
has
what
this
is
what's
triggered:
2.0,
which
is
a
major
sort
of
root
and
branch
rewrite
which
is
api
breaking,
because
once
we
decided
that
we're
going
to
break
things,
it
gives
you
the
scope
to
look
at
the
lessons
learned
from
1.0
and
say
well
what
was
done
well,
what
was
done
badly?
What
made
sense
at
the
time
but
is
now
doesn't
make
sense,
because
the
world
has
moved
on
and.
B
Yes,
if,
by
fun
you
mean
putting
lots
and
lots
of
effort
in
and
the
goal
post
continually
moving
away
from
you,
but
it
is
kind
of
quite
exciting
when
you
see
the
extra
power
and
and
capability
that
sort
of
emerges
out
of
this
sort
of
complete
sort
of
reforging
of
the
of
this
package
and
of
the
basically
just
taking
the
lessons
learned
and
saying.
Well,
you
know,
let's
have
a
second
go
with
all
the
extra
knowledge
that
we've
built
up.
B
So
some
of
the
examples
I've
already
mentioned
that
one
about
slicing
wcs
objects,
ndcube,
is
now
agnostic.
It
doesn't
care
whether
it's
fits
or
dwcs
or
anything
else
so
long
as
it's
814
compliant.
It
just
doesn't
care.
The
changes
also
bring
the
api
into
line
with
814
in
certain
like
naming
conventions,
so
that
people
are
getting
already
very
used
to
the
814
api.
I
think,
and
so
changing
the
api
for
nd
cube
to
fit
in
with
that,
I
think,
is
probably
better
for
user
experience
and
yeah.
B
So,
very
briefly,
this
is
not
an
exhaustive
list
of
what's
new
in
ndq
2.0.
We
have
this
global
coord
class
that
I
mentioned
earlier
for
scalar
coordinates
that
don't
correspond
to
any
access.
I
think
this,
but
this
was
particularly
motivated
by
if
you
slice
out
an
axis,
like
you
say,
a
map
cube
and
you
slice
out.
B
B
We've
completely
changed
how
the
implementation
of
extra
coordinates
before
it
was
a
dictionary
of
dictionaries.
Now
it's
like
a
full-on
class,
and
this
has
allowed
us
to
do
a
number
of
things.
We
now
have
an
ndq
dot
combined
wcs
that
combines
all
the
extra
coordinates
with
the
the
the
wcs
information
into
a
single
wcs
object.
So
you
can
combine
them
if
you
want
to,
but
you
don't
have
to.
If
you
don't,
it's
also
allowed
us
to
unify
the
cropping
api.
Previously
we
had
crop
by
chords
and
crop
by
extra
chords.
B
We
use
high
level
data
objects
when
we're,
by
which
I
mean
things
like
sky
chords
and
time
objects,
so
that
is
more
in
line
with
814,
but
we
also
have
like
a
values
api,
for
example,
crop
by
values.
In
case
you
still
want
to
use
the
lower
level
objects
like
quantities,
so
we've
yeah,
like
I've
already
mentioned
this,
we've
brought
some
of
the
nomenclature
in
line
with
814.
We
use
sort
of
array
index
that
814
now
talks
about
world
pixel
and
array
index
where
basically
array
index
is
the
inverse
of
pixel.
B
Because
of
the
way
of
how
wcs
has
its
axis
inverted
relative
to
the
data,
so
this
is
all
just
making
it
if
this
doesn't
make
sense
to
you.
That's
fine
just
learn
a
new
way,
don't
worry
about
the
old
way,
but
it
is
sort
of
somewhat
breaking
if
you're
used
to
the
old
way,
and
then
we
also
have
improved
plugability,
I
think,
or
what
we
hope
is
improved
public
ability
for
the
visualization
suite
as
well
as
many
other
things
as
well.
B
B
Hopefully
it
does
or
if
it
doesn't
it's,
you
know
an
easy
fix
and
after
that,
it's
basically
documentation
to
to
make
it
easier
to
read
so
tidy
up
our
representation
strings
and
also
develop
some
docs
for
people
who
want
to
subplus
ndcube
and
just
give
them
a
helping
hand
in
how
to
do
that.
So
I
don't
know
how
long
it'll
take
in
time,
but
in
work.
It's
very
close.
I
think
so.
B
I
think
this
is
going
to
be
particularly
useful
for
map
if
we're
talking
about
rotate
or
like
differential
rotation,
or
anything
like
that
and
something
that
has
a
little
bit
of
work
done.
But
I
think
is
more
of
an
aspiration
at
this
point:
is
supporting
arithmetic
operations
so
potentially
adding
multiplying,
dividing
subtracting,
different
nd,
cubes
or
maps.
B
C
Yes,
the
what
that
pr
has
done
is
moved
the
implementation
of
visualization
onto
a
dot,
plotter
property
of
the
ndq
class
and
that
dot
prop
that
dot
plotter
object
now
has
all
of
the
visualization
code
on
it.
So
you
can
implement
extra
plotting
methods
or
on.plotter,
so
you
can
do
cube
dot,
plotter,
dot
draw
me
a
pikachu
and
or
you
can
go
actually
for
this
cube.
C
Matplotlib
isn't
the
best
thing
to
visualize
this
with
I'm
going
to
replace
it
with
pi
vista
and
assign
an
object
to
that
dot,
plotter
and
use
a
different
visualization
suite.
The
only
thing
that
still
exists
on
ndcube
is
dot
plot,
which
is
proxied
through
to
dot
plotter
dot
plot.
So
as
long
as
your
plotter
class
implements
a
default
plot,
the
ndq
dot,
plot
kind
of
d40,
quick,
look
function,
method
still
still
works
and
still
exists.
C
B
B
B
B
But
to
me
anyway,
map
does
a
number
of
things
from
a
user
point
of
view.
It
reads:
data
from
different
sources.
It
creates
this
metadata,
abstraction
layer
that
we've
been
talking
about
so
that
there's
a
reliable,
constant
api
for
getting
say,
observer,
coordinate
you
know,
irrespective
of
which
source
it
came
from
and
if
it
was
stored
in
slightly
different
keywords
or
whatever.
B
So
that's
that's
all
important.
Neither
of
those
things
I
think
is
really
within
the
scope
of
or
the
implement.
The
underlying
implementation
is
not
really
within
the
scope
of
ndq,
but
other
things
are
so
a
standard
data
access
api.
So
your
data,
for
example,
is
stored
in
dot
data
or
wcs
or
dot
meta.
B
So
yeah
that
that
will
make
it
very
easy
to
switch
over.
I
think
so.
Another
thing
is
visualization.
There
are
a
number
of
visually
like
plot
settings,
as
david
mentioned
earlier,
and
also
sort
of
the
dot
plot
method
or
the
dot
peak
method.
That
sort
of
allows
you
to
use
matplotlib
and
and
show
this
data.
B
So
why
do
we
want
to
rebase
or
why
are
we
proposing
to
rebase
map
onto
ndcube?
Well,
firstly,
ndq
provides
this
standard
api,
not
just
for
2d
images
but
potentially
for
all
or
most
sunpi
data
types.
I
think
one
one
of
the
burdens
or
one
of
the
the
barriers
to
creating
more
data
types
in
senpai
has
been
that
you
know.
B
Map
has
been
this
flagship
object
and
it's
clearly
very
useful,
but
has
taken
up
a
huge
amount
of
effort
and
work,
and
I
think
the
idea
of
starting
from
scratch,
with
a
different
data
type,
is
probably
off-putting
to
some
people.
In
fact,
it
would
be
to
me,
but
if
we
have
this
system
where
we
have
the
standard
api,
we
can
like
quickly
spin
up
other
data
objects.
B
Additionally,
ndq
provides
a
number
of
some
things
that
map
doesn't,
for
example,
slicing,
as
I
demonstrated
earlier.
As
far
as
I'm
aware,
map
only
allows
cropping
the
nomenclature
here.
I
I
kind
of
use
is
cropping
is
when
you're
defining
a
region
of
interest
based
on
real
world
coordinates
where
slicing
is,
is
using
the
more
array
index
way
of
going.
C
B
B
That
would
be
a
shift
in
mindset
from
people
who
are
trying
to
do
this
one,
this
type
of
operation,
so,
yes,
ndq,
can
also
easily
be
extended
to
higher
dimensions.
For
example,
there's!
No,
if
you
had,
if
you're,
basing
everything
in
ndcube
a
map
cube
where,
with
an
extra
time
dimension,
you
know
the
api
would
not
significantly
change.
It
should
be
intuitive
for
users
to
go
from
a
2d
map
to
a
3d
map
cube
and
that
ndcube
sort
of
provides
a
sort
of
agnostic
to
the
number
of
axes.
B
B
B
Okay,
so
just
I've
got
a
few
different
areas
here:
sort
of
explicitly
mapping
between
map
and
nd
cube.
The
first
category
is
data
access.
So
this
these
tables
just
show
what's
common
and
how
to
access
common
things.
So
your
data
array,
in
both
cases,
is
data.
Your
mask,
in
both
cases
it
dot
mask
you
can
access
wcs
information
via
wcs
and
metadata
is
documented.
I
B
B
B
In
addition
to
this,
I
guess
because
map
sort
of
was
always
assumed
to
be
two
spatial
dimensions
on
the
you
know
in
helio,
projective
or
some
kind
of
helio
coordinates.
I
don't
think
that
it
easily
gives
you
the
physical
types.
Maybe
you
have
to
dig
into
the
wcs
for
that,
whereas
ndq
provides
this
array
access,
physical
types-
and
this
gives
you
back
a
list
of
tuples
where
each
tuple
corresponds
to
an
axis
and
inside
the
tuple
is
a
string
of
types,
because
you
can
have
multiple
physical
types
corresponding
to
each
array.
B
Axis
so
that's
data
inspection
again.
Stop
me
if
there
any
questions
on
this,
I'm
flying
through
it
a
little
bit
quickly,
but
we
can
come
back
to
it.
If
people
think
about
a
question
later
so
plotting
yep,
you
can
do
mat
map
dot
plot
you
can
and
that
returns
an
access
image
object
exactly
the
same
way
you
can
do
ndcube.plot
and
this
returns
a
wcs
access
subplot.
So
it's
a
different
return
type,
but
from
the
ndq
version
it
is
quite
easy
to
extract
the
access
image
object
if
you
want
to
so
so.
B
Ndcube
does
not
prevent
you
from
doing
things.
The
way
that
they
were
done
on
map
there's
just
an
extra
step
required
now
to
expand
on
this,
as
stuart
mentioned
before.
The
implementation
of
this
is
actually
that
there's
an
ndq
dot
plotter,
which
has
all
the
various
sort
which
can
have
various
sorts
of
weird
and
wonderful
plotting
methods,
but
ndq
dot,
plot
just
defaults
to
the
plotter.plot
method.
B
So
as
it
stands,
you
could
argue
that
map
and
ndq
can
be
made
to
be
very,
very
similar
in
this
respect,
in
fact
default
to
being
very,
very
similar.
In
this
respect,
so
it
can
be
very
simple
to
change
over
or
we
can
completely
change
stuff.
If
we
want
to,
I
don't
know
what
the
status
of
map.peak
is,
but
there's
nothing
similar,
there's
nothing
similar
to
that
in
ndcube.
B
Likewise,
map
sort
of
carries
around
sort
of
plot
settings
so,
like
you
know
which
color
table
to
use,
because
it
knows
it's
ai,
171
or
whatever.
It
is
of
course
indie
cube
is
agnostic
to
all
that,
so
it
doesn't.
But
if
you
provide
that
information,
you
know
through
the
plotting,
you
know
as
like
keywords
or
whatever
to
plot,
then
you
can
still
make
an
indie
cube
dot,
look
exactly
like
a
map,
dot.
A
A
B
Yeah
more
issues,
more
activity,
that's
great,
okay
and
then
penultimately,
I
think
cropping.
If
we
want
to
extract-
as
we
kind
of
mentioned
this
before,
if
we
want
to
extract
a
region
of
interest
based
on
real
world
coordinates,
we
can
use
map.submac
with
almost
almost
exactly
the
same
api.
You
can
do
that
with
ndcube.crop
using
sky
cords
and
time
objects
and
all
the
rest
of
it.
If,
for
whatever
reason
you
don't
want
to
use
high
level
objects,
you
can
use
quantities
by
crop
by
values.
B
B
I
B
C
C
So
you
can't
do
like
numpy
fancy
indexing
index
with
an
array
of
booleans
right,
for
instance,
or
similar
yeah,
pick
out
a
random
pattern
of
pixels,
because
ndq
or
unlike
x,
array,
for
instance,
ndq
always
maintains
the
wcs
as
a
wcs
object.
So
you
can
only
perform
slicing
operations
on
the
queue
which
can
be
performed
on
the
wcs.
D
B
However,
there
are,
or
there
are
slash,
will
be
ways
to
not
to
get
around
that,
but
there's
sort
of
a
different
way
of
achieving
effectively
the
same
end.
So
if
you
want
every
nth
point
another
way
of
doing
that
is
to
just
mask
out
every
you
know
or
to
to
mask
the
array
but
unmask
every
nth
column
or
every
nth
row.
B
So
you
would
still
have
a
contiguous
data
array,
but
you
can
use
that
mask
then,
if
you
want
to
do
calculations
using
only
every
nth
column,
so
the
mask
can
help
you
can
help
you
do
that
if
you're
trying
to
do
calculations.
Another
then
way
of
doing
that
is,
if
you
wanted
to
change
the
dimensionality
or
like
you
wanted
every
nth
column.
B
B
B
Not
at
the
moment,
but
again
that
is
the
that
is
very
much
explicitly
one
of
the
motivations
for
the
like
the
reproject
and
re-sample
work
is
that's
happening
now,
so
no
not
now,
but
but
the
intention
is
that
you
will
be
able
to
do
that
cool
so
that
I
didn't
know
it's
something
else
that
map
map
does
right,
doesn't
it
it
has
or
had
super
pixel
yeah.
It
has.
B
Hazard
pixel
yeah,
so
that
is
something
that
is
not
yet
done,
but
but
that
that
should
be
and
will
be
okay.
So
what
does
a
map
based
on
ndcube
look
like
and
what
needs
to
be
done?
So
here
is
a
strategy
that
I
haven't
run
past
anybody
so
stuart
or
anyone
else
if
you've
got
some
pushback
or
some
other
ideas,
please.
This
is
where
the
discussion
starts.
B
So
my
thoughts
were
that
I
suppose
on
the
right
I'll
start
on
the
right
that
all
the
access
agnostic,
or
most
at
least
most
of
the
access
agnostic
functions,
can
be
provided
by
ndcube.
We've
seen
how
the
data
access
api
is
basically
the
same.
We've
seen
how
you
can
do,
although
the
api
is
slightly
different,
you
can
still
do
slicing
and
cropping
effectively
region
of
interest.
B
We've
got
coordinate
transformation,
support
for
you
know
our
pixel
grids.
We've
got
almost
the
same
and
some
additional
data
inspection
methods
and
there
is
a
default
visualization
suite
that
maybe
is
good
enough
for
map
in
the
future.
As
we've
mentioned,
reprojection
resampling
super
pixel.
Those
things
are
related,
that's
being
worked
on
at
the
moment,
and
then
I
don't
think
map
supports
any
kind
of
arithmetic
operations
between
maps,
but
in
the
longer
term
future.
That
is
something
that
would
be
good.
I
think
that
that
ndq
would
like
to
support.
B
B
B
B
I
think,
given
nd
cube
setup
makes
a
lot
of
sense,
but
isn't
the
only
way
or
isn't
required
as
well
as
that,
some
solar,
specific
analysis
tools,
like
differentially
rotating
your
image,
that
would
rely
on
the
underlying
reprojection,
implement
infrastructure
of
ndcube
and
then
also
potentially
visualization.
If,
if
map
wants
some
more
specific
visualization
tools
for
images
or
for
2d
images,
there's
nothing
stopping
map
saying
because
we
know
we
have
this
image
type
or
this
this
data
type.
B
B
C
Planning
on
taking
that
as
gospel,
because
everybody
has
had
a
very
long
time
to
contra
comment
on
it
and
nobody
has
in
a
significant
amount
of
time.
So
I
am
expecting
that
the
nd
cube
scp
is
merged,
as
is
if
people
have
opinions
on
the
shape
of
the
nd
cube.
Api
now
is
very
likely
your
last
chance
to
go
and
review
this
pr.
B
C
We
can
kind
of
hit
off
this
discussion
with
a
few
things
that
I
noted
down
during
danny's
talk,
which
is
some
two
obviously
senpai
could
inherit
nd
cube
pretty
much
as
is
override
everything
that
we
don't
want
and
maintain
the
api
almost
exactly
as
it
is
at
the
moment.
Some
of
that
would
be
stupid.
We
would
have
a
sub
map
method
and
a
crop
method
at
the
same
time,
doing
the
same
things
in
different
ways,
and
that
is
silly.
So
the
first
thing
that
is
on
the
chopping
block
is
sub
map.
C
B
Oh
great
yeah
just
want
to
double
check.
Also.
I
just
wanted
to
on
a
very
brief
tangent,
although
we
are
talking
before
we
get
too
in
the
weeds
about
map
implementation,
I
saw
matt
was
on
the
call
earlier
sounded
like
craig
gave
in
a
question.
If
there
are
things
coming
out
of
this,
that
you
would
like
to
give
some
extra
context
for
your
needs.
I
think,
having
in
the
back
of
our
minds
that
you
know,
potentially
a
map
object
based
on
nd
cube,
you
know,
could
have
you
know.
B
K
Hi
danny
this
is
matt
here.
I've
got
a
bunch
of
questions,
but
just
to
respond
to
that
one,
it's
actually
wondering
if
it
would
actually
be
constructed
to
have
a
kind
of
side.
Meeting
with
you
guys
where
we
can
actually
specifically
discuss
punches
needs
to
see
if
you
think
it
actually
kind
of
fits
in
with
how
you
see
ndcube
going
I'd,
be
really.
B
Okay,
well
yeah.
I
think
we're
kind
of
like
merging
into
that
q
a
at
the
moment,
but
I
think
it's
it's.
I
think
it's
fair
that
stuart
continues
with
his
list
and
let's
come
back
to
to
matt's
list.
I
think
that's
probably
the
way
to
go.
Do
you
think
that's
that
sounds
reasonable
sounds
good
for
me,
but
I'm
gonna
be
on
mute.
I've
got
noisy
neighbors
at
the
moment,
so.
B
G
G
D
C
C
Nd
cube
returns,
the
axes
objects,
whereas
map.plot
returns.
The
axis
image
object,
which
is
the
difference
between
the
axes
and
the
output
of
the
I
am
show
call
I
at
matplotlib,
I
am
show
returns
an
axis
image
object,
whereas
map
ndq
currently
returns
the
axes
yeah.
I
so
that's
one
thing
to
bear
in
mind,
but
I
think
there
is
a
bigger
discussion
here
about
visualization
in
general.
B
C
D
D
My
objection
previously
is
that
I
still
think
you
should
have
that
dot
plot,
alias
to
make
a
plot
you
should.
I
shouldn't,
have
to
go
dot,
plotter
dot
plot.
If
I
want
to
do
more,
complicated
stuff
sure
it's
fine
to
kind
of
be
aware
of
this
of
this
separation,
but
I
I
think,
having
a
dot
plot
method
that
returns
me,
a
picture
of
my
data
in
some
sort
of
representation
is
still
is
still
a
valuable
thing.
D
F
D
F
D
But
that's,
as
I
said,
that's
my
objection
is
that
because
I
mean
we
talked
about
this,
the
last
coordination,
meaning
is
that
the
people
confuse
peak
and
plot
and
don't
and
don't
really
understand
because
they
use
peak
and
they
get
out
at
a
thing.
Then
they
don't
realize
there's
a
plot
method
as
well,
whereas
you
know
something
like
like
the
quick
look
method
gives
you
something
completely
different.
D
B
B
D
I,
but
I
think,
like
the
map,
you
know
the.
I
guess,
if
we're,
if
we're
moving,
all
of
our
the
kind
of
plot
functionality,
that's
in
map
over
onto
like
a
a
map,
plot
lib,
plotting
mix
and
I'm
using
the
right
words
here,
then
that
should
still
give
you
the
same
kind
of
capabilities
that
we're
providing
users
now
on
dot
plot
and
all
that
to
make
like
the
papers.
The
figures
you
want
for
your
paper
to
say.
B
C
C
Dot
plot
could
call
that
I
I'd
have
to
have
a
look
at
the
code
to
really
crystallize
this
idea
in
my
head,
but
we
could
break
up
plot
plot.
Does
a
bunch
of
things
with
like
setting
a
title
and
stuff
at
the
moment
we
could
move
some
of
that
stuff
out.
We
could
have
a
version
of
the
method
without
that
stuff
and
call
it
something
else
like
I
am
show
and
then
have
the
main
plot
method.
C
Combine
it
all
back
together
again
or
something
so
that
if
you
want
to
build
up
a
plot
more
by
hand,
map
provides
you
some
useful
utilities
to
do
that
in
stages
rather
than
having
to
do
what
you
do
at
the
moment
is
your
call.plot
map
does
a
whole
bunch
of
stuff
for
you,
and
then
you
have
to
back
some
of
it
back
out.
I
mean
like.
C
J
G
Oh
sorry,
I'm
going
to
say
that's
a
good
point,
because
I
think
even
a
lot
of
people
aren't
aware
that
what
that
plot
is
doing
is
doing
an
imp,
show
and
they're
like
confused,
then
about
what
the
hell
is
going
on,
and
they
don't
know
how
to
interact
with
us
and
that
would
be
nice
to
have.
I
guess
another
fun
question
is
like:
would
you
only
alias
dot
plus
and
then
keep
like
draw
a
limb
and
everything
has
like
dot
plotted
after
all
in
or
where
does
it
draw?
The
line
on
that?
I.
F
C
F
B
I
F
C
I
can
kind
of
go
either
way
on
that
one
at
the
moment,
because
it
would
be
very
easy
to
change
it
for
map
with
a
map
specific
plotter
object,
but
if
we're
also,
then
breaking
up
plot
into
a
bunch
of
component
methods
on
the
plotter
having
plot
return
the
axes
and
having
the
ability
to
like
do
an
im
show
to
get
the
axes
image
back
out,
it's
cool,
so
it
could
be
an
argument.
The
other
way
around.
F
F
Let's
just
say
that,
just
in
the
past
day,
I've
written
a
bunch
of
code
where
I
use
you
know
like
a
dataframe.plot
and
it
spits
back
the
thing
or
dataframe.his,
and
I
can
just
directly
just
work
with
that.
It's
not
like
I'm
not
working
the
axis,
I'm
working
with
the
thing
that
was
plotted
right
in
case
the
item
shows
a
little
bit
weirder,
but
certainly,
if
you
talk
about
like
draw
limbs
or
rectangles,
those
should
not
be
returning
axes.
F
That
should
be
returning
the
actual
thing
that
gets
added
to
your
to
your
to
your
whatever
you're
doing
so
yeah.
No,
I
agree.
It's
not
phosphorous
possible
like
that,
the
whole
thing,
or
is
it
supposed
to
be
like
how
we
use
it?
Also
in
some
of
these
things,
where
it's
like
you
know,
especially
in
the
world
of
auto,
align
and
some
of
the
stuff
that
we're
doing
on
the
map
side
like
it's,
not
it's
really
about.
Just
like
saying
you
know
we
want
to
over
plot
something
on
this
existing
plot.
F
C
D
I
was
gonna
say
I
think,
the
most
useful
thing
that
at
least
in
my
experience
that
the
most
useful
thing
that
plot
does
it
sets
up
the
you
know
the
wcs
axis,
based
on
whatever
your
whatever
projection
your
image
is
in,
and
then
you
want.
I
mean
most
of
the
time
if
you
want
to
get
into
like
the
nitty-gritty
details
of
adjusting
your
plot,
you
want
to
be
using
the
wcs
axis
api
and
all
almost
all
those
operations
are
done
on
the
axes.
D
C
B
F
Access
image
objects,
that's
unnecessarily
confusing.
I
mean
in
the
context
of
like,
if
you
think,
about
line,
plotting
and
matplotlib
right,
you
do
a
dot
plot
command.
It
returns.
That
line
doesn't
return
the
axis
that
the
line
lives
in,
and
so
when
you
do
multiple
of
those
calls
and
you
assign
them
to
different
variables.
You
can
know
you
have
a
variable
for
whichever
line
for
each
line
or
whatever
you
want
to
do,
and
you
can
just
modify
that
line.
You
want
to
change
the
drawing
style
for
that
line.
You
already
have
that
object.
F
C
A
C
Yeah,
basically
now,
basically,
the
question
is,
is
do
we
burn
is
do
we
burn
peak
and
tur
and
then
accept
that
plot
is
actually
quite
similar
to
peak
in
what
it's
doing
at
the
moment,
and
maybe
this
is
not
a
question
we
need
to
ask
answer
now
it
doesn't
matter
just
something
to
think
about.
Like
is,
is
I
quite
the
more
I
think
about
it?
I
quite
like
this
idea
of
blake
breaking
plot
up
into
a
bunch
of
component
parts
and
if.
C
D
Well,
I
guess
maybe
this
is
a
dumb
question
and
maybe
we've
already
touched
on
this,
but
I
mean
what
do
in
the
context
of
map,
not
in
the
larger
context
of
ndq.
It's
like
what
what
like
in
the
most
basic
perspective
like.
What
do
we
want
plot
to
do
that
we
you
you
couldn't
just
do
easily
with
matpotlib
show.
D
G
I
I
think
what
you
you
can
already
set
it
like
for
me
personally
from
use
is
the
fact
that
it
sets
up
the
wcs
axis,
and
then
you
can
do
everything
on
that
and,
like
I
think,
even
that
planet
is
at
the
moment
like,
even
though
it
does
have
when
you
just
do
that
it
has
instrument
specific
things
they're,
just
in
the
plot
settings
that
you
can
easily
change.
So
I
guess
having
that
like.
G
B
So,
just
to
clarify
this
pretty
much,
all
this
discussion
is
not
is
talking
about
like
overriding.
What's
an
nd
cube,
it's
not
like
this
question,
which
is
like
you
know.
Are
we
talking
about
changing
fundamentally
what
the
ndq
defaults
we're
talking
about
this
part
right
where
we're
like
adapting
a
new
like
map,
visualization.
F
C
It
kind
of
it
the
it
depends
on
the
dimensionality
of
the
cube,
which
maybe
now
we've
done
the
dot
plotter
thing
we
should
actually
consider
changing,
but
I'm
probably
not
going
to
that
for
2-0.
But
if,
if
you're
plotting
a
2d
cube,
plot
behaves
quite
similar
to
map
stop
plot.
If
you're
not
plotting
a
2d
cube
plot
on
nd
cube
doesn't
behave
similar
to
map
stop
plot
at
all,
because
it
has
to
return
an
animator
that
can
scrub
through
the
extra
dimensions.
E
E
B
It's
like
quick
look.
It's
like
quick
look
like
represent
all
of
my
data
in
this
cube
in
a
in
the
way.
That
makes
most
sense.
I
don't
care,
just
show
it
to
me
sort
of
way,
but
in
which
case
it's
got
to
it's
got
to
inspect
itself
understandable.
How?
How
should
I
show
this
and
then
build
it
all
up
and
give
it
back
to
you?
It's.
F
F
Well,
I
mean,
but
so
then
I
would
argue
that
you
know
if
in
the
world,
where
you're
talking
about
having
these
underlying
plotting
things,
which
is
like
specifically
for
like
a
2d
map,
the
plotting,
you
know,
I
am
show,
and
I
would
push
backing
us
calling.
I
am
sure,
because
I
want
p
color,
yeah
yeah
yeah.
F
Right,
a
more
raw
2d,
plotting
method
and
then
a
higher
level
dot
plot.
If
that
purpose
of
higher
dot
level
dot
plot
is
kind
of
like
how
you've
been
using
map.p,
then
it
shouldn't
return
anything
the
lower
level
plotter
would
return
the
the
axis
image
or
the
p
color
mesh
or
the
contours
or
whatever.
It
is
no.
B
C
C
C
C
C
C
B
C
B
Isn't
it
if
you're
using
a
native
nd
cube?
Yes,
there
is
to
pivot
to
albert
hypercube.
You
could
potentially
create
a
new
data
class
that
every
time
it
slices
it
checks
the
physical
axes
and
then
instance.
It
uses
that
information
to
instantiate
a
map
or
a
time
series
object
or
whatever.
But
if
you're
using
native
nd
cube,
then
that's
correct.
It's
still
an
nd
cube,
yeah.
H
I
mean
that's
kind
of
what
I
was
getting
to.
Obviously
it's
not
what
we're
talking
about
now,
but
it
just.
It
seems
weird
that
you
would
do
that
and
that
you
get
like
an
object.
But
then
you
create
a
similar
object
from
similar
data
and
you
get
a
time
series
even
though
they're
identical
representations
of
data.
I
C
G
I
C
G
B
B
C
H
B
D
I
would
say
I
think
the
question
is
I
mean
now
that
we're
expanding
map
to
effectively
more
than
two-dimensional
images.
It's
like
what
is
the
scope
of
math
now
right,
I
think,
and
how
like,
where
does
that
fit
into
the
larger
scope
of
of
ndq,
like
what
I
mean
to
first
order?
I
realize
that
we
just
want
to
replace
map
with
ndcube.
D
Like
that's,
you
know,
and
not
necessarily
think
about
that,
but
I
think
that
is
a
larger
thing
that
we
have
to
think
about
at
some
point,
it's
like:
where
does
the
map
api
previously
just
like?
Well
anything,
that's
not
a
2d
image
is
not
a
map,
you
know,
or
it's
not
going
to
fit
into
the
map
map
api,
but
now
I
I
don't
know.
C
D
C
There
is
spectral
cube,
there
is
spectrum
1d,
there
is
various
other
things
and
they
all
make
an
assumption
that
I
have
an
nd
data
object,
which
is:
has
this
specific
set
of
spectral
axis
types
and
sometimes
that's
useful?
You
can
make
logical
assumptions
and
you
can
make
apis
which
people
find
easier
to
interact
with,
because
you're
a
shoot
you're
making
that
assumption
so,
for
instance,
spoke
from
1d
has
a
dot
flux
attribute,
which
is
returns,
the
wavelength
axis
or
no
returns
the
data
right,
because
it's.
D
D
You
know
cube
or
map
sequence.
I
guess
is
what
we
call
it
now,
but
I
mean
our
like
is
is
representing
like
like
in
taking
your
your
iris
example.
It
is
representing
iris
data,
as
a
map
ever
going
to
be
is
like.
Is
that
in
the
scope
of
math,
or
not
now
that
now
that
it's
based
on
an
object
that
can
handle
n-dimensional
data.
D
Should
it
right
like
what
I
guess,
what
I?
What
is
the
scope
of
map
in
terms
of
types
or
it's
really
in
terms
of
data
dimensionality,
I
don't
really
care
as
much
about
data
type,
but
about
you
know
whether
that
2d
image
represents
flux
or
counts
or
whatever
the
hell.
You
want
to
call
it
like
it's
it's
more
about
like
yeah.
What
what
sorts
of
dimensionality
do
we
want
to
support
in
map.
B
You
know,
and
then
you
know
you
inherently
you
you
deal
with
your
data
generically
and
you
know
if
you
know
you
need
a
dot
flux.
That's
a
bad
example,
because
it's
a
coordinate,
but
you
know
you
know
metadata.
Then
you
have
the
specific
metadata
objects
that
handle.
You
know
the
needs
of
specific
combinations
of.
C
Having
but
if
once
we've
got
map
rebased
on
nd
data
and
done
all
the
metadata
stuff,
we
spoke
about
and
implemented
reproject
and
free
sample
in
ndq
and
a
few
other
things.
Then
we
should
probably
have
this
discussion
then,
because
long
term
can
I
see
us
dropping
map
in
favor
of
a
solar,
specific
nd
cube
object
that
has
a
has
a
celestial
component.
E
H
C
D
Oh,
I
was
just
going
to
say
before
we
jumped
into
the
more
I
guess
general
indie
cube
discussion.
Did
we
do
we
have
sort
of
more
concrete
things
that
could
go
into
an
scp?
I
know
that's
what
we
said
we
wanted
to
kind
of
accomplish
at
the
at
the
end
of
this.
I
mean
this
slide
that
you're,
showing
here
I
think,
sort
of
encapsulates
some
some
of
those
thoughts
and
maybe
some
of
the
things
from
the
notes.
C
C
C
G
G
No,
but
it
would
say
if
the
fitzfar
can
read
it
in
and
you
have
you
could
read
in
your
bits
file.
It
gives
you
a
data
and
a
header,
and
you
could
pass
those
data
and
headed
to
an
nd
cube
and
it
would
give
you
an
ndq
back.
But
if
you
try
to
pass
that
to
map
it
says
sorry,
we
don't
support
that
at
the
moment
and
of
just
takes
the
first
image.
B
I
think
the
one
thing,
the
reason
I
sort
of
made
that
comment
was
just
to
stress
to
get
away
from
the
idea
of
fits
files.
I
mean
map
was
inherently
sort
of
designed.
Oh,
we
have
these
fixed
files,
but
ndq
is
not
ndq.
Give
me
an
array
and
a
wcs
object
in
a
meta
like
dictionary
or
a
meta
object.
I
don't
care.
Nor
do
I
want
to
know
if
they
come
from,
I
don't
want
to
fix
header
objects.
I
don't
care
where
it
comes
from.
Just
you
know,
that's
that's
the
scope
of
ndq.
G
C
G
C
C
B
K
C
K
K
C
C
That
is
broken,
because
we
have
a
method
that
passes
off
to
reproject,
that
does
actual
math
maths
on
the
data
and
therefore
has
to
have
it
in
memory,
but
the
short
it
delegates
that
to
the
array,
implementation
underneath.
So
if
you
are
working
with
a
data
set
which
is
larger
than
memory,
I
would
recommend
you
put
your
array
in
a
dark
array
instead
of
a
numpy
array
that
allows
you
to
do
lazy
loading
of
the
memory
and.
C
B
K
B
Well,
first
of
all,
as
is
the
sim,
the
the
most
basic
form
of
astro
pi
nd
data
is
a
really
like
it's
just
a
container
class,
and
it
does
very
very
little.
There
are
various
different
mix-ins
that
you
can
add
or
not
add
at
the
moment,
like
ndq
by
default,
includes
the
arithmetic
mix
in
but
again
that's
not
a
requirement,
so
the
ver,
the
most
basic
form
of
that
is
very,
very
stable
and
not
changing
and
is
very,
very
light.
B
B
So
I
think
the
reason
I
tell
that
story
is
because,
if
nd
at
the
moment,
the
most
likely
way
nd
data
is
going
to
be
massively
disrupted
is
by
becoming
in
the
cube
or
something
very
like
it.
So
it's
probably
going
to
merge
closer.
You
know
it's,
it's
not
it's
going
to.
If
it'll
change
it'll
change
more
closely
to
what
you
want,
if
you
want
ndq
not
further
away.
H
C
B
That's
actually
been
a
lot
of
a
lot
of
what
well
yeah
over
the
course
of
this,
particularly
with
2.0
is,
is
a
number
of
things
that
originally
developed
for
in
ndq.
Stuart
has
upstreamed
astropy
or
has
motivated
other
people
to
develop
something
that,
if
that
recreates,
you
know
what
we're
doing
in
ndq,
but
better.
B
K
B
C
So
I
will
say
that
while
ndcube
itself
doesn't
yet
have
us
any
decent,
serialization
implementation,
there's
nothing
stopping
you
serializing
the
component
paths,
an
nd
cube
is
made
up
of
a
data
and
metadata
a
wcs
and
a
couple
of
other
things.
That
list
is
finite
and
well
defined.
You
can
just
save
those
out
to
whatever
file
you
fancy,
saving
them
out
and
then
reconstruct
a
cube
on
read
so,
okay.
C
D
B
An
ndq
doesn't
make
any
of
those
assumptions,
but
if
you
are
dealing
with
punch
data-
and
you
know
you
not
even
assume
you
know
certain
things
about
the
data,
then
you
can
constrain
that
problem
to
something
more
specific,
which
you
know
is
not
within
the
remit
of
ndq,
because
it's
no
longer
really
general,
but
you
know
suddenly
now
becomes
an
incredibly
solvable
problem,
so
you
can,
as
stuart
said,
basically
come
up
with
your
own.
Save
method
not
met
a
save
function.
K
I
C
Such
is
life
the,
however,
the
814
wcs
specification
is
cartesian,
ordered
for
both
the
world
and
pixel
sides
of
that
transformation
right.
A
wcs
is
an
arbitrary
transformation
between
a
pixel
coordinate
and
a
world
coordinate,
and
the
wcs
transformation
keeps
has
both
of
those
in
cartesian
order.
Okay,
great.
B
So
the
just
just
to
sort
of
elaborate
on
something
we're
saying
earlier,
which
is
relevant
here,
is
since
814
the
nomenclature.
There
are
three
main
terms,
I
suppose
so.
There's
world
world
order
say
you
know
which
we've
discussed
before
there's
pixel
pixel
order,
which
is
again
the
both
of
those
are
cartesian
and
then
there's
array
order,
and
that
is
that
is
sort
of
row
major
and
the
same
as
c
and
python.
B
B
B
K
K
K
It's
not
completely
clear.
We
are
going
to
have
the
order
for
our
remember
the
primary
data
array,
which
is
going
to
be
kind
of
standard
data
array,
and
then
we
will
have
in
the
hdu1
we
will
just
have.
We
will
conform
to
fit
standards
and
then
in
the
secondary
hdu.
That's
where
we're
going
to
put
stuff.
What's
what
we're
envisaging,
where
we're
going
to
put
stuff,
which
is
non-standard,
I'm
not
sure
the
final
data
sizes.
But
the
question
is:
is
there
a
way
to
kind
of
carry
that
information
within
the
data.
B
K
B
We're
always
going
to
say,
or
something
completely
like
custom
built,
that's
a
class
of
it's
in
its
own
right.
You
know,
and
you
can
store
any
data
that
you
like
in
there
ndcube
like
itself,
does
nothing
to
it.
It
carries
it
around
and
just
you
know
leaves
it
there
for
you.
So
that's
one
option,
so
you've
got
any
degree
of
option.
If
it's
like
a
secondary
data
array,
that's
not
uncertainty
or
mask,
then
I
think
I
think
in
that
case.
B
B
You
probably
know,
no,
I
don't
I
don't.
I
don't
think
so.
I
think
it
can
have
like
it
doesn't
even
have
to
have
any
axes
aligned,
it
can
have
axes,
aligned
it's
an
option,
but
none
of
the
axes
have
to
be
one
or
some
or
none
of
the
axes
can
be
aligned.
I
need
to
go
back
and
check
exactly
what
the
limitations
on
it
are.
I
suspect,
maybe
the
dimensionality
there
might
be
some.
I
need
to
double
check.
It's
been
a
while
since,
since
I
wrote
it
now,.
K
B
That's
kind
of
what
we
want
and
just
to
reiterate
what
I
said
earlier
is
the
use
of
extra
chords.
It
was
originally
a
motivated
big.
You
know
so
that
you
can
basically
do
what
x-ray
does
and
have
like
arrays
of
coordinates,
but
now
I
think
it
actually
can
serve
a
separate
feature,
which
is
you
can
have
two
sets
of
coordinate
transformations.
K
Maybe
not
this
actually
kind
of
like
feeds
into
what
was
my
final
question.
If
you
don't
mind
we're
forming
this
over
sure,
and
that
was
you
discussed
earlier
about
the
map
object,
which,
I
must
say,
I've
never
really
kind
of
used.
The
map
object
before
I
normally
gank
out
the
array
and
manipulate
it.