tmolteno / disko

Discrete Sky Operator (DiSkO) Aperture Synthesis Radio Imaging
GNU General Public License v3.0
2 stars 2 forks source link

Disko overplotting coordinate system does not work for anything other than Zenith projection #7

Open bennahugo opened 1 year ago

bennahugo commented 1 year ago

It looks like the coordinate system is not using WCS to work out where on the sphere to place things. The GNSS plots has no respect for PHASE_DIR Not phase steered, single field ms: image Phase steered, single field ms: image

bennahugo commented 1 year ago

Ok this one is much more involved looking at the code because it assumes things can be rotated to where they should be in spherical coordinates. I think I'm not actually going to fix this right now - it will take quite a bit of work.

tmolteno commented 1 year ago

I think the solution here is to re-architect the sphere object, and for it to be able to manage it's own co-ordinate transformations from elaz to celestial in particular. I'll add an issue to address this

bennahugo commented 1 year ago

Thanks. It is a bit beyond what I have time for now, but it will be useful for longer observations, seeing that all standard imagers produce a fits file which will really need to be converted to healpix to be viewed properly - the stretching on a planar view is well beyond what standard WCS views are designed to do TBH - all projections break down at this level which is why ds9 and others don't work well.

We currently read into the source table Ra Dec coords (as it should be - the images are all constructed Ra Dec) inside tart2ms. If and when we use this in Disko the sphere will have to understand Ra Dec properly in order to display. The cutoffs etc will need to be Ra Dec.

I thought about an alternative in that we rephase the visibilities back to zenith on the fly - then all will be well. However then that also means disko cannot be used for long integrations unless we only do it when you overplot. It is a bit weird though in terms of mode switching.

Let's discuss.

On Wed, 26 Oct 2022, 04:42 Tim Molteno, @.***> wrote:

I think the solution here is to re-architect the sphere object, and for it to be able to manage it's own co-ordinate transformations from elaz to celestial in particular. I'll add an issue to address this

— Reply to this email directly, view it on GitHub https://github.com/tmolteno/disko/issues/7#issuecomment-1291420792, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4RE6S56Y4QR4OSKXNP4HTWFCLADANCNFSM6AAAAAAROEDF7Y . You are receiving this because you authored the thread.Message ID: @.***>

tmolteno commented 1 year ago

As discussed, the plan is to move drawing code out of disko completely and create a utility specifically for doing this. I'll track this in Issue #10.