FWIW, it would make more sense if the units of each slice were Jy/beam/(km/s), because then integrating along that axis would truly be integrating a spectrum, but I've never seen radio people treat it that way. On Jul 7, 2014, at 11:50 AM, John ZuHone wrote:

Nathan,

At the moment we've left the units of all of the axes in code_length, which is equivalent to the FITS pixel (except in cases where the z-axis is rescaled, in which case along that axis it is a multiple of the pixel).

For these datasets, I actually don't think that projections with a path length (whether in terms of length or velocity) makes a lot of sense--since the units along each slice are Jy/beam and the total projected intensity is in the same units. That's why for this image, when we used it in this notebook:

http://yt-project.org/docs/dev-3.0/cookbook/fits_radio_cubes.html#radio-cube...

we specified proj_style="sum" which eliminates the path length and simply sums everything along this axis.

Best,

John

On Jul 7, 2014, at 11:43 AM, Nathan Goldbaum wrote:

...

Hi all,

I think this question is primarily for John ZuHone, but please feel free to jump in.

I'm currently looking at the FITS frontend for my scipy talk.

I just made a projection of the M33 HI data cube we have on the data hub. The image is here: http://i.imgur.com/kcw98g8.png

I know that we decided to not try to jam WCS axes into the PlotWindow code, instead reserving that for PlotWindowWCS. I agree with that.

However, I'm confused about the units of the z-axis. Presumably, the units of the actual observation are km/s. Did we ever investigate making the units of the z-axis km/s? Is that not possible at the moment due to a restriction that all three axes must have spatial units?

Thanks for your advice,

Nathan _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org