Ability to define source extraction radius in units of deg

[ajstewart]

I've come across a situation where I have one particular (deep) image of a field that has been imaged at a better resolution than that of other snapshots in the dataset. This means that when the source extraction radius is defined in pixels, the regions of sky the TraP extracts from do not match.

Of course running the cross matching on images with different resolutions is not ideal but I still think it would be useful if this issue was avoided by being able to define the extraction radius in units of degrees. I know in FITS files at least you just need the CDELT1 and CDELT2 parameters to calculate how many pixels an X deg radius would include (I'm sure it's similar in casa tables format).

It may mean the user has to look more carefully at the output but at least the same region of sky would be covered.

Perhaps something like:

extraction_radius_pix = 1000 --> extraction_radius = 1000pix/1deg

[timstaley]

Yes, this sounds like a sensible change to me - we even store the skyregions with extraction_radius in degrees.

Would you need the option to switch between pixels / degrees, do you think, or would a complete switch to degrees work? I'd strongly prefer the latter as it's simpler to code and avoids user confusion, but would obviously mean changing configs, so we'd have to do it as part of a major release.

[AntoniaR]

Although I can see advantages in having both pixels and degrees, I also see the advantages in going for the simpler option! I'm happy with this switching to just using degrees in a major release. As long as we very clearly highlight that this has happened to all users when we switch, as otherwise it could cause extra confusion...

[AntoniaR]

This is an ongoing wish list item but not essential for R7. Moving to the long term milestone.

[HannoSpreeuw]

Seems like a PySE feature request.
Now I've seen how easy one can move issues from one repo to another, let me take care of that.