[Dachs-support] SODA error with 3d data

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Thu Mar 30 09:23:44 CEST 2023


Ixaka,

On Wed, Mar 29, 2023 at 04:18:12PM +0200, Ixaka Labadie wrote:
> Sorry, I don't know if I'm not making myself clear or I don't understand
> well your answer. The thing is that I don't use fits_makeBANDMeta, so no
> BAND parameter. As I see it, fits_makeWCSParams creates with
> soda.iterOtherAxisKeys() the parameters or slices to make the cutout; this
> function doesn't discern between any unit or type of axis except RA and DEC
> axes. Then, fits_doWCSCutout makes the cutout taking those parameters into
> account. Is this correct?

Ah!  I had totally forgotten about the automatic cutouts on the extra
axes.  Thanks for setting my head right.

And yes, that's still broken in the current beta with negative CDELT,
but it'll be fixed in the next beta.  But now that I revisit this I
notice that in the typical case (i.e., a spectral or velocity cube
with explicit, separable axes), iterOtherAxisKeys overgenerates,
i.e., produces extra parameters that just clutter the interface.  The
non-spatial cutout should use the conventional BAND or VELOCITY
parameters, not some autogenerated thing.

On re-thinking, I now feel this autogeneration in general is
undesirable.  Also, I suspect there's no service I'd actually break
if I change the behaviour now, so unless someone protests, I'll
change //soda#fits_makeWCSParams in DaCHS 2.8 to only produce spatial
WCS parameters by default.  If you want auto-generated cutouts on
other axes, you have to pass these in axisMetaOverrides.

Protests?

The alternative would be to pass a blacklist of FITS axis indexes for
which automatic cutout parameters should be suppressed into
fits_makeWCSParams.  That would work fine and not change the current
behaviour -- but since I now consider the current behaviour broken
(which I just happened to not notice because all cubes I publish are
either weird or have slightly wonky (i.e., inseparable) WCS headers),
that would clearly be my second choice.

> As you said, I also thought there was a problem with the negative CDELT3 in
> the procedure I just described. I will try your instructions in the
> following days and comment the outcome.

Ok -- I'll wait for your feedback and then do whatever change to
fits_makesWCSParams seems wise by then.  After that, I'll do another
beta which then ought to remove the extra cutout parameter you will
still see for the velocity axis.

Thanks,

           Markus


More information about the Dachs-support mailing list