Home | Overview | Browser | Access | Login | Cookbook 
  VSA logo

Glossary of VSA attributes

This Glossary alphabetically lists all attributes used in the VSAv20150413 database(s) held in the VSA. If you would like to have more information about the schema tables please use the VSAv20150413 Schema Browser (other Browser versions).
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z

P

NameSchema TableDatabaseDescriptionTypeLengthUnitDefault ValueUnified Content Descriptor
PA combo17CDFSSource COMBO17 position angle, measured West to North real 4 deg    
PA nvssSource NVSS [-90, 90] Position angle of fitted major axis real 4 degress   pos.posAng
pa first08Jul16Source, firstSource, firstSource12Feb16 FIRST position angle (east of north) derived from the elliptical Gaussian model for the source real 4 degrees   pos.posAng
pa svNgc253Detection SVNGC253v20100429 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa svOrionDetection SVORIONv20100429 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa ultravistaDetection ULTRAVISTAv20100429 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis counterclockwise.
real 4 degrees   pos.posAng
pa vhsDetection VHSDR1 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vhsDetection VHSDR2 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vhsDetection VHSDR3 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vhsDetection VHSv20120926 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vhsDetection VHSv20130417 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vhsDetection VHSv20140409 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vhsDetection VHSv20150108 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa videoDetection VIDEODR2 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis counterclockwise.
real 4 degrees   pos.posAng
pa videoDetection VIDEODR3 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis counterclockwise.
real 4 degrees   pos.posAng
pa videoDetection VIDEODR4 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis counterclockwise.
real 4 degrees   pos.posAng
pa videoDetection VIDEOv20100513 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis counterclockwise.
real 4 degrees   pos.posAng
pa videoDetection VIDEOv20111208 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis counterclockwise.
real 4 degrees   pos.posAng
pa vikingDetection VIKINGDR2 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vikingDetection VIKINGDR3 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vikingDetection VIKINGDR4 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vikingDetection VIKINGv20110714 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vikingDetection VIKINGv20111019 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vikingDetection VIKINGv20130417 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vikingDetection VIKINGv20140402 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vikingDetection VIKINGv20150421 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCDR1 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCDR2 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCDR3 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20110816 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20110909 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20120126 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20121128 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20130304 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20130805 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20140428 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20140903 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vmcDetection VMCv20150309 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vvvDetection VVVDR1 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vvvDetection VVVDR2 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vvvDetection, vvvListRemeasurement VVVv20100531 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa vvvListRemeasurement VVVv20110718 ellipse fit orientation to x axis {catalogue TType keyword: Position_angle}
Angle of ellipse major axis wrt x axis.
real 4 degrees   pos.posAng
pa_2mass allwise_sc WISE Position angle (degrees E of N) of the vector from the WISE source to the associated 2MASS PSC source. This column is "null" if there is no associated 2MASS PSC source. float 8 deg    
pa_2mass wise_allskysc WISE Position angle (degrees E of N) of the vector from the WISE source to the associated 2MASS PSC source, default if there is no associated 2MASS PSC source. real 4 degrees -0.9999995e9  
pa_2mass wise_prelimsc WISE Position angle (degrees E of N) of the vector from the WISE source to the associated 2MASS PSC source, default if there is no associated 2MASS PSC source real 4 degrees -0.9999995e9  
pairingCriterion Programme SVNGC253v20100429 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme SVORIONv20100429 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme ULTRAVISTAv20100429 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VHSDR1 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VHSDR2 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VHSDR3 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VHSv20120926 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VHSv20130417 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VHSv20150108 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIDEODR2 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIDEODR3 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIDEODR4 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIDEOv20100513 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIDEOv20111208 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIKINGDR2 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIKINGDR3 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIKINGDR4 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIKINGv20110714 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIKINGv20111019 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIKINGv20130417 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VIKINGv20150421 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCDR1 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCDR3 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20110816 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20110909 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20120126 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20121128 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20130304 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20130805 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20140428 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20140903 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VMCv20150309 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VSAQC The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VVVDR1 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VVVDR2 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VVVv20100531 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
pairingCriterion Programme VVVv20110718 The pairing criterion for associating detections into merged sources real 4 Degrees   ??
parallax videoVariability VIDEODR2 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax videoVariability VIDEODR3 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax videoVariability VIDEODR4 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax videoVariability VIDEOv20100513 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax videoVariability VIDEOv20111208 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vikingVariability VIKINGDR2 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vikingVariability VIKINGDR3 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vikingVariability VIKINGDR4 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vikingVariability VIKINGv20110714 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vikingVariability VIKINGv20111019 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vikingVariability VIKINGv20130417 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vikingVariability VIKINGv20140402 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vikingVariability VIKINGv20150421 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCDR1 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCDR2 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCDR3 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20110816 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20110909 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20120126 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20121128 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20130304 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20130805 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20140428 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20140903 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vmcVariability VMCv20150309 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vvvVariability VVVDR1 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vvvVariability VVVDR2 Parallax of star real 4 mas -0.9999995e9 pos.parallax
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vvvVariability VVVv20100531 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
parallax vvvVariability VVVv20110718 Parallax of star real 4 mas -0.9999995e9  
The Variability table contains statistics from the set of observations of each source. At present, the mean ra and dec and the error in two tangential directions are calculated. The "ra" direction is defined as tangential to both the radial direction and the cartesian z-axis and the "dec" direction is defined as both the radial direction and the "ra" direction. Since the current model is just the mean and standard deviation of the data, then the chi-squared of the fit=1. Data from good frames across all bands go into the astrometric model determination. This will include bands in non-synoptic filters: the one observation in these bands can help. In future releases a fit will be made to the rms data as a function of magnitude in each band, as has already happened for photometric data and a motion model that incorporates proper motion (and possibly parallax) will be used. The motion model is a parameter in the VarFrameSetInfo table.
PARK grs_ngpSource, grs_ranSource, grs_sgpSource TWODFGRS k classification parameter = k / k_star real 4      
PARMU grs_ngpSource, grs_ranSource, grs_sgpSource TWODFGRS mu classification parameter = mu / mu_star real 4      
patternString Multiframe VHSDR1 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VHSDR2 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VHSDR3 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VHSv20120926 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VHSv20130417 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VHSv20140409 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VHSv20150108 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIDEODR2 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIDEODR3 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIDEODR4 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIDEOv20111208 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIKINGDR2 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIKINGDR3 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIKINGDR4 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIKINGv20110714 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIKINGv20111019 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIKINGv20130417 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIKINGv20140402 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VIKINGv20150421 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCDR1 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCDR2 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCDR3 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20110816 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20110909 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20120126 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20121128 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20130304 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20130805 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20140428 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20140903 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VMCv20150309 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VSAQC SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VVVDR1 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VVVDR2 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString Multiframe VVVv20110718 SADT pattern ID {image primary HDU keyword: HIERARCH ESO OCS SADT PATTERN} varchar 64   NONE  
patternString ultravistaMultiframe, vhsMultiframe, videoMultiframe, vikingMultiframe, vmcMultiframe, vvvMultiframe VSAQC SADT pattern ID varchar 64   NONE  
period vmcCepheidVariables VMCDR3 Period of first mode of oscillation {catalogue TType keyword: Period} real 4 day -0.9999995e9 time.period
period vmcCepheidVariables VMCv20121128 Period of first mode of oscillation {catalogue TType keyword: Period} real 4 day -0.9999995e9 time.period
period vmcCepheidVariables VMCv20140428 Period of first mode of oscillation {catalogue TType keyword: Period} real 4 day -0.9999995e9 time.period
period vmcCepheidVariables VMCv20140903 Period of first mode of oscillation {catalogue TType keyword: Period} real 4 day -0.9999995e9 time.period
period vmcCepheidVariables VMCv20150309 Period of first mode of oscillation {catalogue TType keyword: Period} real 4 day -0.9999995e9 time.period
period vmcEclipsingBinaryVariables VMCv20140903 Period from the EROS/OGLE catalogues. Periods of some stars (marked *, in externalID) were recalculated using GRATIS {catalogue TType keyword: PERIOD} real 4 day   time.period
period vmcEclipsingBinaryVariables VMCv20150309 Period from the EROS/OGLE catalogues. Periods of some stars (marked *, in externalID) were recalculated using GRATIS {catalogue TType keyword: PERIOD} real 4 day   time.period
petroFlux svNgc253Detection SVNGC253v20100429 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux svOrionDetection SVORIONv20100429 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux ultravistaDetection ULTRAVISTAv20100429 flux within Petrosian radius circular aperture (SE: FLUX_PETRO) {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vhsDetection VHSDR1 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vhsDetection VHSDR2 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vhsDetection VHSDR3 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vhsDetection VHSv20120926 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vhsDetection VHSv20130417 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vhsDetection VHSv20140409 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vhsDetection VHSv20150108 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux videoDetection VIDEODR2 flux within Petrosian radius circular aperture (SE: FLUX_PETRO) {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux videoDetection VIDEODR3 flux within Petrosian radius circular aperture (SE: FLUX_PETRO) {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux videoDetection VIDEODR4 flux within Petrosian radius circular aperture (SE: FLUX_PETRO) {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux videoDetection VIDEOv20100513 flux within Petrosian radius circular aperture (SE: FLUX_PETRO) {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux videoDetection VIDEOv20111208 flux within Petrosian radius circular aperture (SE: FLUX_PETRO) {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vikingDetection VIKINGDR2 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vikingDetection VIKINGDR3 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vikingDetection VIKINGDR4 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vikingDetection VIKINGv20110714 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vikingDetection VIKINGv20111019 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vikingDetection VIKINGv20130417 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vikingDetection VIKINGv20140402 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vikingDetection VIKINGv20150421 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vmcDetection VMCDR1 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vmcDetection VMCDR2 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vmcDetection VMCDR3 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vmcDetection VMCv20110816 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vmcDetection VMCv20110909 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vmcDetection VMCv20120126 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vmcDetection VMCv20121128 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vmcDetection VMCv20130304 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vmcDetection VMCv20130805 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vmcDetection VMCv20140428 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vmcDetection VMCv20140903 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vmcDetection VMCv20150309 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vvvDetection VVVDR1 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vvvDetection VVVDR2 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count
petroFlux vvvDetection, vvvListRemeasurement VVVv20100531 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFlux vvvListRemeasurement VVVv20110718 flux within circular aperture to k × r_p ; k = 2 {catalogue TType keyword: Petr_flux} real 4 ADU   phot.count;em.opt
petroFluxErr svNgc253Detection SVNGC253v20100429 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr svOrionDetection SVORIONv20100429 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr ultravistaDetection ULTRAVISTAv20100429 error on Petrosian flux (SE: FLUXERR_PETRO) {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vhsDetection VHSDR1 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vhsDetection VHSDR2 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vhsDetection VHSDR3 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vhsDetection VHSv20120926 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vhsDetection VHSv20130417 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vhsDetection VHSv20140409 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vhsDetection VHSv20150108 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr videoDetection VIDEODR2 error on Petrosian flux (SE: FLUXERR_PETRO) {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr videoDetection VIDEODR3 error on Petrosian flux (SE: FLUXERR_PETRO) {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr videoDetection VIDEODR4 error on Petrosian flux (SE: FLUXERR_PETRO) {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr videoDetection VIDEOv20100513 error on Petrosian flux (SE: FLUXERR_PETRO) {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr videoDetection VIDEOv20111208 error on Petrosian flux (SE: FLUXERR_PETRO) {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vikingDetection VIKINGDR2 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vikingDetection VIKINGDR3 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vikingDetection VIKINGDR4 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vikingDetection VIKINGv20110714 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vikingDetection VIKINGv20111019 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vikingDetection VIKINGv20130417 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vikingDetection VIKINGv20140402 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vikingDetection VIKINGv20150421 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCDR1 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCDR2 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCDR3 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20110816 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20110909 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20120126 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20121128 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20130304 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20130805 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20140428 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20140903 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vmcDetection VMCv20150309 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vvvDetection VVVDR1 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vvvDetection VVVDR2 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vvvDetection, vvvListRemeasurement VVVv20100531 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroFluxErr vvvListRemeasurement VVVv20110718 error on Petrosian flux {catalogue TType keyword: Petr_flux_err} real 4 ADU   stat.error
petroMag svNgc253Detection SVNGC253v20100429 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag svOrionDetection SVORIONv20100429 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag ultravistaDetection ULTRAVISTAv20100429 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vhsDetection VHSDR1 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vhsDetection VHSDR2 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vhsDetection VHSDR3 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vhsDetection VHSv20120926 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vhsDetection VHSv20130417 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vhsDetection VHSv20140409 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vhsDetection VHSv20150108 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag videoDetection VIDEODR2 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag videoDetection VIDEODR3 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag videoDetection VIDEODR4 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag videoDetection VIDEOv20100513 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag videoDetection VIDEOv20111208 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vikingDetection VIKINGDR2 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vikingDetection VIKINGDR3 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vikingDetection VIKINGDR4 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vikingDetection VIKINGv20110714 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vikingDetection VIKINGv20111019 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vikingDetection VIKINGv20130417 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vikingDetection VIKINGv20140402 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vikingDetection VIKINGv20150421 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCDR1 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCDR2 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCDR3 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20110816 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20110909 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20120126 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20121128 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20130304 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20130805 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20140428 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20140903 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vmcDetection VMCv20150309 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vvvDetection VVVDR1 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vvvDetection VVVDR2 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vvvDetection, vvvListRemeasurement VVVv20100531 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMag vvvListRemeasurement VVVv20110718 Calibrated Petrosian magnitude within circular aperture r_p real 4 mag   phot.mag
petroMagErr svNgc253Detection SVNGC253v20100429 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr svOrionDetection SVORIONv20100429 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr ultravistaDetection ULTRAVISTAv20100429 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vhsDetection VHSDR1 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vhsDetection VHSDR2 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vhsDetection VHSDR3 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vhsDetection VHSv20120926 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vhsDetection VHSv20130417 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vhsDetection VHSv20140409 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vhsDetection VHSv20150108 error on calibrated Petrosian magnitude real 4 mag   stat.error;phot.mag
petroMagErr videoDetection VIDEODR2 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr videoDetection VIDEODR3 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr videoDetection VIDEODR4 error on calibrated Petrosian magnitude real 4 mag   stat.error;phot.mag
petroMagErr videoDetection VIDEOv20100513 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr videoDetection VIDEOv20111208 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vikingDetection VIKINGDR2 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vikingDetection VIKINGDR3 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vikingDetection VIKINGDR4 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vikingDetection VIKINGv20110714 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vikingDetection VIKINGv20111019 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vikingDetection VIKINGv20130417 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vikingDetection VIKINGv20140402 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vikingDetection VIKINGv20150421 error on calibrated Petrosian magnitude real 4 mag   stat.error;phot.mag
petroMagErr vmcDetection VMCDR1 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCDR2 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCDR3 error on calibrated Petrosian magnitude real 4 mag   stat.error;phot.mag
petroMagErr vmcDetection VMCv20110816 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCv20110909 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCv20120126 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCv20121128 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCv20130304 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCv20130805 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCv20140428 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vmcDetection VMCv20140903 error on calibrated Petrosian magnitude real 4 mag   stat.error;phot.mag
petroMagErr vmcDetection VMCv20150309 error on calibrated Petrosian magnitude real 4 mag   stat.error;phot.mag
petroMagErr vvvDetection VVVDR1 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vvvDetection VVVDR2 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vvvDetection, vvvListRemeasurement VVVv20100531 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroMagErr vvvListRemeasurement VVVv20110718 error on calibrated Petrosian magnitude real 4 mag   stat.error
petroRad svNgc253Detection SVNGC253v20100429 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad svOrionDetection SVORIONv20100429 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad ultravistaDetection ULTRAVISTAv20100429 Petrosian radius (SE: PETRO_RADIUS*A_IMAGE) {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
Since <FLUX>_RADIUS is expressed in multiples of the major axis, <FLUX>_RADIUS is multiplied by A_IMAGE to convert to pixels.
petroRad vhsDetection VHSDR1 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vhsDetection VHSDR2 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vhsDetection VHSDR3 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vhsDetection VHSv20120926 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vhsDetection VHSv20130417 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vhsDetection VHSv20140409 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vhsDetection VHSv20150108 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad videoDetection VIDEODR2 Petrosian radius (SE: PETRO_RADIUS*A_IMAGE) {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
Since <FLUX>_RADIUS is expressed in multiples of the major axis, <FLUX>_RADIUS is multiplied by A_IMAGE to convert to pixels.
petroRad videoDetection VIDEODR3 Petrosian radius (SE: PETRO_RADIUS*A_IMAGE) {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
Since <FLUX>_RADIUS is expressed in multiples of the major axis, <FLUX>_RADIUS is multiplied by A_IMAGE to convert to pixels.
petroRad videoDetection VIDEODR4 Petrosian radius (SE: PETRO_RADIUS*A_IMAGE) {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
Since <FLUX>_RADIUS is expressed in multiples of the major axis, <FLUX>_RADIUS is multiplied by A_IMAGE to convert to pixels.
petroRad videoDetection VIDEOv20100513 Petrosian radius (SE: PETRO_RADIUS*A_IMAGE) {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
Since <FLUX>_RADIUS is expressed in multiples of the major axis, <FLUX>_RADIUS is multiplied by A_IMAGE to convert to pixels.
petroRad videoDetection VIDEOv20111208 Petrosian radius (SE: PETRO_RADIUS*A_IMAGE) {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
Since <FLUX>_RADIUS is expressed in multiples of the major axis, <FLUX>_RADIUS is multiplied by A_IMAGE to convert to pixels.
petroRad vikingDetection VIKINGDR2 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vikingDetection VIKINGDR3 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vikingDetection VIKINGDR4 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vikingDetection VIKINGv20110714 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vikingDetection VIKINGv20111019 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vikingDetection VIKINGv20130417 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vikingDetection VIKINGv20140402 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vikingDetection VIKINGv20150421 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vmcDetection VMCDR1 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vmcDetection VMCDR2 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vmcDetection VMCDR3 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vmcDetection VMCv20110816 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vmcDetection VMCv20110909 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vmcDetection VMCv20120126 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vmcDetection VMCv20121128 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vmcDetection VMCv20130304 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vmcDetection VMCv20130805 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vmcDetection VMCv20140428 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vmcDetection VMCv20140903 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vmcDetection VMCv20150309 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vvvDetection VVVDR1 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vvvDetection VVVDR2 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize
petroRad vvvDetection, vvvListRemeasurement VVVv20100531 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
petroRad vvvListRemeasurement VVVv20110718 r_p as defined in Yasuda et al. 2001 AJ 112 1104 {catalogue TType keyword: Petr_radius} real 4 pixels   phys.angSize;src
PF_DEC mgcBrightSpec MGC PFr object declination in deg (J2000) float 8      
PF_JMK mgcBrightSpec MGC PFr J-K colour from 2MASS real 4      
PF_K mgcBrightSpec MGC PFr K magnitude from 2MASS real 4      
PF_NAME mgcBrightSpec MGC PFr object name varchar 8      
PF_R mgcBrightSpec MGC PFr R magnitude from USNO real 4      
PF_RA mgcBrightSpec MGC PFr object right ascension in deg (J2000) float 8      
PF_Z mgcBrightSpec MGC PFr redshift real 4      
PF_ZQUAL mgcBrightSpec MGC PFr redshift quality tinyint 1      
pFlag rosat_bsc, rosat_fsc ROSAT possible problem with position determination varchar 1     meta.code
pGalaxy svNgc253Source SVNGC253v20100429 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy svOrionSource SVORIONv20100429 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy ultravistaSource ULTRAVISTAv20100429 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vhsSource VHSDR1 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vhsSource VHSDR2 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vhsSource VHSDR3 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vhsSource VHSv20120926 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vhsSource VHSv20130417 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vhsSource VHSv20140409 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vhsSource VHSv20150108 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy videoSource VIDEODR2 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy videoSource VIDEODR3 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy videoSource VIDEODR4 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy videoSource VIDEOv20100513 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy videoSource VIDEOv20111208 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vikingSource VIKINGDR2 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vikingSource VIKINGDR3 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vikingSource VIKINGDR4 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vikingSource VIKINGv20110714 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vikingSource VIKINGv20111019 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vikingSource VIKINGv20130417 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vikingSource VIKINGv20140402 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vikingSource VIKINGv20150421 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCDR2 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCDR3 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20110816 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20110909 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20120126 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20121128 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20130304 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20130805 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20140428 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20140903 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource VMCv20150309 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vmcSource, vmcSynopticSource VMCDR1 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vvvSource VVVDR2 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vvvSource VVVv20100531 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vvvSource VVVv20110718 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pGalaxy vvvSource, vvvSynopticSource VVVDR1 Probability that the source is a galaxy real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

ph_qual allwise_sc WISE Photometric quality flag. Four character flag, one character per band [W1/W2/W3/W4], that provides a shorthand summary of the quality of the profile-fit photometry measurement in each band, as derived from the measurement signal-to-noise ratio. varchar 4      
  • A - Source is detected in this band with a flux signal-to-noise ratio w?snr>10.
  • B - Source is detected in this band with a flux signal-to-noise ratio 3<w?snr<10.
  • C - Source is detected in this band with a flux signal-to-noise ratio 2<w?snr<3.
  • U - Upper limit on magnitude. Source measurement has w?snr<2. The profile-fit magnitude w?mpro is a 95% confidence upper limit.
  • X - A profile-fit measurement was not possible at this location in this band. The value of w?mpro and w?sigmpro will be "null" in this band.
  • Z - A profile-fit source flux measurement was made at this location, but the flux uncertainty could not be measured. The value of w?sigmpro will be "null" in this band. The value of w?mpro will be "null" if the measured flux, w?flux, is negative, but will not be "null" if the flux is positive. If a non-null magnitude is present, it corresponds to the true flux, and not the 95% confidence upper limit. This occurs for a small number of sources found in a narrow range of ecliptic longitude which were covered by a large number of saturated pixels from 3-Band Cryo single-exposures.
ph_qual twomass_psc 2MASS Photometric quality flag. varchar 3     meta.code.qual
ph_qual twomass_sixx2_psc 2MASS flag indicating photometric quality of source varchar 3      
ph_qual wise_allskysc WISE Photometric quality flag.
Four character flag, one character per band [W1/W2/W3/W4], that provides a shorthand summary of the quality of the profile-fit photometry measurement in each band, as derived from the measurement signal-to-noise ratio.
char 4      
ph_qual wise_prelimsc WISE Photometric quality flag
Four character flag, one character per band [W1/W2/W3/W4], that provides a shorthand summary of the quality of the profile-fit photometry measurement in each band, as derived from the measurement signal-to-noise ratio
char 4      
phaRange rosat_bsc, rosat_fsc ROSAT PHA range with highest detection likelihood varchar 1     meta.code
pHeight svNgc253Detection SVNGC253v20100429 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight svOrionDetection SVORIONv20100429 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight ultravistaDetection ULTRAVISTAv20100429 Highest pixel value above sky (SE: FLUX_MAX) {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vhsDetection VHSDR1 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vhsDetection VHSDR2 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vhsDetection VHSDR3 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vhsDetection VHSv20120926 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vhsDetection VHSv20130417 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vhsDetection VHSv20140409 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vhsDetection VHSv20150108 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight videoDetection VIDEODR2 Highest pixel value above sky (SE: FLUX_MAX) {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight videoDetection VIDEODR3 Highest pixel value above sky (SE: FLUX_MAX) {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight videoDetection VIDEODR4 Highest pixel value above sky (SE: FLUX_MAX) {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight videoDetection VIDEOv20100513 Highest pixel value above sky (SE: FLUX_MAX) {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight videoDetection VIDEOv20111208 Highest pixel value above sky (SE: FLUX_MAX) {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vikingDetection VIKINGDR2 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vikingDetection VIKINGDR3 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vikingDetection VIKINGDR4 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vikingDetection VIKINGv20110714 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vikingDetection VIKINGv20111019 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vikingDetection VIKINGv20130417 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vikingDetection VIKINGv20140402 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vikingDetection VIKINGv20150421 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCDR1 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCDR2 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCDR3 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20110816 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20110909 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20120126 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20121128 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20130304 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20130805 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20140428 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20140903 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vmcDetection VMCv20150309 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vvvDetection VVVDR1 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vvvDetection VVVDR2 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vvvDetection, vvvListRemeasurement VVVv20100531 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeight vvvListRemeasurement VVVv20110718 Highest pixel value above sky {catalogue TType keyword: Peak_height}
In counts relative to local value of sky - also zeroth order aperture flux.
real 4 ADU   phot.count
pHeightErr svNgc253Detection SVNGC253v20100429 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr svOrionDetection SVORIONv20100429 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr ultravistaDetection ULTRAVISTAv20100429 Error in peak height {catalogue TType keyword: Peak_height_err}
FLUX_MAX*FLUXERR_APER1 / FLUX_APER1
real 4 ADU   stat.error
pHeightErr vhsDetection VHSDR1 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vhsDetection VHSDR2 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vhsDetection VHSDR3 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vhsDetection VHSv20120926 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vhsDetection VHSv20130417 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vhsDetection VHSv20140409 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vhsDetection VHSv20150108 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr videoDetection VIDEODR2 Error in peak height {catalogue TType keyword: Peak_height_err}
FLUX_MAX*FLUXERR_APER1 / FLUX_APER1
real 4 ADU   stat.error
pHeightErr videoDetection VIDEODR3 Error in peak height {catalogue TType keyword: Peak_height_err}
FLUX_MAX*FLUXERR_APER1 / FLUX_APER1
real 4 ADU   stat.error
pHeightErr videoDetection VIDEODR4 Error in peak height {catalogue TType keyword: Peak_height_err}
FLUX_MAX*FLUXERR_APER1 / FLUX_APER1
real 4 ADU   stat.error
pHeightErr videoDetection VIDEOv20100513 Error in peak height {catalogue TType keyword: Peak_height_err}
FLUX_MAX*FLUXERR_APER1 / FLUX_APER1
real 4 ADU   stat.error
pHeightErr videoDetection VIDEOv20111208 Error in peak height {catalogue TType keyword: Peak_height_err}
FLUX_MAX*FLUXERR_APER1 / FLUX_APER1
real 4 ADU   stat.error
pHeightErr vikingDetection VIKINGDR2 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vikingDetection VIKINGDR3 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vikingDetection VIKINGDR4 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vikingDetection VIKINGv20110714 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vikingDetection VIKINGv20111019 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vikingDetection VIKINGv20130417 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vikingDetection VIKINGv20140402 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vikingDetection VIKINGv20150421 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCDR1 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCDR2 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCDR3 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20110816 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20110909 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20120126 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20121128 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20130304 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20130805 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20140428 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20140903 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vmcDetection VMCv20150309 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vvvDetection VVVDR1 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vvvDetection VVVDR2 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vvvDetection, vvvListRemeasurement VVVv20100531 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
pHeightErr vvvListRemeasurement VVVv20110718 Error in peak height {catalogue TType keyword: Peak_height_err} real 4 ADU   stat.error
phi_opt twomass_psc 2MASS Position angle on the sky of the vector from the the associated optical source to the TWOMASS source position, in degrees East of North. smallint 2 degrees   pos.posAng
phot_flag combo17CDFSSource COMBO17 flags on photometry: bit 0-7 (corresponding to values 0-128) are original SExtractor flags, bit 9-11 set by COMBO-17 photometry, bit 9 indicates only potential problem from bright neighbours or reflexes from the optics (check images), bit 10 indicates uncorrected hot pixels, bit 11 is set interactively when photometry is erroneous smallint 2      
photZPCat MultiframeDetector SVNGC253v20100429 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector SVORIONv20100429 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector ULTRAVISTAv20100429 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VHSDR1 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VHSDR2 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VHSDR3 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VHSv20120926 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VHSv20130417 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VHSv20140409 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VHSv20150108 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIDEODR2 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIDEODR3 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIDEODR4 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIDEOv20100513 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIDEOv20111208 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIKINGDR2 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIKINGDR3 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIKINGDR4 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIKINGv20110714 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIKINGv20111019 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIKINGv20130417 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIKINGv20140402 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VIKINGv20150421 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCDR1 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCDR2 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCDR3 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20110816 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20110909 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20120126 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20121128 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20130304 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20130805 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20140428 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20140903 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VMCv20150309 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VSAQC Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VVVDR1 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VVVDR2 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VVVv20100531 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat MultiframeDetector VVVv20110718 Photometric zero point for default extinction for the catalogue data {catalogue extension keyword:  MAGZPT} real 4 mags -0.9999995e9 ??
Derived detector zero-point in the sense of what magnitude object gives a total (corrected) flux of 1 count/s. These ZPs are appropriate for generating magnitudes in the natural detector+filter system based on Vega, see CASU reports for more details on colour equations etc. The ZPs have been derived from a robust average of all photometric standards observed on any particular set of frames, corrected for airmass but assuming the default extinction values listed later. For other airmass or other values of the extinction use
ZP → ZP - [sec(z)-1]×extinct + extinct default - extinct
You can then make use of any of the assorted flux estimators to produce magnitudes via
Mag = ZP - 2.5*log10(flux/exptime) - aperCor - skyCorr
Note that for the so-called total and isophotal flux options it is not possible to have a single-valued aperture correction.
photZPCat PreviousMFDZP SVNGC253v20100429 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP SVORIONv20100429 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP ULTRAVISTAv20100429 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VHSDR1 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VHSDR2 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VHSDR3 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VHSv20120926 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VHSv20130417 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VHSv20140409 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VHSv20150108 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIDEODR2 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIDEODR3 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIDEODR4 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIDEOv20100513 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIDEOv20111208 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIKINGDR2 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIKINGDR3 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIKINGDR4 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIKINGv20110714 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIKINGv20111019 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIKINGv20130417 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIKINGv20140402 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VIKINGv20150421 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCDR1 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCDR2 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCDR3 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20110816 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20110909 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20120126 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20121128 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20130304 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20130805 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20140428 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20140903 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VMCv20150309 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VSAQC Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VVVDR1 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VVVDR2 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VVVv20100531 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat PreviousMFDZP VVVv20110718 Photometric zeropoint for default extinction in catalogue header real 4 mag -0.9999995e9  
photZPCat ultravistaMultiframeDetector, vhsMultiframeDetector, videoMultiframeDetector, vikingMultiframeDetector, vmcMultiframeDetector, vvvMultiframeDetector VSAQC Photometric zero point for default extinction for the catalogue data real 4 mags -0.9999995e9 ??
photZPErrCat MultiframeDetector SVNGC253v20100429 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR}
[Currently set to -1 for WFCAM data.]
real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector SVORIONv20100429 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR}
[Currently set to -1 for WFCAM data.]
real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector ULTRAVISTAv20100429 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR}
[Currently set to -1 for WFCAM data.]
real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VHSDR1 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VHSDR2 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VHSDR3 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VHSv20120926 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VHSv20130417 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VHSv20140409 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VHSv20150108 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIDEODR2 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIDEODR3 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIDEODR4 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIDEOv20100513 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR}
[Currently set to -1 for WFCAM data.]
real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIDEOv20111208 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIKINGDR2 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIKINGDR3 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIKINGDR4 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIKINGv20110714 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIKINGv20111019 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIKINGv20130417 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIKINGv20140402 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VIKINGv20150421 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCDR1 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCDR2 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCDR3 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20110816 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20110909 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20120126 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20121128 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20130304 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20130805 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20140428 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20140903 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VMCv20150309 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VSAQC Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VVVDR1 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VVVDR2 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VVVv20100531 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR}
[Currently set to -1 for WFCAM data.]
real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat MultiframeDetector VVVv20110718 Photometric zero point error for the catalogue data {catalogue extension keyword:  MAGZRR} real 4 mags -0.9999995e9 ??
Error in the zero point. If good photometric night this error will be at the level of a few percent. Values of 0.05 and above indicate correspondingly non-photometric night and worse.
photZPErrCat PreviousMFDZP SVNGC253v20100429 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP SVORIONv20100429 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP ULTRAVISTAv20100429 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VHSDR1 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VHSDR2 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VHSDR3 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VHSv20120926 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VHSv20130417 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VHSv20140409 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VHSv20150108 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIDEODR2 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIDEODR3 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIDEODR4 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIDEOv20100513 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIDEOv20111208 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIKINGDR2 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIKINGDR3 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIKINGDR4 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIKINGv20110714 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIKINGv20111019 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIKINGv20130417 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIKINGv20140402 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VIKINGv20150421 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCDR1 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCDR2 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCDR3 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20110816 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20110909 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20120126 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20121128 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20130304 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20130805 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20140428 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20140903 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VMCv20150309 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VSAQC Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VVVDR1 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VVVDR2 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VVVv20100531 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat PreviousMFDZP VVVv20110718 Photometric zeropoint error in catalogue header real 4 mag -0.9999995e9  
photZPErrCat ultravistaMultiframeDetector, vhsMultiframeDetector, videoMultiframeDetector, vikingMultiframeDetector, vmcMultiframeDetector, vvvMultiframeDetector VSAQC Photometric zero point error for the catalogue data real 4 mags -0.9999995e9 ??
picoi Multiframe SVNGC253v20100429 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe SVORIONv20100429 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe ULTRAVISTAv20100429 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VHSDR1 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VHSDR2 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VHSDR3 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VHSv20120926 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VHSv20130417 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VHSv20140409 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VHSv20150108 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIDEODR2 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIDEODR3 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIDEODR4 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIDEOv20100513 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIDEOv20111208 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIKINGDR2 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIKINGDR3 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIKINGDR4 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIKINGv20110714 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIKINGv20111019 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIKINGv20130417 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIKINGv20140402 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VIKINGv20150421 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCDR1 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCDR2 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCDR3 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20110816 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20110909 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20120126 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20121128 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20130304 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20130805 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20140428 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20140903 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VMCv20150309 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VSAQC PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VVVDR1 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VVVDR2 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VVVv20100531 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi Multiframe VVVv20110718 PI-COI name. {image primary HDU keyword: PI-COI} varchar 64   NONE  
picoi ultravistaMultiframe, vhsMultiframe, videoMultiframe, vikingMultiframe, vmcMultiframe, vvvMultiframe VSAQC PI-COI name. varchar 64   NONE  
PID_R spectra SIXDF PID number read from R frame int 4      
PID_V spectra SIXDF PID number read from V frame int 4      
PIDL15 akari_lmc_psa_v1, akari_lmc_psc_v1 AKARI Observing Pointing identifier char 9   9999999.9  
PIDL24 akari_lmc_psa_v1, akari_lmc_psc_v1 AKARI Observing Pointing identifier char 9   9999999.9  
PIDN3 akari_lmc_psa_v1, akari_lmc_psc_v1 AKARI Observing Pointing identifier char 9   9999999.9  
PIDS11 akari_lmc_psa_v1, akari_lmc_psc_v1 AKARI Observing Pointing identifier char 9   9999999.9  
PIDS7 akari_lmc_psa_v1, akari_lmc_psc_v1 AKARI Observing Pointing identifier char 9   9999999.9  
PIVOT_R spectra SIXDF R pivot number smallint 2      
PIVOT_V spectra SIXDF V pivot number smallint 2      
Pix_x_I denisDR3Source DENIS Pixel x position in I band float 8 pix    
Pix_x_J denisDR3Source DENIS Pixel x position in J band float 8 pix    
Pix_x_K denisDR3Source DENIS Pixel x position in K band float 8 pix    
Pix_y_I denisDR3Source DENIS Pixel y position in I band float 8 pix    
Pix_y_J denisDR3Source DENIS Pixel y position in J band float 8 pix    
Pix_y_K denisDR3Source DENIS Pixel y position in K band float 8 pix    
pixelID vvvBulge3DExtinctVals EXTINCT UID of the pixel int 4     meta.id
pixelID vvvBulgeExtMapCoords EXTINCT UID of the 2D pixel int 4     meta.id;meta.main
pixelSize RequiredMosaic VHSDR1 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VHSDR2 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VHSDR3 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VHSv20120926 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VHSv20130417 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VHSv20150108 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIDEODR2 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIDEODR3 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIDEODR4 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIDEOv20100513 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIDEOv20111208 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIKINGDR2 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIKINGDR3 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIKINGDR4 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIKINGv20110714 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIKINGv20111019 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIKINGv20130417 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VIKINGv20150421 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCDR1 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCDR3 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20110816 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20110909 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20120126 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20121128 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20130304 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20130805 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20140428 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20140903 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VMCv20150309 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VSAQC The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VVVDR1 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VVVDR2 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VVVv20100531 The final pixel size of the mosaic real 4 arcsec   ??
pixelSize RequiredMosaic VVVv20110718 The final pixel size of the mosaic real 4 arcsec   ??
pixSizeAng ThreeDimExtinctionMaps EXTINCT Angular resolution of extinction map real 4 Arcminutes -0.9999995e9  
pixSizeRad ThreeDimExtinctionMaps EXTINCT Radial resolution of extinction map real 4 kpc -0.9999995e9  
PMAG grs_ngpSource, grs_ranSource, grs_sgpSource TWODFGRS Unmatched raw APM profile integrated mag real 4      
pmcode allwise_sc WISE This is a five character string that encodes information about factors that impact the accuracy of the motion estimation. These include the original blend count, whether a blend-swap took place, and the distance in hundredths of an arcsecond between the non-motion position and the motion mean-observation-epoch position. This column is null if a motion solution was not attempted or a valid solution was not found. varchar 5      
The format is NQDDD where N is the original blend count, Q is either "Y" or "N" for "yes" or "no" a blend-swap occurred (i.e., the original primary component was not the final primary component), and DDD is the radial distance between the non-motion and motion at mean-observation epoch positions in units of 0.01 arcsec, clipped at 999 (almost 10 arcsec).

For example, a well-behaved source that is not part of a blend and that has similar stationary and motion fit positions would have a pmcode value like "1N008". A source with a questionable motion estimate that is passively deblended (nb=2) and whose stationary-fit and motion position differ by a significant amount would have a pmcode value like "3Y234".

pmDec ukirtFSstars SVNGC253v20100429 Proper motion in Dec real 4 arcsec per year 0.0  
pmDec ukirtFSstars SVORIONv20100429 Proper motion in Dec real 4 arcsec per year 0.0  
pmDec ukirtFSstars ULTRAVISTAv20100429 Proper motion in Dec real 4 arcsec per year 0.0  
pmDec ukirtFSstars VIDEOv20100513 Proper motion in Dec real 4 arcsec per year 0.0  
pmDec ukirtFSstars VIKINGv20110714 Proper motion in Dec real 4 arcsec per year 0.0  
pmDec ukirtFSstars VVVv20100531 Proper motion in Dec real 4 arcsec per year 0.0  
pmdec allwise_sc WISE The apparent motion in declination estimated for this source. This column is null if the motion fit failed to converge or was not attempted. CAUTION: This is the total motion in declination, and not the proper motion. The apparent motion can be significantly affected by parallax for nearby objects. int 4 mas/year    
pmRA ukirtFSstars SVNGC253v20100429 Proper motion in RA real 4 arcsec per year 0.0  
pmRA ukirtFSstars SVORIONv20100429 Proper motion in RA real 4 arcsec per year 0.0  
pmRA ukirtFSstars ULTRAVISTAv20100429 Proper motion in RA real 4 arcsec per year 0.0  
pmRA ukirtFSstars VIDEOv20100513 Proper motion in RA real 4 arcsec per year 0.0  
pmRA ukirtFSstars VIKINGv20110714 Proper motion in RA real 4 arcsec per year 0.0  
pmRA ukirtFSstars VVVv20100531 Proper motion in RA real 4 arcsec per year 0.0  
pmra allwise_sc WISE The apparent motion in right ascension estimated for this source. This column is null if the motion fit failed to converge or was not attempted. CAUTION: This is the total motion in right ascension, and not the proper motion. The apparent motion can be significantly affected by parallax for nearby objects. int 4 mas/year    
PN_1_BG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 1 background map.
Made using a 12 x 12 nodes spline fit on the source-free individual-band images.
real 4 counts/pixel    
PN_1_DET_ML twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 1 Maximum likelihood real 4      
PN_1_EXP twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 1 exposure map, combining the mirror vignetting, detector efficiency, bad pixels and CCD gaps.
The PSF weighted mean of the area of the subimages (radius 60 arcseconds) in the individual-band exposure maps.
real 4 s    
PN_1_FLUX twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 1 flux real 4 erg/cm**2/s    
PN_1_FLUX_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 1 flux error real 4 erg/cm**2/s    
PN_1_RATE twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 1 Count rates real 4 counts/s    
PN_1_RATE_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 1 Count rates error real 4 counts/s    
PN_1_VIG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 1 vignetting value. real 4      
PN_2_BG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 2 background map.
Made using a 12 x 12 nodes spline fit on the source-free individual-band images.
real 4 counts/pixel    
PN_2_DET_ML twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 2 Maximum likelihood real 4      
PN_2_EXP twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 2 exposure map, combining the mirror vignetting, detector efficiency, bad pixels and CCD gaps.
The PSF weighted mean of the area of the subimages (radius 60 arcseconds) in the individual-band exposure maps.
real 4 s    
PN_2_FLUX twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 2 flux real 4 erg/cm**2/s    
PN_2_FLUX_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 2 flux error real 4 erg/cm**2/s    
PN_2_RATE twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 2 Count rates real 4 counts/s    
PN_2_RATE_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 2 Count rates error real 4 counts/s    
PN_2_VIG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 2 vignetting value. real 4      
PN_3_BG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 3 background map.
Made using a 12 x 12 nodes spline fit on the source-free individual-band images.
real 4 counts/pixel    
PN_3_DET_ML twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 3 Maximum likelihood real 4      
PN_3_EXP twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 3 exposure map, combining the mirror vignetting, detector efficiency, bad pixels and CCD gaps.
The PSF weighted mean of the area of the subimages (radius 60 arcseconds) in the individual-band exposure maps.
real 4 s    
PN_3_FLUX twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 3 flux real 4 erg/cm**2/s    
PN_3_FLUX_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 3 flux error real 4 erg/cm**2/s    
PN_3_RATE twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 3 Count rates real 4 counts/s    
PN_3_RATE_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 3 Count rates error real 4 counts/s    
PN_3_VIG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 3 vignetting value. real 4      
PN_4_BG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 4 background map.
Made using a 12 x 12 nodes spline fit on the source-free individual-band images.
real 4 counts/pixel    
PN_4_DET_ML twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 4 Maximum likelihood real 4      
PN_4_EXP twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 4 exposure map, combining the mirror vignetting, detector efficiency, bad pixels and CCD gaps.
The PSF weighted mean of the area of the subimages (radius 60 arcseconds) in the individual-band exposure maps.
real 4 s    
PN_4_FLUX twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 4 flux real 4 erg/cm**2/s    
PN_4_FLUX_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 4 flux error real 4 erg/cm**2/s    
PN_4_RATE twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 4 Count rates real 4 counts/s    
PN_4_RATE_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 4 Count rates error real 4 counts/s    
PN_4_VIG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 4 vignetting value. real 4      
PN_5_BG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 5 background map.
Made using a 12 x 12 nodes spline fit on the source-free individual-band images.
real 4 counts/pixel    
PN_5_DET_ML twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 5 Maximum likelihood real 4      
PN_5_EXP twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 5 exposure map, combining the mirror vignetting, detector efficiency, bad pixels and CCD gaps.
The PSF weighted mean of the area of the subimages (radius 60 arcseconds) in the individual-band exposure maps.
real 4 s    
PN_5_FLUX twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 5 flux real 4 erg/cm**2/s    
PN_5_FLUX_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 5 flux error real 4 erg/cm**2/s    
PN_5_RATE twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 5 Count rates real 4 counts/s    
PN_5_RATE_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 5 Count rates error real 4 counts/s    
PN_5_VIG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN band 5 vignetting value. real 4      
PN_8_CTS twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM Combined band source counts real 4 counts    
PN_8_CTS_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM Combined band source counts 1 σ error real 4 counts    
PN_8_DET_ML twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 8 Maximum likelihood real 4      
PN_8_FLUX twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 8 flux real 4 erg/cm**2/s    
PN_8_FLUX_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 8 flux error real 4 erg/cm**2/s    
PN_8_RATE twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 8 Count rates real 4 counts/s    
PN_8_RATE_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 8 Count rates error real 4 counts/s    
PN_9_DET_ML twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 9 Maximum likelihood real 4      
PN_9_FLUX twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 9 flux real 4 erg/cm**2/s    
PN_9_FLUX_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 9 flux error real 4 erg/cm**2/s    
PN_9_RATE twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 9 Count rates real 4 counts/s    
PN_9_RATE_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM PN band 9 Count rates error real 4 counts/s    
PN_CHI2PROB twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0 XMM The Chi² probability (based on the null hypothesis) that the source as detected by the PN camera is constant.
The Pearson approximation to Chi² for Poissonian data was used, in which the model is used as the estimator of its own variance . If more than one exposure (that is, time series) is available for this source the smallest value of probability was used.
real 4      
PN_CHI2PROB xmm3dr4 XMM The Chi² probability (based on the null hypothesis) that the source as detected by the PN camera is constant.
The Pearson approximation to Chi² for Poissonian data was used, in which the model is used as the estimator of its own variance . If more than one exposure (that is, time series) is available for this source the smallest value of probability was used.
float 8      
PN_FILTER twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0 XMM PN filter. The options are Thick, Medium, Thin1, Thin2, and Open, depending on the efficiency of the optical blocking. varchar 6      
PN_FILTER xmm3dr4 XMM PN filter. The options are Thick, Medium, Thin1, Thin2, and Open, depending on the efficiency of the optical blocking. varchar 50      
PN_FLAG twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0 XMM PN flag string made of the flags 1 - 12 (counted from left to right) for the PN source detection.
In case where the camera was not used in the source detection a dash is given. In case a source was not detected by the PN the flags are all set to False (default). Flag 10 is not used.
varchar 12      
PN_FLAG xmm3dr4 XMM PN flag string made of the flags 1 - 12 (counted from left to right) for the PN source detection.
In case where the camera was not used in the source detection a dash is given. In case a source was not detected by the PN the flags are all set to False (default). Flag 10 is not used.
varchar 50      
PN_FVAR xmm3dr4 XMM The fractional excess variance measured in the PN timeseries of the detection. Where multiple PN exposures exist, it is for the one giving the largest probability of variability (PN_CHI2PROB). This quantity provides a measure of the amplitude of variability in the timeseries, above purely statistical fluctuations. float 8      
PN_FVARERR xmm3dr4 XMM The error on the fractional excess variance for the PN timeseries of the detection (PN_FVAR). float 8      
PN_HR1 twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN hardness ratio between the bands 1 & 2
In the case where the rate in one band is 0.0 (i.e., too faint to be detected in this band) the hardness ratio will be -1 or +1 which is only a lower or upper limit, respectively.
real 4      
PN_HR1_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The 1 σ error of the PN hardness ratio between the bands 1 & 2 real 4      
PN_HR2 twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN hardness ratio between the bands 2 & 3
In the case where the rate in one band is 0.0 (i.e., too faint to be detected in this band) the hardness ratio will be -1 or +1 which is only a lower or upper limit, respectively.
real 4      
PN_HR2_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The 1 σ error of the PN hardness ratio between the bands 2 & 3 real 4      
PN_HR3 twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN hardness ratio between the bands 3 & 4
In the case where the rate in one band is 0.0 (i.e., too faint to be detected in this band) the hardness ratio will be -1 or +1 which is only a lower or upper limit, respectively.
real 4      
PN_HR3_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The 1 σ error of the PN hardness ratio between the bands 3 & 4 real 4      
PN_HR4 twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN hardness ratio between the bands 4 & 5
In the case where the rate in one band is 0.0 (i.e., too faint to be detected in this band) the hardness ratio will be -1 or +1 which is only a lower or upper limit, respectively.
real 4      
PN_HR4_ERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The 1 σ error of the PN hardness ratio between the bands 4 & 5 real 4      
PN_MASKFRAC twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PSF weighted mean of the detector coverage of a detection as derived from the detection mask.
Sources which have less than 0.15 of their PSF covered by the detector are considered as being not detected.
real 4      
PN_OFFAX twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN offaxis angle (the distance between the detection position and the onaxis position on the respective detector).
The offaxis angle for a camera can be larger than 15 arcminutes when the detection is located outside the FOV of that camera.
real 4 arcmin    
PN_ONTIME twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM The PN ontime value (the total good exposure time (after GTI filtering) of the CCD where the detection is positioned).
If a source position falls into CCD gaps or outside of the detector it will have a NULL given.
real 4 s    
PN_SUBMODE twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0 XMM PN observing mode. The options are full frame mode with the full FOV exposed (in two sub-modes), and large window mode with only parts of the FOV exposed. varchar 23      
PN_SUBMODE xmm3dr4 XMM PN observing mode. The options are full frame mode with the full FOV exposed (in two sub-modes), and large window mode with only parts of the FOV exposed. varchar 50      
pNearH iras_psc IRAS Number of nearby hours-confirmed point sources tinyint 1     meta.number
pNearW iras_psc IRAS Number of nearby weeks-confirmed point sources tinyint 1     meta.number
pNoise svNgc253Source SVNGC253v20100429 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise svOrionSource SVORIONv20100429 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise ultravistaSource ULTRAVISTAv20100429 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vhsSource VHSDR1 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vhsSource VHSDR2 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vhsSource VHSDR3 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vhsSource VHSv20120926 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vhsSource VHSv20130417 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vhsSource VHSv20140409 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vhsSource VHSv20150108 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise videoSource VIDEODR2 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise videoSource VIDEODR3 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise videoSource VIDEODR4 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise videoSource VIDEOv20100513 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise videoSource VIDEOv20111208 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vikingSource VIKINGDR2 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vikingSource VIKINGDR3 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vikingSource VIKINGDR4 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vikingSource VIKINGv20110714 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vikingSource VIKINGv20111019 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vikingSource VIKINGv20130417 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vikingSource VIKINGv20140402 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vikingSource VIKINGv20150421 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCDR2 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCDR3 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20110816 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20110909 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20120126 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20121128 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20130304 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20130805 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20140428 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20140903 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource VMCv20150309 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vmcSource, vmcSynopticSource VMCDR1 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vvvSource VVVDR2 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vvvSource VVVv20100531 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vvvSource VVVv20110718 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

pNoise vvvSource, vvvSynopticSource VVVDR1 Probability that the source is noise real 4     stat
Individual detection classifications are combined in the source merging process to produce a set of attributes for each merged source as follows. Presently, a basic classification table is defined that assigns reasonably accurate, self-consistent probability values for a given classification code:
FlagMeaning
Probability (%)
StarGalaxyNoiseSaturated
-9Saturated 0.0 0.0 5.095.0
-3Probable galaxy25.070.0 5.0 0.0
-2Probable star70.025.0 5.0 0.0
-1Star90.0 5.0 5.0 0.0
0Noise 5.0 5.090.0 0.0
+1Galaxy 5.090.0 5.0 0.0

Then, each separately available classification is combined for a merged source using Bayesian classification rules, assuming each datum is independent:

P(classk)=ΠiP(classk)i / ΣkΠiP(classk)i
where classk is one of star|galaxy|noise|saturated, and i denotes the ith single detection passband measurement available (the non-zero entries are necessary for the independent measures method to work, since some cases might otherwise be mutually exclusive). For example, if an object is classed in J|H|K as -1|-2|+1 it would have merged classification probabilities of pStar=73.5%, pGalaxy=26.2%, pNoise=0.3% and pSaturated=0.0%. Decision thresholds for the resulting discrete classification flag mergedClass are 90% for definitive and 70% for probable; hence the above example would be classified (not unreasonably) as probably a star (mergedClass=-2). An additional decision rule enforces mergedClass=-9 (saturated) when any individual classification flag indicates saturation.

polFlux nvssSource NVSS Integrated linearly polarized flux density real 4 mJy   PHOT_FLUX_LINEAR
polPA nvssSource NVSS [-90,90] The position angle of polFlux real 4 degress   POS_POS-EQ
pos iras_asc IRAS Position Angle from IRAS Source to Association (E of N) smallint 2 degrees   pos.posAng
posAng iras_psc IRAS Uncertainty ellipse position angle (East of North) smallint 2 degrees   pos.posAng
posAngle CurrentAstrometry SVNGC253v20100429 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry SVORIONv20100429 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry ULTRAVISTAv20100429 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VHSDR1 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VHSDR2 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VHSDR3 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VHSv20120926 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VHSv20130417 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VHSv20140409 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VHSv20150108 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIDEODR2 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIDEODR3 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIDEODR4 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIDEOv20100513 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIDEOv20111208 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIKINGDR2 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIKINGDR3 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIKINGDR4 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIKINGv20110714 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIKINGv20111019 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIKINGv20130417 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIKINGv20140402 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VIKINGv20150421 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCDR1 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCDR2 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCDR3 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20110816 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20110909 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20120126 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20121128 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20130304 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20130805 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20140428 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20140903 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VMCv20150309 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VVVDR1 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VVVDR2 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VVVv20100531 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry VVVv20110718 orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle CurrentAstrometry, ultravistaCurrentAstrometry, vhsCurrentAstrometry, videoCurrentAstrometry, vikingCurrentAstrometry, vmcCurrentAstrometry, vvvCurrentAstrometry VSAQC orientation of image x-axis to N-S float 8 Degrees -0.9999995e9 pos.posAng
posAngle RequiredMosaic VHSDR2 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VHSDR3 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VHSv20120926 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VHSv20130417 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VHSv20150108 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIDEODR2 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIDEODR3 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIDEODR4 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIDEOv20111208 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIKINGDR2 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIKINGDR3 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIKINGDR4 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIKINGv20110714 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIKINGv20111019 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIKINGv20130417 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VIKINGv20150421 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCDR1 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCDR3 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20110816 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20110909 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20120126 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20121128 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20130304 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20130805 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20140428 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20140903 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VMCv20150309 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VSAQC Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VVVDR1 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VVVDR2 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic VVVv20110718 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngle RequiredMosaic, RequiredStack, RequiredTile VHSDR1 Orientation of image x-axis to N-S real 4 deg -0.9999995e9  
posAngleTolerance Programme VHSDR1 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VHSDR2 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VHSDR3 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VHSv20120926 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VHSv20130417 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VHSv20150108 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIDEODR2 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIDEODR3 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIDEODR4 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIDEOv20111208 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIKINGDR2 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIKINGDR3 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIKINGDR4 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIKINGv20110714 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIKINGv20111019 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIKINGv20130417 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VIKINGv20150421 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCDR1 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCDR3 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20110816 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20110909 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20120126 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20121128 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20130304 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20130805 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20140428 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20140903 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VMCv20150309 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VSAQC The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VVVDR1 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VVVDR2 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
posAngleTolerance Programme VVVv20110718 The position angle tolerance used when creating deep stacks and tiles real 4 Degrees -0.9999995e9 ??
POSCOROK xmm3dr4 XMM Signifies whether catcorr obtained a statistically reliable solution or not (0 = False, 1 = True). This parameter is redundant in the sense that if REFCAT is positive, then a reliable solution was considered to have been found. bit 1      
POSERR twoxmm, twoxmm_v1_2, twoxmmi_dr3_v1_0, xmm3dr4 XMM Total position uncertainty in arcseconds calculated by combining the statistical error RADEC_ERR and the systematic error SYSERR as follows: POSERR = SQRT ( RADEC_ERR² + SYSERR² ). real 4 arcsec    
ppErrBits svNgc253Detection SVNGC253v20100429 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits svOrionDetection SVORIONv20100429 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits ultravistaDetection ULTRAVISTAv20100429 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vhsDetection VHSDR1 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vhsDetection VHSDR2 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vhsDetection VHSDR3 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vhsDetection VHSv20120926 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vhsDetection VHSv20130417 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vhsDetection VHSv20140409 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vhsDetection VHSv20150108 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits videoDetection VIDEODR2 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits videoDetection VIDEODR3 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits videoDetection VIDEODR4 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits videoDetection VIDEOv20100513 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits videoDetection VIDEOv20111208 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vikingDetection VIKINGDR2 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vikingDetection VIKINGDR3 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vikingDetection VIKINGDR4 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vikingDetection VIKINGv20110714 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vikingDetection VIKINGv20111019 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vikingDetection VIKINGv20130417 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vikingDetection VIKINGv20140402 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vikingDetection VIKINGv20150421 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCDR1 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCDR2 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCDR3 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20110816 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20110909 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20120126 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20121128 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20130304 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20130805 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20140428 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20140903 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vmcDetection VMCv20150309 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vvvDetection VVVDR1 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vvvDetection VVVDR2 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vvvDetection VVVv20100531 additional WFAU post-processing error bits int 4   0 meta.code
Post-processing error quality bit flags assigned to detections in the archive curation procedure for survey data. From least to most significant byte in the 4-byte integer attribute byte 0 (bits 0 to 7) corresponds to information on generally innocuous conditions that are nonetheless potentially significant as regards the integrity of that detection; byte 1 (bits 8 to 15) corresponds to warnings; byte 2 (bits 16 to 23) corresponds to important warnings; and finally byte 3 (bits 24 to 31) corresponds to severe warnings:
ByteBitDetection quality issue Threshold or bit mask Applies to
DecimalHexadecimal
0 4 Deblended 16 0x00000010 All VDFS catalogues
0 6 Bad pixel(s) in default aperture 64 0x00000040 All VDFS catalogues
0 7 Low confidence in default aperture 128 0x00000080 All VDFS catalogues
1 12 Lies within detector 16 region of a tile 4096 0x00001000 All catalogues from tiles
2 16 Close to saturated 65536 0x00010000 All VDFS catalogues
2 17 Photometric calibration probably subject to systematic error 131072 0x00020000 VVV only
2 22 Lies within a dither offset of the stacked frame boundary 4194304 0x00400000 All catalogues
2 23 Lies within the underexposed strip (or "ear") of a tile 8388608 0x00800000 All catalogues from tiles
3 24 Lies within an underexposed region of a tile due to missing detector 16777216 0x01000000 All catalogues from tiles

In this way, the higher the error quality bit flag value, the more likely it is that the detection is spurious. The decimal threshold (column 4) gives the minimum value of the quality flag for a detection having the given condition (since other bits in the flag may be set also; the corresponding hexadecimal value, where each digit corresponds to 4 bits in the flag, can be easier to compute when writing SQL queries to test for a given condition). For example, to exclude all Ks band sources in the VHS having any error quality condition other than informational ones, include a predicate ... AND kppErrBits ≤ 255. See the SQL Cookbook and other online pages for further information.
ppErrBits vvvListRemeasurement VVVv20100531 additional WFAU post-processing error bits int 4   0 meta.code
ppErrBits vvvListRemeasurement VVVv20110718 additional WFAU post-processing error bits int 4   0 meta.code
ppErrBitsStatus ProgrammeFrame SVNGC253v20100429 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame SVORIONv20100429 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame ULTRAVISTAv20100429 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VHSDR1 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VHSDR2 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VHSDR3 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VHSv20120926 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VHSv20130417 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VHSv20140409 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VHSv20150108 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIDEODR2 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIDEODR3 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIDEODR4 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIDEOv20100513 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIDEOv20111208 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIKINGDR2 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIKINGDR3 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIKINGDR4 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIKINGv20110714 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIKINGv20111019 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIKINGv20130417 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIKINGv20140402 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VIKINGv20150421 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCDR1 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCDR2 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCDR3 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20110816 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20110909 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20120126 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20121128 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20130304 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20130805 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20140428 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20140903 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VMCv20150309 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VSAQC Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VVVDR1 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VVVDR2 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VVVv20100531 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
ppErrBitsStatus ProgrammeFrame VVVv20110718 Bit flag to denote whether detection quality flagging has been done on this multiframe for this programme. int 4   0  
previewv Multiframe SVNGC253v20100429 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe SVORIONv20100429 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe ULTRAVISTAv20100429 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VHSDR1 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VHSDR2 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VHSDR3 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VHSv20120926 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VHSv20130417 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VHSv20140409 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VHSv20150108 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIDEODR2 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIDEODR3 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIDEODR4 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIDEOv20100513 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIDEOv20111208 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIKINGDR2 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIKINGDR3 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIKINGDR4 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIKINGv20110714 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIKINGv20111019 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIKINGv20130417 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIKINGv20140402 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VIKINGv20150421 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCDR1 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCDR2 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCDR3 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20110816 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20110909 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20120126 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20121128 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20130304 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20130805 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20140428 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20140903 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VMCv20150309 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VSAQC Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VVVDR1 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VVVDR2 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VVVv20100531 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv Multiframe VVVv20110718 Version of previ {image primary HDU keyword: PREVIEWV} varchar 64   NONE  
previewv ultravistaMultiframe, vhsMultiframe, videoMultiframe, vikingMultiframe, vmcMultiframe, vvvMultiframe VSAQC Version of previ varchar 64   NONE  
priFlgLb rosat_bsc, rosat_fsc ROSAT priority flag L-broad tinyint 1     meta.code
priFlgLh rosat_bsc, rosat_fsc ROSAT priority flag L-hard tinyint 1     meta.code
priFlgLs rosat_bsc, rosat_fsc ROSAT priority flag L-soft tinyint 1     meta.code
priFlgMb rosat_bsc, rosat_fsc ROSAT priority flag M-broad tinyint 1     meta.code
priFlgMh rosat_bsc, rosat_fsc ROSAT priority flag M-hard tinyint 1     meta.code
priFlgMs rosat_bsc, rosat_fsc ROSAT priority flag M-soft tinyint 1     meta.code
PRIORITY agntwomass, denisi, denisj, durukst, fsc, hes, hipass, nvss, rass, shapley, sumss, supercos, twomass SIXDF survey weight smallint 2      
priOrSec svNgc253Source SVNGC253v20100429 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec svOrionSource SVORIONv20100429 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec ultravistaSource ULTRAVISTAv20100429 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec ultravistaSourceRemeasurement ULTRAVISTAv20100429 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vhsSource VHSDR1 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vhsSource VHSDR2 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vhsSource VHSDR3 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vhsSource VHSv20120926 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vhsSource VHSv20130417 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vhsSource VHSv20140409 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vhsSource VHSv20150108 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vhsSourceRemeasurement VHSDR1 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec videoSource VIDEODR2 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec videoSource VIDEODR3 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec videoSource VIDEODR4 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec videoSource VIDEOv20100513 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec videoSource VIDEOv20111208 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec videoSourceRemeasurement VIDEOv20100513 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSource VIKINGDR2 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSource VIKINGDR3 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSource VIKINGDR4 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSource VIKINGv20110714 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSource VIKINGv20111019 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSource VIKINGv20130417 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSource VIKINGv20140402 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSource VIKINGv20150421 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSourceRemeasurement VIKINGv20110714 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vikingSourceRemeasurement VIKINGv20111019 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCDR1 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCDR2 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCDR3 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20110816 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20110909 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20120126 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20121128 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20130304 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20130805 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20140428 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20140903 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSource VMCv20150309 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSourceRemeasurement VMCv20110816 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vmcSourceRemeasurement VMCv20110909 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vvvSource VVVDR1 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vvvSource VVVDR2 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vvvSource VVVv20100531 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vvvSource VVVv20110718 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates). bigint 8   -99999999 meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vvvSourceRemeasurement VVVv20100531 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
priOrSec vvvSourceRemeasurement VVVv20110718 Seam code for a unique (=0) or duplicated (!=0) source (eg. flags overlap duplicates) bigint 8     meta.code
Because of the spacing of the detectors in VIRCam, and the restrictions on guide star brightness, there will always be overlap regions between adjacent frame sets. Source merging is done on a set-by-set basis; hence after source merging there are usually a small number of duplicate sources in the table. A process known as seaming takes place after source merging is complete, whereby duplicates are identified and flagged. The flagging attribute is priOrSec, and the meaning of the flag is quite simple: if a source is not found to be duplicated in overlap regions, then priOrSec=0; if a source is duplicated, then priOrSec will be set to the frameSetID of the source that should be considered the best one to use out of the set of duplicates. Presently, the choice of which is best is made on the basis of proximity to the optical axis of the camera, the assumption being that this will give the best quality image in general. So, if a particular source has a non-zero priOrSec that is set to it's own value of frameSetID, then this indicates that there is a duplicate elsewhere in the table, but this is the one that should be selected as the best (i.e. this is the primary source). On the other hand, if a source has a non-zero value of priOrSec that is set a different frameSetID than that of the source in question, then this indicates that this source should be considered as a secondary duplicate of a source who's primary is actually to be found in the frame set pointed to by that value of frameSetID. Hence, the WHERE clause for selecting out a seamless, best catalogue is of the form WHERE ... AND (priOrSec=0 OR priOrSec=frameSetID).
PROB grs_ngpSource, grs_ranSource, grs_sgpSource TWODFGRS psi classification parameter: for eyeballed galaxies: psi*1000 = (10000 + abs(jon) + psi*100); for eyeballed non-galaxies: psi*1000 = -(10000 + abs(jon) + psi*100) real 4      
productID EpochFrameStatus, ProgrammeFrame VSAQC Product ID of deep stack frame (or intermediate stack if used as a deep stack). {image primary HDU keyword: PRODID} bigint 8   -99999999  
productID RequiredDiffImage SVNGC253v20100429 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage SVORIONv20100429 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage ULTRAVISTAv20100429 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VHSDR1 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VHSDR2 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VHSDR3 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VHSv20120926 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VHSv20130417 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VHSv20150108 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIDEODR2 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIDEODR3 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIDEODR4 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIDEOv20100513 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIDEOv20111208 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIKINGDR2 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIKINGDR3 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIKINGDR4 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIKINGv20110714 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIKINGv20111019 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIKINGv20130417 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VIKINGv20150421 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCDR1 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCDR3 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20110816 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20110909 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20120126 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20121128 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20130304 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20130805 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20140428 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20140903 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VMCv20150309 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VSAQC A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VVVDR1 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VVVDR2 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VVVv20100531 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredDiffImage VVVv20110718 A unique identifier assigned to each required difference image product entry int 4     ??
productID RequiredMergeLogMultiEpoch, RequiredStack, RequiredTile VSAQC A unique identifier assigned to each required stack product entry int 4     ??
productID RequiredMosaic SVNGC253v20100429 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic SVORIONv20100429 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic ULTRAVISTAv20100429 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VHSDR1 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VHSDR2 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VHSDR3 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VHSv20120926 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VHSv20130417 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VHSv20150108 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIDEODR2 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIDEODR3 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIDEODR4 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIDEOv20100513 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIDEOv20111208 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIKINGDR2 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIKINGDR3 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIKINGDR4 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIKINGv20110714 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIKINGv20111019 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIKINGv20130417 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VIKINGv20150421 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCDR1 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCDR3 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20110816 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20110909 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20120126 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20121128 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20130304 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20130805 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20140428 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20140903 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VMCv20150309 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VSAQC A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VVVDR1 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VVVDR2 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VVVv20100531 A unique identifier assigned to each required mosaic product entry int 4     ??
productID RequiredMosaic VVVv20110718 A unique identifier assigned to each required mosaic product entry int 4     ??
productType EpochFrameStatus VSAQC Product type (stack,tile,mosaic) varchar 16   NONE  
productType ExternalProduct VHSv20150108 The product type within the imported directory varchar 16     ??
productType ExternalProduct VIDEODR4 The product type within the imported directory varchar 16     ??
productType ExternalProduct VIDEOv20111208 The product type within the imported directory varchar 16     ??
productType ExternalProduct VIKINGDR4 The product type within the imported directory varchar 16     ??
productType ExternalProduct VIKINGv20150421 The product type within the imported directory varchar 16     ??
productType ExternalProduct VMCDR3 The product type within the imported directory varchar 16     ??
productType ExternalProduct VMCv20140428 The product type within the imported directory varchar 16     ??
productType ExternalProduct VMCv20140903 The product type within the imported directory varchar 16     ??
productType ExternalProduct VMCv20150309 The product type within the imported directory varchar 16     ??
productType ExternalProduct VSAQC The product type within the imported directory varchar 16     ??
productType ExternalProduct, ExternalProductCatalogue VHSDR3 The product type within the imported directory varchar 16     ??
productType RequiredListDrivenProduct VHSv20130417 product type of file to be extracted (stack, tile, mosaic) varchar 8   NONE  
productType RequiredListDrivenProduct VIKINGv20130417 product type of file to be extracted (stack, tile, mosaic) varchar 8   NONE  
productType RequiredListDrivenProduct VMCv20130805 product type of file to be extracted (stack, tile, mosaic) varchar 8   NONE  
productType RequiredMergeLogMultiEpoch VSAQC Product type (stack,tile,mosaic) varchar 16      
PROGID agntwomass, denisi, denisj, durukst, fsc, hes, hipass, nvss, rass, shapley, sumss, supercos, twomass SIXDF programme ID smallint 2      
PROGID target SIXDF highest priority programme ID smallint 2      
PROGID_R spectra SIXDF programme ID in R frame varchar 32      
PROGID_V spectra SIXDF programme ID in V frame varchar 32      
programmeID EpochFrameStatus, ProgrammeFrame VSAQC VSA assigned programme UID {image primary HDU keyword: HIERARCH ESO OBS PROG ID} int 4   -99999999 meta.id
programmeID ExternalProduct VHSv20150108 the unique programme ID int 4     meta.id
programmeID ExternalProduct VIDEODR4 the unique programme ID int 4     meta.id
programmeID ExternalProduct VIKINGDR4 the unique programme ID int 4     meta.id
programmeID ExternalProduct VIKINGv20150421 the unique programme ID int 4     meta.id
programmeID ExternalProduct VMCDR3 the unique programme ID int 4     meta.id
programmeID ExternalProduct VMCv20140428 the unique programme ID int 4     meta.id
programmeID ExternalProduct VMCv20140903 the unique programme ID int 4     meta.id
programmeID ExternalProduct VMCv20150309 the unique programme ID int 4     meta.id
programmeID ExternalProduct, ExternalProductCatalogue, ProductLinks, ProgrammeCurationHistory, ProgrammeTable, RequiredDiffImage, RequiredFilters, RequiredMosaic, RequiredNeighbours, RequiredStack, RequiredTile VHSDR3 the unique programme ID int 4     meta.id
programmeID ExternalProduct, RequiredListDrivenProduct VIDEOv20111208 the unique programme ID int 4     meta.id
programmeID ExternalProduct, RequiredMergeLogMultiEpoch VSAQC the unique programme ID int 4     meta.id
programmeID Programme SVNGC253v20100429 UID of the archived programme coded as above int 4     meta.id
programmeID Programme SVORIONv20100429 UID of the archived programme coded as above int 4     meta.id
programmeID Programme ULTRAVISTAv20100429 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VHSDR1 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VHSDR2 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VHSDR3 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VHSv20120926 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VHSv20130417 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VHSv20150108 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIDEODR2 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIDEODR3 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIDEODR4 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIDEOv20100513 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIDEOv20111208 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIKINGDR2 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIKINGDR3 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIKINGDR4 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIKINGv20110714 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIKINGv20111019 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIKINGv20130417 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VIKINGv20150421 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCDR1 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCDR3 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20110816 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20110909 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20120126 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20121128 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20130304 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20130805 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20140428 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20140903 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VMCv20150309 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VSAQC UID of the archived programme coded as above int 4     meta.id
programmeID Programme VVVDR1 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VVVDR2 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VVVv20100531 UID of the archived programme coded as above int 4     meta.id
programmeID Programme VVVv20110718 UID of the archived programme coded as above int 4     meta.id
programmeID SurveyProgrammes SVNGC253v20100429 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes SVORIONv20100429 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes ULTRAVISTAv20100429 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VHSDR1 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VHSDR2 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VHSDR3 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VHSv20120926 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VHSv20130417 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VHSv20150108 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIDEODR2 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIDEODR3 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIDEODR4 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIDEOv20100513 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIDEOv20111208 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIKINGDR2 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIKINGDR3 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIKINGDR4 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIKINGv20110714 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIKINGv20111019 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIKINGv20130417 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VIKINGv20150421 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCDR1 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCDR3 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20110816 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20110909 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20120126 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20121128 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20130304 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20130805 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20140428 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20140903 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VMCv20150309 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VSAQC VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VVVDR1 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VVVDR2 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VVVv20100531 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
programmeID SurveyProgrammes VVVv20110718 VSA assigned programme UID {image primary HDU keyword: PROJECT} int 4   -99999999 meta.id
project Multiframe SVNGC253v20100429 Time-allocation code varchar 64   NONE meta.bib
project Multiframe SVORIONv20100429 Time-allocation code varchar 64   NONE meta.bib
project Multiframe ULTRAVISTAv20100429 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VHSDR1 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VHSDR2 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VHSDR3 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VHSv20120926 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VHSv20130417 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VHSv20140409 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VHSv20150108 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIDEODR2 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIDEODR3 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIDEODR4 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIDEOv20100513 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIDEOv20111208 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIKINGDR2 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIKINGDR3 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIKINGDR4 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIKINGv20110714 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIKINGv20111019 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIKINGv20130417 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIKINGv20140402 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VIKINGv20150421 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCDR1 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCDR2 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCDR3 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20110816 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20110909 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20120126 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20121128 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20130304 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20130805 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20140428 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20140903 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VMCv20150309 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VVVDR1 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VVVDR2 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VVVv20100531 Time-allocation code varchar 64   NONE meta.bib
project Multiframe VVVv20110718 Time-allocation code varchar 64   NONE meta.bib
project Multiframe, ultravistaMultiframe, vhsMultiframe, videoMultiframe, vikingMultiframe, vmcMultiframe, vvvMultiframe VSAQC Time-allocation code varchar 64   NONE meta.bib
projection RequiredMosaic SVNGC253v20100429 CASU mosaic tool option to specify output WCS projection type (TAN for gnomonic, ZPN for zenithal polynomial) varchar 3     ??
projection RequiredMosaic SVORIONv20100429 CASU mosaic tool option to specify output WCS projection type (TAN for gnomonic, ZPN for zenithal polynomial) varchar 3     ??
projection RequiredMosaic ULTRAVISTAv20100429 CASU mosaic tool option to specify output WCS projection type (TAN for gnomonic, ZPN for zenithal polynomial) varchar 3     ??
projp1 CurrentAstrometry SVNGC253v20100429 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry SVORIONv20100429 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry ULTRAVISTAv20100429 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VHSDR1 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VHSDR2 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VHSDR3 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VHSv20120926 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VHSv20130417 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VHSv20140409 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VHSv20150108 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIDEODR2 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIDEODR3 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIDEODR4 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIDEOv20100513 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIDEOv20111208 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIKINGDR2 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIKINGDR3 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIKINGDR4 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIKINGv20110714 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIKINGv20111019 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIKINGv20130417 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIKINGv20140402 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VIKINGv20150421 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCDR1 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCDR2 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCDR3 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20110816 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20110909 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20120126 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20121128 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20130304 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20130805 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20140428 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20140903 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VMCv20150309 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VSAQC Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VVVDR1 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VVVDR2 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VVVv20100531 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 CurrentAstrometry VVVv20110718 Old style WCS {image extension keyword: PROJP1} float 8   -9.999995e+08  
projp1 ultravistaCurrentAstrometry, vhsCurrentAstrometry, videoCurrentAstrometry, vikingCurrentAstrometry, vmcCurrentAstrometry, vvvCurrentAstrometry VSAQC Old style WCS float 8   -9.999995e+08  
projp3 CurrentAstrometry SVNGC253v20100429 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry SVORIONv20100429 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry ULTRAVISTAv20100429 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VHSDR1 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VHSDR2 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VHSDR3 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VHSv20120926 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VHSv20130417 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VHSv20140409 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VHSv20150108 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIDEODR2 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIDEODR3 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIDEODR4 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIDEOv20100513 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIDEOv20111208 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIKINGDR2 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIKINGDR3 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIKINGDR4 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIKINGv20110714 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIKINGv20111019 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIKINGv20130417 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIKINGv20140402 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VIKINGv20150421 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCDR1 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCDR2 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCDR3 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20110816 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20110909 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20120126 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20121128 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20130304 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20130805 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20140428 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20140903 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VMCv20150309 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VSAQC Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VVVDR1 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VVVDR2 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VVVv20100531 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 CurrentAstrometry VVVv20110718 Old style WCS {image extension keyword: PROJP3} float 8   -9.999995e+08  
projp3 ultravistaCurrentAstrometry, vhsCurrentAstrometry, videoCurrentAstrometry, vikingCurrentAstrometry, vmcCurrentAstrometry, vvvCurrentAstrometry VSAQC Old style WCS float 8   -9.999995e+08  
projp5 CurrentAstrometry SVNGC253v20100429 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry SVORIONv20100429 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry ULTRAVISTAv20100429 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VHSDR1 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VHSDR2 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VHSDR3 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VHSv20120926 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VHSv20130417 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VHSv20140409 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VHSv20150108 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIDEODR2 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIDEODR3 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIDEODR4 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIDEOv20100513 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIDEOv20111208 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIKINGDR2 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIKINGDR3 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIKINGDR4 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIKINGv20110714 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIKINGv20111019 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIKINGv20130417 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIKINGv20140402 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VIKINGv20150421 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCDR1 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCDR2 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCDR3 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20110816 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20110909 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20120126 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20121128 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20130304 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20130805 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20140428 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20140903 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VMCv20150309 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VSAQC Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VVVDR1 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VVVDR2 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VVVv20100531 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 CurrentAstrometry VVVv20110718 Old style WCS {image extension keyword: PROJP5} float 8   -9.999995e+08  
projp5 ultravistaCurrentAstrometry, vhsCurrentAstrometry, videoCurrentAstrometry, vikingCurrentAstrometry, vmcCurrentAstrometry, vvvCurrentAstrometry VSAQC Old style WCS float 8   -9.999995e+08  
propPeriod Programme SVNGC253v20100429 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme SVORIONv20100429 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme ULTRAVISTAv20100429 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VHSDR1 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VHSDR2 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VHSDR3 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VHSv20120926 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VHSv20130417 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VHSv20150108 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIDEODR2 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIDEODR3 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIDEODR4 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIDEOv20100513 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIDEOv20111208 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIKINGDR2 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIKINGDR3 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIKINGDR4 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIKINGv20110714 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIKINGv20111019 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIKINGv20130417 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VIKINGv20150421 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCDR1 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCDR3 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20110816 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20110909 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20120126 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20121128 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20130304 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20130805 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20140428 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20140903 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VMCv20150309 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VSAQC the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VVVDR1 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VVVDR2 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VVVv20100531 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
propPeriod Programme VVVv20110718 the proprietory period for any data taken for this programme in months, e.g. 12 for open time. int 4 months   time.period
proprietary Survey SVNGC253v20100429 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey SVORIONv20100429 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey ULTRAVISTAv20100429 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VHSDR1 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VHSDR2 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VHSDR3 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VHSv20120926 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VHSv20130417 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VHSv20150108 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIDEODR2 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIDEODR3 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIDEODR4 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIDEOv20100513 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIDEOv20111208 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIKINGDR2 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIKINGDR3 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIKINGDR4 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIKINGv20110714 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIKINGv20111019 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIKINGv20130417 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VIKINGv20150421 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCDR1 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCDR3 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCv20110816 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCv20110909 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCv20120126 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCv20121128 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCv20130304 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCv20130805 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary Survey VMCv20140428 Logical flag indicating whether a survey is proprietary or not (1=yes; 0=no) tinyint 1     ??
proprietary