Create Masks as ArcGIS Rasters for CoastWatch Images Listed in Table

Table to query.

Field containing the paths of the CoastWatch POES AVHRR CWF or HDF files.

Only CoastWatch POES AVHRR files are supported. Other CoastWatch files, such as those for the GOES satellite series, will be skipped and a warning will be reported.

Compressed files in a supported compression format will be automatically decompressed. Archives (e.g. .zip or .tar) must contain exactly one file, which must not be in a subdirectory.

Field containing the output rasters to create. The pixels will be 8-bit unsigned integers, where the value 1 indicates the pixel is masked.

If True, pixels that are not masked will be stored as NoData. If False, they will be stored as the value 0.

If True, pixels that are missing data will be masked.

The most common cause for missing data is the satellite swath not completely covering the region of interest. The pixels that could not be seen by the sensor when the satellite flew over will be marked as missing data.

If True, pixels that are classified as land by the CoastWatch graphics variable will be masked.

The graphics variable is obtained by invoking the CoastWatch Utilities cwgraphics program on the input file. I have observed that this program does not always produce a land mask that is 100% identical to the graphics variable contained by the input file. For example, when I executed cwgraphics on 2005_108_1841_n16_er.hdf, I noticed that several pixels, mostly near the edges of the images, differed from those obtained by viewing the graphics variable in 2005_108_1841_n16_er.hdf using the cdat program.

I do not know the reason for this discrepancy. My theory is that the cwgraphics program does not read the graphics variable from the input file at all. Rather, it only reads the geographic extent and then produces a new land mask from its database in the installation directory of the CoastWatch Utilities. Newer versions of the CoastWatch Utilities may include updated land masks that differ from those used by CoastWatch in the past. But this is only a theory. In any case, the discrepancy seems to be quite insignificant and should not affect most users.

Field containing the paths of the CoastWatch POES AVHRR CWF or HDF files that contain the cloud masks for the input files.

If you omit this parameter, this tool will try to obtain the cloud mask from the input CoastWatch file instead. This will also occur when you do specify a field for this parameter, but a given row contains NULL for that field. If no cloud mask can be obtained from whichever file is used, cloud masking will not be performed.

If you're processing only HDFs, you can probably omit this parameter. HDFs usually contain all of the variables for a given satellite pass, including the cloud mask, so it is not necessary to obtain it from a different file. If you're processing CWFs, you must specify a field for this parameter if you want cloud masking to be performed. If you're processing both HDFs and CWFs, the field can contain NULL for the HDFs.

Compressed files in a supported compression format will be automatically decompressed. Archives (e.g. .zip or .tar) must contain exactly one file, which must not be in a subdirectory.

Name of the CoastWatch variable to extract from the cloud mask file and use as the cloud mask (e.g. "cloud").

The current implementation of this tool was designed to operate on the 8-bit CLAVR cloud mask represented by the "cloud" variable in CoastWatch files. It was not designed to operate on the "cloudx" variable, which is a new experimental CLAVR-x cloud mask available in recent CoastWatch HDF files. Nonetheless, if you wish to operate on the cloudx variable, you can specify it instead of cloud, and pick mask options appropriate for it instead.

Field containing the paths of the CoastWatch POES AVHRR CWF or HDF files that contain the cloud solar zenith images (i.e. the "sun_zenith" variable) for the input files.

If you omit this parameter, this tool will try to obtain the solar zenith image from the input CoastWatch file instead. This will also occur when you do specify a field for this parameter, but a given row contains NULL for that field.

If you're processing only HDFs, you can probably omit this parameter. HDFs usually contain all of the variables for a given satellite pass, including the solar zenith (when sun is above the horizon), so it is not necessary to obtain it from a different file. If you're processing CWFs, you must specify a field for this parameter if you want cloud masking to be performed and you're processing images with a day/night scene time. If you're processing both HDFs and CWFs, the field can contain NULL for the HDFs.

Compressed files in a supported compression format will be automatically decompressed. Archives (e.g. .zip or .tar) must contain exactly one file, which must not be in a subdirectory.

According to CoastWatch researcher Peter Hollemans, when an image's scene time is "day", all pixels of the cloud mask use daytime cloud tests, and when it is "night", all pixels use nighttime cloud tests. When the scene time is "day/night", the decision of which tests to use is based on the solar zenith for that pixel.

