-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disko overplotting coordinate system does not work for anything other than Zenith projection #7
Comments
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. |
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 |
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
<#7 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4RE6S56Y4QR4OSKXNP4HTWFCLADANCNFSM6AAAAAAROEDF7Y>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
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. |
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:
Phase steered, single field ms:
The text was updated successfully, but these errors were encountered: