search

opencadc / caom2

Common Archive Observation Model
GNU Affero General Public License v3.0
5 stars 11 forks source link

Requiring pixel values for some WCS #29

Closed dr-rodriguez closed 6 years ago

dr-rodriguez commented 7 years ago

While validating CAOM v2.3 XML files, I’ve run into an error which appear to be driven by the schema design: in the SpectralWCS, PolarizationWCS, and TemporalWCS (energy, polarization, and time in Chunk, respectively) there is an axis element that contains a bounds element of type CoordsBound1D. This element consists of samples of start/end points defined by RefCoord which currently require both pix and val to be provided. While the physical value (val) should always be present, it’s not clear that a pixel value (pix) will be and that’s been the case for some of the data I’ve been working with. A simple fix may be to set these as minOccurs="0" in the schema.

pdowler commented 7 years ago

I will consult older use case docs and discover why it is done that way...

pdowler commented 6 years ago

The goal of the range/bounds/function objects in the wcs part of the model is to allow data providers to provide as little or as much metadata about the data array as was feasible. Normally only one of these is created per axis. The minimum was designed so that standard code could determine the dimensions and a possibly crude bounding box to aggregate into the plane metadata.

Now that we are moving to never compute plane metadata and provide it independently, the "range" values are no longer useful. The "bounds" objects have two possible uses:

  1. if the valid portion of the data array is smaller than the whole array described by the function, the bounds can be used as a footprint-within-the array; cutouts can try to return valid pixels only

  2. if the function representation is not feasible (eg multi-order spectroscopic data), the bounds can be used to define "tiles" and cutouts can extract tiles (not exact cutout but better than nothing). CADC uses this for some CFHT spectra, defining ~20-40 tiles for a spectrum with 200k pixels; a narrow cutouts can extract a single tile of 5-10k pixels.

So, yes - the intent is to require pixel and sky description in all three.

Recommendation: if you have the CoordFunction, leave the other two null unless use #1 above is valuable