According to Peter, for CoastWatch HDF files, pixels with a solar zenith > 80 degrees use the nighttime cloud tests, and <= 80 use the daytime cloud tests. This tool implements that logic. If you specify that cloud masking should be performed for a day/night image but no solar zenith image is available, this tool will assume that nighttime cloud tests were used for every pixel and a warning will be issued. For some reason, CoastWatch occasionally produces day/night images with no sun_zenith or other variables that are present in day images. My recollection is that Peter said it is safe to assume for these images that all pixels are nighttime.

The solar zenith image is ignored for scene times other than "day/night" (e.g. "day" or "night").

After some investigation, I find that the cloud mask pixels near the 80 degree solar zenith line are problematic, for two reasons:

• According to Peter, the solar zenith <= 80 cutoff line is not going to line up perfectly with the switch from daytime to nighttime cloud tests because the solar zenith angles are rounded to the nearest 0.01 when written to the HDF file so a few pixels with values of say 80.003 will get rounded to 80 even though they underwent processing with the nighttime cloud tests. Peter said, "I guess that's the flaw with storing angle data in HDF as scaled integers (that decision was mainly due to file size concerns)."

• The switch between daytime tests and nighttime tests does not manifest as a clean transition in the cloud mask pixels. The daytime pixels do not seem to cleanly abut the nighttime pixels. Rather, a strip of pixels with strange values raggedly separates the two. Peter said: "The apparent unclean transition between day and night tests is related to neighborhood functions. The uniformity tests use a 2x2 box of data values to the right and below a given value in the array to check for a condition being true, and the results of the uniformity test flag all pixels in the 2x2 box with the test results, regardless of whether all those pixels are day or nighttime. Both day and nighttime have uniformity tests, so the results of uniformity tests at the day/night boundary are mixed. The mixing is generally acceptable because the results are intended to be used for SST masking not cloud type evaluation and the mixing only occurs in cloudy conditions, not clear SST conditions."

