Change request #2730
Adopt tools to store GSkyRegions instead of maps which would allow a greater flexibility
| Status: | New | Start date: | 11/08/2018 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assigned To: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | - | |||
| Duration: |
Description
The internal handling of regions is a little inconsistent over the tools.
ctskymap for example is able to read exclusions from both, a FITS map and a ds9 file. It internally creates a GSkyMap from the map or the geometrical regions.
csphagen (hence also cslightcrv, csphasecrv that internally call csphagen) is only able to read a FITS map because it internally creates a GSkyRegionMap.
Are there argument why this differing behaviour is needed?
Would it make sense to unify that by changing both tools to use a GSkyRegions container that internally handle maps and geometrical regions?
I think the interface for the tools should basically stay the same. In this scenario an adaption of GSkyRegions::load() would be neccessary, which currently is implemented to only read from a ds9 region file but could be extended to also load from FITS maps.
Recurrence
No recurrence.
History
#1
Updated by Specovius Andreas about 6 years ago
- Subject changed from Adopt tools to handle GSkyRegions instead of maps explicitly to Adopt tools to store GSkyRegions instead of maps which would allow a greater flexibility
#2
Updated by Specovius Andreas about 6 years ago
I am wondering how saving of regions would then work when both, maps and geometrical regions, were present in the GSkyRegions container...
#3
Updated by Knödlseder Jürgen over 5 years ago
- Target version set to 1.7.0
#4
Updated by Knödlseder Jürgen over 4 years ago
- Target version deleted (
1.7.0)