- Bitmask Primer
- Bitmasks in CAS
- Bitmasks in IDL
- PHOTO FLAGS1
- PHOTO FLAGS2
- RESOLVE_STATUS
- CALIB_STATUS
- IMAGE_STATUS
- LEGACY_TARGET1
- LEGACY_TARGET2
- SEGUE1_TARGET1
- SEGUE1_TARGET2
- SEGUE2_TARGET1
- SEGUE2_TARGET2
- SPECIAL_TARGET1
- SPECIAL_TARGET2
- BOSS_TARGET1
- ANCILLARY_TARGET1
- ANCILLARY_TARGET2
- BOSSTILE_STATUS
- FLUXMATCH_STATUS
- SPECTRUM PIXMASK
- ZWARNING
- APOGEE_TARGET1
- APOGEE_TARGET2
- APOGEE_PIXMASK
- APOGEE_STARFLAG
- APOGEE_ASPCAPFLAG
- APOGEE_PARAMFLAG
SDSS-III Bitmasks in CAS
As for SDSS-I and -II, the SDSS-III CAS allows the user to check values of a bitmask. See the links on the side for detailed information on the meanings of all bit masks.
Checking bitmasks can be included in the where
clause
of an SQL query, using a form such as:
(flagname & value) != 0
where & is a bit-wise AND operator. Similarly, | is an OR operator. A simple example is as follows:
SELECT plate, mjd, fiberid FROM specObjAll WHERE (zWarning & 128) !=0
The bitmask value can also be specified in hex. Incidentally, take care to not use ">0", since if the sign bit is set that check can fail.
More usage of bitmasks in CAS is documented in a set of examples on the CAS site. Some values of each bitmask are also enumerated there as part of the Data Constants documentation in the schema browser.
As a final note, you will see in some of the documentation that
there are some functions that one can use to return the values
associated with each bitmask (e.g. fPhotoFlags
). Those
are useful for readability; however, note that they come with a
performance cost, and that using the bitmask value explicitly will
result in faster queries.