Peter said he did not know what was done for CoastWatch day/night CWF files. I examined a few of these from the North East region, and it appeared that they also switched from daytime to nighttime cloud tests in the middle of the image. But the NOAA distribution site (http://www.class.noaa.gov) only appeared to have CWFs containing the sun_zenith variable for dates after late 1999.

Peter mentioned that the cwangles program from the CoastWatch Utilities could compute the solar zenith, but the values would only be approximate beacuse the program assumed that all pixels were obtained by the sensor at the same moment in time. I tried this approach but the 80 degree solar zenith line did not line up with the line where the cloud tests appeared to switch. Because of this, I do not believe that day/night CWF files will be useable for users who want to use some cloud tests and ignore others.

Name of the CoastWatch variable to extract from the solar zenith file and use as the solar zenith image (e.g. "sun_zenith").

If True, daytime pixels that failed the CLAVR-1 Reflective Gross Cloud Test (bit 1 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 test is used for both CWF and HDF files, but for HDF files, the CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Reflectance Uniformity Test (bit 2 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 test is used for both CWF and HDF files, but for HDF files, the CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Reflectance Ratio Cloud Test (bit 3 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 test is used for both CWF and HDF files, but for HDF files, the CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Channel 3 Albedo Test (bit 4 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Thermal Uniformity Test (bit 5 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Four Minus Five Test (bit 6 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Thermal Gross Cloud Test (bit 7 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If a value is provided, daytime pixels with a cloud mask value greater than this value will be masked.

The CoastWatch cloud mask is a bitmask, where each bit represents the success (0) or failure (1) of a given CLAVR cloud test. Thus the cloud mask values are NOT intended to be interpreted as range, like a spectrum, where 0 represents "very clear" and 255 represents "very cloudy". Nevertheless, some users of this tool determined that for their study the best tradeoff between minimizing SST error and minimizing the number of pixels masked by clouds was obtained by masking all pixels where the cloud mask exceeded a certain value. This option was implemented specifically for those users and is not recommended for general use. If you do use this option, be sure to study many cloud mask images before selecting a value.

If a value is provided both for this parameter and for the cloud test bits specified by the previous parameters, all of these parameters will be effective. In other words, a cloudy pixel can be masked by failing a specific cloud test, or by exceeding the minimum cloud mask value, or both. .

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter. For more information about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Thermal Gross Cloud Test (bit 1 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Thermal Uniformity Test (bit 2 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Uniform Low Stratus Test (bit 3 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Four Minus Five Test (bit 4 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Cirrus Test (bit 5 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-x Channel 3B Albedo Test (bit 6 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, this test was not used for CoastWatch CWF files and thus bit 6 will always be 0, indicating success, for CWF nighttime cloud mask pixels.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-x Channel 3B Albedo Uniformity Test (bit 7 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, this test was not used for CoastWatch CWF files and thus bit 7 will always be 0, indicating success, for CWF nighttime cloud mask pixels.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If a value is provided, nighttime pixels with a cloud mask value greater than this value will be masked.

The CoastWatch cloud mask is a bitmask, where each bit represents the success (0) or failure (1) of a given CLAVR cloud test. Thus the cloud mask values are NOT intended to be interpreted as range, like a spectrum, where 0 represents "very clear" and 255 represents "very cloudy". Nevertheless, some users of this tool determined that for their study the best tradeoff between minimizing SST error and minimizing the number of pixels masked by clouds was obtained by masking all pixels where the cloud mask exceeded a certain value. This option was implemented specifically for those users and is not recommended for general use. If you do use this option, be sure to study many cloud mask images before selecting a value.

If a value is provided both for this parameter and for the cloud test bits specified by the previous parameters, all of these parameters will be effective. In other words, a cloudy pixel can be masked by failing a specific cloud test, or by exceeding the minimum cloud mask value, or both. .

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter. For more information about the cloud tests, please see the CoastWatch and CLAVR documentation.

Minimum number of neighbors that a cloudy pixel must have in order for that pixel to be masked.

You can use this option to ignore isolated cloudy pixels that are not clumped together. For example, if you specify the value 1, cloudy pixels will be ignored and not used in the masking process unless at least one of their eight neighbors is also cloudy.

If a neighbor is not cloudy but it is masked for some other reason (e.g. it is land), it does not count as being cloudy.

This option is ignored when cloud masking is not performed.

SQL WHERE clause expression that specifies the subset of rows to process. If this parameter is not provided, all of the rows will be processed. If this parameter is provided but the underlying database does not support WHERE clauses, an error will be raised.

The exact syntax of this expression depends on the underlying database. ESRI recommends you reference fields using the following syntax:

• If you're querying ArcInfo coverages, shapefiles, INFO tables or dBASE tables (.dbf files), enclose field names in double quotes in the SQL expression: "MY_FIELD".

• If you're querying Microsoft Access tables or personal geodatabase tables, enclose field names in square brackets: [MY_FIELD].

• If you're querying ArcSDE geodatabase tables, an ArcIMS feature class, or an ArcIMS image service sublayer, don't enclose field names: MY_FIELD.

Fields that will be used to sort the rows (i.e., the columns specified in the ORDER BY clause of a SQL SELECT statement). If no fields are provided, the rows will be sorted in the default order determined by the underlying database. If this parameter is provided but this computer is not running ArcGIS 9.2 or later or the underlying database does not support ORDER BY clauses, an error will be raised.

In addition to specifying the ORDER BY fields, you must also specify the sort direction for each field.

List of strings, either 'Ascending' or 'Descending', that specify the sort directions for the ORDER BY fields. If this parameter is provided but this computer is not running ArcGIS 9.2 or later or the underlying database does not support ORDER BY clauses, an error will be raised.

If True, conversion will be skipped for output rasters that already exist.

Base path to prepend to relative paths.

If a base path is provided, it will be prepended to any relative paths that are obtained from the fields that list the inputs (and outputs, if this tool has outputs). If a base path is not provided, the workspace containing the table will be prepended instead.

Table to query.

Field containing the paths of the CoastWatch POES AVHRR CWF or HDF files.

Only CoastWatch POES AVHRR files are supported. Other CoastWatch files, such as those for the GOES satellite series, will be skipped and a warning will be reported.

Compressed files in a supported compression format will be automatically decompressed. Archives (e.g. .zip or .tar) must contain exactly one file, which must not be in a subdirectory.

Field containing the output rasters to create. The pixels will be 8-bit unsigned integers, where the value 1 indicates the pixel is masked.

If True, pixels that are not masked will be stored as NoData. If False, they will be stored as the value 0.

If True, pixels that are missing data will be masked.

The most common cause for missing data is the satellite swath not completely covering the region of interest. The pixels that could not be seen by the sensor when the satellite flew over will be marked as missing data.

If True, pixels that are classified as land by the CoastWatch graphics variable will be masked.

The graphics variable is obtained by invoking the CoastWatch Utilities cwgraphics program on the input file. I have observed that this program does not always produce a land mask that is 100% identical to the graphics variable contained by the input file. For example, when I executed cwgraphics on 2005_108_1841_n16_er.hdf, I noticed that several pixels, mostly near the edges of the images, differed from those obtained by viewing the graphics variable in 2005_108_1841_n16_er.hdf using the cdat program.

I do not know the reason for this discrepancy. My theory is that the cwgraphics program does not read the graphics variable from the input file at all. Rather, it only reads the geographic extent and then produces a new land mask from its database in the installation directory of the CoastWatch Utilities. Newer versions of the CoastWatch Utilities may include updated land masks that differ from those used by CoastWatch in the past. But this is only a theory. In any case, the discrepancy seems to be quite insignificant and should not affect most users.

Field containing the paths of the CoastWatch POES AVHRR CWF or HDF files that contain the cloud masks for the input files.

If you omit this parameter, this tool will try to obtain the cloud mask from the input CoastWatch file instead. This will also occur when you do specify a field for this parameter, but a given row contains NULL for that field. If no cloud mask can be obtained from whichever file is used, cloud masking will not be performed.

If you're processing only HDFs, you can probably omit this parameter. HDFs usually contain all of the variables for a given satellite pass, including the cloud mask, so it is not necessary to obtain it from a different file. If you're processing CWFs, you must specify a field for this parameter if you want cloud masking to be performed. If you're processing both HDFs and CWFs, the field can contain NULL for the HDFs.

Compressed files in a supported compression format will be automatically decompressed. Archives (e.g. .zip or .tar) must contain exactly one file, which must not be in a subdirectory.

Name of the CoastWatch variable to extract from the cloud mask file and use as the cloud mask (e.g. "cloud").

The current implementation of this tool was designed to operate on the 8-bit CLAVR cloud mask represented by the "cloud" variable in CoastWatch files. It was not designed to operate on the "cloudx" variable, which is a new experimental CLAVR-x cloud mask available in recent CoastWatch HDF files. Nonetheless, if you wish to operate on the cloudx variable, you can specify it instead of cloud, and pick mask options appropriate for it instead.

Field containing the paths of the CoastWatch POES AVHRR CWF or HDF files that contain the cloud solar zenith images (i.e. the "sun_zenith" variable) for the input files.

If you omit this parameter, this tool will try to obtain the solar zenith image from the input CoastWatch file instead. This will also occur when you do specify a field for this parameter, but a given row contains NULL for that field.

If you're processing only HDFs, you can probably omit this parameter. HDFs usually contain all of the variables for a given satellite pass, including the solar zenith (when sun is above the horizon), so it is not necessary to obtain it from a different file. If you're processing CWFs, you must specify a field for this parameter if you want cloud masking to be performed and you're processing images with a day/night scene time. If you're processing both HDFs and CWFs, the field can contain NULL for the HDFs.

Compressed files in a supported compression format will be automatically decompressed. Archives (e.g. .zip or .tar) must contain exactly one file, which must not be in a subdirectory.

According to CoastWatch researcher Peter Hollemans, when an image's scene time is "day", all pixels of the cloud mask use daytime cloud tests, and when it is "night", all pixels use nighttime cloud tests. When the scene time is "day/night", the decision of which tests to use is based on the solar zenith for that pixel.

According to Peter, for CoastWatch HDF files, pixels with a solar zenith > 80 degrees use the nighttime cloud tests, and <= 80 use the daytime cloud tests. This tool implements that logic. If you specify that cloud masking should be performed for a day/night image but no solar zenith image is available, this tool will assume that nighttime cloud tests were used for every pixel and a warning will be issued. For some reason, CoastWatch occasionally produces day/night images with no sun_zenith or other variables that are present in day images. My recollection is that Peter said it is safe to assume for these images that all pixels are nighttime.

The solar zenith image is ignored for scene times other than "day/night" (e.g. "day" or "night").

After some investigation, I find that the cloud mask pixels near the 80 degree solar zenith line are problematic, for two reasons:

• According to Peter, the solar zenith <= 80 cutoff line is not going to line up perfectly with the switch from daytime to nighttime cloud tests because the solar zenith angles are rounded to the nearest 0.01 when written to the HDF file so a few pixels with values of say 80.003 will get rounded to 80 even though they underwent processing with the nighttime cloud tests. Peter said, "I guess that's the flaw with storing angle data in HDF as scaled integers (that decision was mainly due to file size concerns)."

• The switch between daytime tests and nighttime tests does not manifest as a clean transition in the cloud mask pixels. The daytime pixels do not seem to cleanly abut the nighttime pixels. Rather, a strip of pixels with strange values raggedly separates the two. Peter said: "The apparent unclean transition between day and night tests is related to neighborhood functions. The uniformity tests use a 2x2 box of data values to the right and below a given value in the array to check for a condition being true, and the results of the uniformity test flag all pixels in the 2x2 box with the test results, regardless of whether all those pixels are day or nighttime. Both day and nighttime have uniformity tests, so the results of uniformity tests at the day/night boundary are mixed. The mixing is generally acceptable because the results are intended to be used for SST masking not cloud type evaluation and the mixing only occurs in cloudy conditions, not clear SST conditions."

Peter said he did not know what was done for CoastWatch day/night CWF files. I examined a few of these from the North East region, and it appeared that they also switched from daytime to nighttime cloud tests in the middle of the image. But the NOAA distribution site (http://www.class.noaa.gov) only appeared to have CWFs containing the sun_zenith variable for dates after late 1999.

Peter mentioned that the cwangles program from the CoastWatch Utilities could compute the solar zenith, but the values would only be approximate beacuse the program assumed that all pixels were obtained by the sensor at the same moment in time. I tried this approach but the 80 degree solar zenith line did not line up with the line where the cloud tests appeared to switch. Because of this, I do not believe that day/night CWF files will be useable for users who want to use some cloud tests and ignore others.

Name of the CoastWatch variable to extract from the solar zenith file and use as the solar zenith image (e.g. "sun_zenith").

If True, daytime pixels that failed the CLAVR-1 Reflective Gross Cloud Test (bit 1 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 test is used for both CWF and HDF files, but for HDF files, the CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Reflectance Uniformity Test (bit 2 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 test is used for both CWF and HDF files, but for HDF files, the CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Reflectance Ratio Cloud Test (bit 3 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 test is used for both CWF and HDF files, but for HDF files, the CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Channel 3 Albedo Test (bit 4 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Thermal Uniformity Test (bit 5 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Four Minus Five Test (bit 6 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, daytime pixels that failed the CLAVR-1 Thermal Gross Cloud Test (bit 7 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If a value is provided, daytime pixels with a cloud mask value greater than this value will be masked.

The CoastWatch cloud mask is a bitmask, where each bit represents the success (0) or failure (1) of a given CLAVR cloud test. Thus the cloud mask values are NOT intended to be interpreted as range, like a spectrum, where 0 represents "very clear" and 255 represents "very cloudy". Nevertheless, some users of this tool determined that for their study the best tradeoff between minimizing SST error and minimizing the number of pixels masked by clouds was obtained by masking all pixels where the cloud mask exceeded a certain value. This option was implemented specifically for those users and is not recommended for general use. If you do use this option, be sure to study many cloud mask images before selecting a value.

If a value is provided both for this parameter and for the cloud test bits specified by the previous parameters, all of these parameters will be effective. In other words, a cloudy pixel can be masked by failing a specific cloud test, or by exceeding the minimum cloud mask value, or both. .

This parameter is ignored for nighttime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter. For more information about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Thermal Gross Cloud Test (bit 1 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Thermal Uniformity Test (bit 2 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Uniform Low Stratus Test (bit 3 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Four Minus Five Test (bit 4 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-1 Cirrus Test (bit 5 of the cloud mask) will be masked. If False, this cloud test will be ignored.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-x Channel 3B Albedo Test (bit 6 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, this test was not used for CoastWatch CWF files and thus bit 6 will always be 0, indicating success, for CWF nighttime cloud mask pixels.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If True, nighttime pixels that failed the CLAVR-x Channel 3B Albedo Uniformity Test (bit 7 of the cloud mask) will be masked. If False, this cloud test will be ignored.

According to CoastWatch researcher Peter Hollemans, this test was not used for CoastWatch CWF files and thus bit 7 will always be 0, indicating success, for CWF nighttime cloud mask pixels.

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter.

In CoastWatch cloud masks, bit 1 is the least significant bit, and a value of 0 for a bit indicates that the cloud test passed, while 1 indicates it failed. For more details about the cloud tests, please see the CoastWatch and CLAVR documentation.

If a value is provided, nighttime pixels with a cloud mask value greater than this value will be masked.

The CoastWatch cloud mask is a bitmask, where each bit represents the success (0) or failure (1) of a given CLAVR cloud test. Thus the cloud mask values are NOT intended to be interpreted as range, like a spectrum, where 0 represents "very clear" and 255 represents "very cloudy". Nevertheless, some users of this tool determined that for their study the best tradeoff between minimizing SST error and minimizing the number of pixels masked by clouds was obtained by masking all pixels where the cloud mask exceeded a certain value. This option was implemented specifically for those users and is not recommended for general use. If you do use this option, be sure to study many cloud mask images before selecting a value.

If a value is provided both for this parameter and for the cloud test bits specified by the previous parameters, all of these parameters will be effective. In other words, a cloudy pixel can be masked by failing a specific cloud test, or by exceeding the minimum cloud mask value, or both. .

This parameter is ignored for daytime pixels. For a discussion of how pixels are classified as daytime or nighttime, please see the documentation for the cloud mask file parameter. For more information about the cloud tests, please see the CoastWatch and CLAVR documentation.

Minimum number of neighbors that a cloudy pixel must have in order for that pixel to be masked.

You can use this option to ignore isolated cloudy pixels that are not clumped together. For example, if you specify the value 1, cloudy pixels will be ignored and not used in the masking process unless at least one of their eight neighbors is also cloudy.

If a neighbor is not cloudy but it is masked for some other reason (e.g. it is land), it does not count as being cloudy.

This option is ignored when cloud masking is not performed.

SQL WHERE clause expression that specifies the subset of rows to process. If this parameter is not provided, all of the rows will be processed. If this parameter is provided but the underlying database does not support WHERE clauses, an error will be raised.

The exact syntax of this expression depends on the underlying database. ESRI recommends you reference fields using the following syntax:

• If you're querying ArcInfo coverages, shapefiles, INFO tables or dBASE tables (.dbf files), enclose field names in double quotes in the SQL expression: "MY_FIELD".

• If you're querying Microsoft Access tables or personal geodatabase tables, enclose field names in square brackets: [MY_FIELD].

• If you're querying ArcSDE geodatabase tables, an ArcIMS feature class, or an ArcIMS image service sublayer, don't enclose field names: MY_FIELD.

Fields that will be used to sort the rows (i.e., the columns specified in the ORDER BY clause of a SQL SELECT statement). If no fields are provided, the rows will be sorted in the default order determined by the underlying database. If this parameter is provided but this computer is not running ArcGIS 9.2 or later or the underlying database does not support ORDER BY clauses, an error will be raised.

In addition to specifying the ORDER BY fields, you must also specify the sort direction for each field.

List of strings, either 'Ascending' or 'Descending', that specify the sort directions for the ORDER BY fields. If this parameter is provided but this computer is not running ArcGIS 9.2 or later or the underlying database does not support ORDER BY clauses, an error will be raised.

If True, conversion will be skipped for output rasters that already exist.

Base path to prepend to relative paths.

If a base path is provided, it will be prepended to any relative paths that are obtained from the fields that list the inputs (and outputs, if this tool has outputs). If a base path is not provided, the workspace containing the table will be prepended instead.