Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Below are two sets of metadata which will be stored in the new archive in regard to Images and the Image Sets to which they belong.  Included where relevant are the equivalent fields in the Virtual Observatory ObsCore Data Model,  a potential source from which to obtain the data, and a comment.  The images table was written specifically with the idea of spatial images in mind.  Other data products (spectra, time series, etc) would have different amounts of granularity in the header information available.

The existing images table covers much of the desired data.  The modifications we require are:

  • Split center_position and observing_band fields
  • Retaining image size data (the VO _xel fields)
  • Add fields for spectral resolution, physical data description, and spatial region information
  • Determination and acquisition of time-domain information.

...

Images

...

Images Database Table:

Column NameUnitsVO EquivalentSourceComments
sourcename
target_nameOBJECT Keyword
ra
(center_position)
degs_raCenter of Ra Axis
dec (center_position)

dec degs_decCenter of Dec Axis
image_field_of_viewdegs_fov
Average of NAXISn*CRDELn of the spatial Axes
Quadratic Mean of the ra & dec extents (NAXISn*CDELTn)
spatial_region
s_regionDerived from spatial DataSTC-S String Defined in the TAP (Dowler, et al 2010)
ra_element_count
s_xel1
Relevent
Relevant NAXISn Keyword
ra_pixel_size

abs(Relevant CDELTn)
dec_element_count
s_xel2
Relevent
Relevant NAXISn Keyword
dec_pixel_size

abs(Relevant CDELTn)
spatial_resolutionarcsecs_resolution
Average of CRDELn of the spatial Axesstarttimet_maxTemporal domain information for an image is dependent upon the observation(s) used in its generation.  Some controlling process (Like Vlass Manager, whatever imaging pipeline we create, and any image manipulation software we use) will need to supply it
sqrt(BMAJ*BMIN)Geometric mean of the synthesized beam axes.
beam_axis_ratio

BMAJ/BMINRatio of the synthesized beam axes.
starttimeMJDt_min

These values should be obtained by some larger-scale process.  VlassMgr, in the case of quicklook images

endtimeMJDt_
min
max
exposure_timest_exptime
min_frequency
observing_band)
Hzem_minMinimum of Spectral Axis

The spectral information is recoverable from the FITS header, and will identify the spectral coverage, and total bandwidth processed for the image. 


max_frequency
(observing_band)
Hzem_maxMaximum of Spectral Axis
spectral_resolutionem_res_powerSpectral CRDELn Keywordpolarization_code

rest_frequencyHz
RESTFRQ KeywordUsed for transformations
band_code

weblogRequires outside information source for accuracy. 

polarization_id


pol_states

Currently, there is insufficient information provided about the polarization information of the image in the quicklook FITS headers.  There is a STOKES axis, but no further information is provided. 

Since Single Epoch images will be created in Stokes
Polarization CRVALn value

CASA uses the CRVALn value to convey polarization information, with [1,2,3,4] mapped to [I,Q,

and

U,

that information must be provided to distinguish the files.  Adding the stokes parameter name to the CTYPEn or CUNITn header keywords would solve this issue. 

V]. 

Default to 'None' in case of other values.

telescope
instrument_nameTELESCOP KeywordThis must accommodate images for multiple instruments (i.e. VLA + Single Dish)
file_id

automatically generatedlink to information about the physical file
image_id
obs_idautomatically generatedUnique Identifier for the Image
image_units

o_ucd

BTYPE & BUNIT KeywordsDescription of the physical quantity measured in the image
max_intensityimage_units
image table values
min_intensity
These values are can be determined from the data portion of the image file in conjunction with the BSCALE & BZERO keywords.  The library which is used for FITS interaction for ingestion can perform these calculations, but no information about the speed of results is yet available.
min_intensityrms_noisethumbnailweblog, a PNG with identical name
image_units
image table values
rms_noiseimage_units
weblogBoth of these will need to come from the last stage of the imaging process, to maintain accuracy.  For quicklook images, that is stage7.  That may change (and will likely be different for the Single Epoch products).
thumbnail

weblog, find the matching thumbnail image generated.
tags


Internal tagging system to facilitate searches.
ra_pixel_size

Appropriate CDELTn
dec_pixel_size

Appropriate CDELTn

FITS Data Description Keywords:

...

Maximum: CRVALn + CDELTn*(NAXISn - CRPIXn)

There are similar formulae for the minimum and maximum values of an axis. 

For the Frequency axis, which only has a single point (NAXISn=1), our calculations are simpler:

Minimum:  CRVALn - CDELTn/2

Center :     CRVALn

Maximum: CRVALn +CDELTn/2

Image Sets Database Table:

...

Column NameVO EquivalentSourceComment
image_set_idobs_idautomatically generatedUnique Identifier for the Image Set
project_code
Required to facilitate Ingestion
configuration
VlassMgrThis will need to hold the entire list used for the imaging. 
collection_nameobs_collectionVlassMgr


calibration_levelcalib_levelVlassMgrAs defined by the VO in their 0-4 system
product_file_id
automatically generatedLink to the imaging products tar file
tags

internal tags which apply to all images of the set


VO ObsCore Remaining Fields:

VO RequirementValueSource

access_url



access_estsize
files.filesize, or combined value for an image set
dataproduct_type'image'default
access_format'fits'default

obs_publisher_did


Obtained upon registering with the Virtual Observatory
faciltyfacility_name'NRAO'default
t_resolution
images.image_integrationexposure_time
t_xel1default
em_res_powernull default
em_xel1default
pol_xel1default


Thumbnails

We won't store thumbnails in NGAS as such, for each we will:

  1. compute the sha1 hash of the file
  2. store the file in a filesystem at $ROOT/$1/$2/$3/$FILENAME, where $ROOT is a CAPO property that maps to the root of the filesystem, $1 is the first two characters of the sha1 sum, $2 the second two, and $3 the third two.
  3. in the metadata database we will store the $1/$2/$3/$FILENAME path