| 1 | <?xml version="1.0" encoding="utf-8"?> |
|---|
| 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
|---|
| 3 | <html xmlns="http://www.w3.org/1999/xhtml"><head><link rel="stylesheet" type="text/css" href="81help.css?format=raw" /><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Find CoastWatch Images and Find Cayula-Cornillon Fronts as ArcGIS Rasters</title></head><body><table style="margin-top:-1em; margin-bottom:0; padding:0; margin-left:-1em"><tr><td style="background:white"><img width="875" height="70" alt="ArcToolbox banner" src="AHBanner_ArcToolbox.gif?format=raw" /></td></tr></table><h1>Find CoastWatch Images and Find Cayula-Cornillon Fronts as ArcGIS Rasters</h1><p></p><p>Uses the Cayula-Cornillon (1992) single-image edge detection algorithm to find fronts in the CoastWatch POES AVHRR images found in a directory, and outputs the fronts as ArcGIS rasters.</p><br /><p><h2><img width="11" height="11" border="0" src="sm_arrow_down.gif?format=raw" /> Command line syntax</h2></p><div Class="expand" id="id103150">CoastWatchAVHRRFindCoastWatchFilesAndFindFrontsAsArcGISRasters_GeoEco <inputDirectory> <outputWorkspace> {wildcard} {searchTree} {minSize} {maxSize} {minDateCreated} {maxDateCreated} {minDateModified} {maxDateModified} {variables;variables...} {regionCodes;regionCodes...} {satellites;satellites...} {minImageDate} {maxImageDate} {minDayOfYear} {maxDayOfYear} {sceneTimes;sceneTimes...} {cloudVariable} {sunZenithVariable} {useDayCloudTest1} {useDayCloudTest2} {useDayCloudTest3} {useDayCloudTest4} {useDayCloudTest5} {useDayCloudTest6} {useDayCloudTest7} {maskWhenDayCloudMaskExceeds} {useNightCloudTest1} {useNightCloudTest2} {useNightCloudTest3} {useNightCloudTest4} {useNightCloudTest5} {useNightCloudTest6} {useNightCloudTest7} {maskWhenNightCloudMaskExceeds} {minCloudyNeighbors} {medianFilterWindowSize} {histogramWindowSize} {histogramWindowStride} {minPropNonMaskedCells} {minPopProp} {minPopMeanDifference} {minTheta} {minSinglePopCohesion} {minGlobalPopCohesion} {threads} {projectedCoordinateSystem} {geographicTransformation} {NEAREST | BILINEAR | CUBIC} {projectedCellSize} {registrationPoint} {clippingRectangle} {buildPyramids} {outputFrontsRasterPythonExpression} {outputMaskRasterPythonExpression} {outputFilteredImageRasterPythonExpression} {outputCandidateCountsRasterPythonExpression} {outputFrontCountsRasterPythonExpression} {outputWindowStatusCodesRasterPythonExpression} {outputWindowStatusValuesRasterPythonExpression} {modulesToImport;modulesToImport...} {skipExisting} <br /><br /><b>Parameters</b><br /><table width="100%" border="0" cellpadding="5"><tbody><tr><th width="40%"><b>Expression</b></th><th width="60%"><b>Explanation</b></th></tr><tr><td class="info"><inputDirectory></td><td class="info" align="left"><p>Directory to search.</p></td></tr><tr><td class="info"><outputWorkspace></td><td class="info" align="left"><p>Workspace to receive the ArcGIS rasters.</p></td></tr><tr><td class="info">{wildcard}</td><td class="info" align="left"><p>UNIX-style "glob" wildcard expression specifying the CoastWatch |
|---|
| 4 | files to find.</p><p>The glob syntax supports the following patterns:</p><ul><li><p>? - matches any single character</p></li></ul><ul><li><p>* - matches zero or more characters</p></li></ul><ul><li><p>[seq] - matches any single character in <i>seq</i></p></li></ul><ul><li><p>[!seq] - matches any single character not in <i>seq</i></p></li></ul><p><i>seq</i> is one or more characters, such as abc. You may specify |
|---|
| 5 | character ranges using a dash. For example, a-z0-9 specifies all of |
|---|
| 6 | the characters in the English alphabet and the decimal digits 0 |
|---|
| 7 | through 9.</p><p>You may specify subdirectories in the glob expression. For example, |
|---|
| 8 | the expression CoastWatch*/2006* will find all files beginning with |
|---|
| 9 | 2006 that are contained in directories beginning with CoastWatch.</p><p>The operating system determines whether / or \ is used as the |
|---|
| 10 | directory separator. On Windows, both will work. On most flavors of |
|---|
| 11 | UNIX, / must be used.</p><p>The operating system determines if matching is case sensitive. On |
|---|
| 12 | Windows, matching is case-insensitive. On most flavors of UNIX, |
|---|
| 13 | matching is case-sensitive.</p><p>It is ok if your expression matches files that are not CoastWatch |
|---|
| 14 | files. For example, the expression *.hdf might match some |
|---|
| 15 | non-CoastWatch HDF files. These files will be ignored.</p></td></tr><tr><td class="info">{searchTree}</td><td class="info" align="left"><p>If True, subdirectories will be searched.</p></td></tr><tr><td class="info">{minSize}</td><td class="info" align="left"><p>Minimum size, in bytes, of files to find. If provided, only files |
|---|
| 16 | that are this size or larger will be found.</p></td></tr><tr><td class="info">{maxSize}</td><td class="info" align="left"><p>Maximum size, in bytes, of files to find. If provided, only files |
|---|
| 17 | that are this size or smaller will be found.</p></td></tr><tr><td class="info">{minDateCreated}</td><td class="info" align="left"><p>Minimum creation date, in the local time zone, of the files to |
|---|
| 18 | find, as reported by the operating system. If provided, only files |
|---|
| 19 | that were created on or after this date will be found. You may provide |
|---|
| 20 | a date with or without a time. If you do not provide a time, it is |
|---|
| 21 | assumed to be midnight.</p></td></tr><tr><td class="info">{maxDateCreated}</td><td class="info" align="left"><p>Maximum creation date, in the local time zone, of the files to |
|---|
| 22 | find, as reported by the operating system. If provided, only files |
|---|
| 23 | that were created on or before this date will be found. You may |
|---|
| 24 | provide a date with or without a time. If you do not provide a time, |
|---|
| 25 | it is assumed to be midnight.</p></td></tr><tr><td class="info">{minDateModified}</td><td class="info" align="left"><p>Minimum modification date, in the local time zone, of the files to |
|---|
| 26 | find, as reported by the operating system. If provided, only files |
|---|
| 27 | that were modified on or after this date will be found. You may |
|---|
| 28 | provide a date with or without a time. If you do not provide a time, |
|---|
| 29 | it is assumed to be midnight.</p></td></tr><tr><td class="info">{maxDateModified}</td><td class="info" align="left"><p>Maximum modification date, in the local time zone, of the files to |
|---|
| 30 | find, as reported by the operating system. If provided, only files |
|---|
| 31 | that were modified on or before this date will be found. You may |
|---|
| 32 | provide a date with or without a time. If you do not provide a time, |
|---|
| 33 | it is assumed to be midnight.</p></td></tr><tr><td class="info">{variables;variables...}</td><td class="info" align="left"><p>CoastWatch variables to find in the files that are found. Each |
|---|
| 34 | variable corresponds to an image in the file. If any variables are |
|---|
| 35 | provided, only the images for those variables will be found in the |
|---|
| 36 | files. If none are provided, all images in the files will be found.</p><p>At the time of this writing, the CoastWatch program was known to have |
|---|
| 37 | published files with these variables:</p><dl><dt></dt><dd><pre>avhrr_ch1 |
|---|
| 38 | avhrr_ch2 |
|---|
| 39 | avhrr_ch3 |
|---|
| 40 | avhrr_ch3a |
|---|
| 41 | avhrr_ch4 |
|---|
| 42 | avhrr_ch5 |
|---|
| 43 | cloud |
|---|
| 44 | cloudx |
|---|
| 45 | graphics |
|---|
| 46 | sst |
|---|
| 47 | rel_azimuth |
|---|
| 48 | sat_zenith |
|---|
| 49 | sun_zenith</pre></dd></dl><p>Please see the CoastWatch documentation for more information about |
|---|
| 50 | these variables. In general, most users are interested in the "sst" |
|---|
| 51 | variable, which is the estimated sea surface temperature, and the |
|---|
| 52 | "cloud" variable, which is a bit mask indicating which cloud tests |
|---|
| 53 | failed for that pixel. A value of 0 for the cloud variable indicates |
|---|
| 54 | that all cloud tests passed and CoastWatch has high confidence in the |
|---|
| 55 | validity of the SST value for that pixel.</p></td></tr><tr><td class="info">{regionCodes;regionCodes...}</td><td class="info" align="left"><p>CoastWatch region codes for the files to find. If any regions are |
|---|
| 56 | provided, only files matching those regions will be found. If none are |
|---|
| 57 | provided, all files will be found.</p><p>This function finds the region codes by examining the CoastWatch |
|---|
| 58 | metadata inside the files, not be examining the file name. Thus it |
|---|
| 59 | will work properly with older CoastWatch files that do not include the |
|---|
| 60 | region in the file name.</p><p>Because the CoastWatch metadata does not include the region code |
|---|
| 61 | explicitly, it must be inferred from the other image metadata. The |
|---|
| 62 | current implementation of this function recognizes the following |
|---|
| 63 | regions:</p><dl><dt></dt><dd><pre>aa - Alaska Sitka |
|---|
| 64 | ax - Alaska South |
|---|
| 65 | gb - Great Barrier Reef |
|---|
| 66 | ay - Alaska West |
|---|
| 67 | az - Alaska North |
|---|
| 68 | ce - Caribbean East |
|---|
| 69 | cw - Caribbean West |
|---|
| 70 | er - East Coast North |
|---|
| 71 | gr - Great Lakes |
|---|
| 72 | hr - Hawaii |
|---|
| 73 | mr - Gulf of Mexico |
|---|
| 74 | sb - East Coast Bermuda |
|---|
| 75 | sl - Great Salt Lake |
|---|
| 76 | sr - East Coast South |
|---|
| 77 | wa - West Coast Acapulco |
|---|
| 78 | wj - West Coast Baja |
|---|
| 79 | wn - West Coast North |
|---|
| 80 | ws - West Coast South |
|---|
| 81 | uk - the CoastWatch region is unknown (the image coordinates were not recognized by this tool)</pre></dd></dl><p>These regions were taken from the <a href="http://www2.ncdc.noaa.gov/docs/klm/html/c9/sec9-5.htm">NOAA KLM User's Guide Section 9.5</a> amended |
|---|
| 82 | November 7, 2005. If a file is not for one of these regions, it will |
|---|
| 83 | only be found if you do not specify any region codes. If you would |
|---|
| 84 | like more region codes added to this tool, please contact the |
|---|
| 85 | author.</p></td></tr><tr><td class="info">{satellites;satellites...}</td><td class="info" align="left"><p>Satellites for the files to find. If any satellites are provided, |
|---|
| 86 | only files that contain data from these satellites will be found. If |
|---|
| 87 | none are provided, all files will be found.</p><p>At the time of this writing, the CoastWatch program was known to have |
|---|
| 88 | published data from the following satellites:</p><dl><dt></dt><dd><pre>NOAA-12 |
|---|
| 89 | NOAA-14 |
|---|
| 90 | NOAA-15 |
|---|
| 91 | NOAA-16 |
|---|
| 92 | NOAA-17 |
|---|
| 93 | NOAA-18</pre></dd></dl></td></tr><tr><td class="info">{minImageDate}</td><td class="info" align="left"><p>Minimum image date, in UTC, for the files to find. If provided, |
|---|
| 94 | only files that contain images taken on or after this date will be |
|---|
| 95 | found. You may provide a date with or without a time. If you do not |
|---|
| 96 | provide a time, it is assumed to be midnight.</p></td></tr><tr><td class="info">{maxImageDate}</td><td class="info" align="left"><p>Maximum image date, in UTC, for the files to find. If provided, |
|---|
| 97 | only files that contain images taken on or before this date will be |
|---|
| 98 | found. You may provide a date with or without a time. If you do not |
|---|
| 99 | provide a time, it is assumed to be midnight.</p></td></tr><tr><td class="info">{minDayOfYear}</td><td class="info" align="left"><p>Minimum image day of the year, in UTC, for the for the files to |
|---|
| 100 | find. If provided, only files that contain images taken on or after |
|---|
| 101 | this day of the year will be found. The first day of the year is |
|---|
| 102 | always 1, and the last day of the year is 365 during non-leap years |
|---|
| 103 | and 366 during leap years.</p></td></tr><tr><td class="info">{maxDayOfYear}</td><td class="info" align="left"><p>Maximum image day of the year, in UTC, for the for the files to |
|---|
| 104 | find. If provided, only files that contain images taken on or before |
|---|
| 105 | this day of the year will be found. The first day of the year is |
|---|
| 106 | always 1, and the last day of the year is 365 during non-leap years |
|---|
| 107 | and 366 during leap years.</p></td></tr><tr><td class="info">{sceneTimes;sceneTimes...}</td><td class="info" align="left"><p>CoastWatch "scene times" for the files to find. If provided, only |
|---|
| 108 | files that contain images with these scene times will be found. If |
|---|
| 109 | none are provided, all files will be found.</p><p>At the time of this writing, the CoastWatch program was known to have |
|---|
| 110 | published data with the following scene times:</p><dl><dt></dt><dd><pre>day |
|---|
| 111 | day/night |
|---|
| 112 | night</pre></dd></dl><p>The scene time affects which cloud tests are used to generate the |
|---|
| 113 | cloud mask image, among other things. Please consult the CoastWatch |
|---|
| 114 | documentation for more information.</p></td></tr><tr><td class="info">{cloudVariable}</td><td class="info" align="left"><p>Name of the CoastWatch variable to extract from the input |
|---|
| 115 | CoastWatch file and use as the cloud mask (e.g. "cloud"). If the input |
|---|
| 116 | file does not contain the cloud variable, cloud masking will not be |
|---|
| 117 | performed for this file.</p><p>A limitation of this tool is that it can only extract the cloud |
|---|
| 118 | variable from the input CoastWatch file; it cannot extract it from |
|---|
| 119 | another file. This tool, therefore, cannot perform cloud masking on |
|---|
| 120 | CWF files (except those that contain the cloud variable), because CWFs |
|---|
| 121 | usually only contain one variable (e.g. sst) in addition to the |
|---|
| 122 | graphics variable. If you need to perform cloud masking on CWF files, |
|---|
| 123 | I recommend you convert the CWFs containing the cloud variable and the |
|---|
| 124 | other variables of interest into a single HDF, and then process the |
|---|
| 125 | HDF instead.</p><p>The current implementation of this tool was designed to operate on the |
|---|
| 126 | 8-bit CLAVR cloud mask represented by the "cloud" variable in |
|---|
| 127 | CoastWatch files. It was not designed to operate on the "cloudx" |
|---|
| 128 | variable, which is a new experimental CLAVR-x cloud mask available in |
|---|
| 129 | recent CoastWatch HDF files. Nonetheless, if you wish to operate on |
|---|
| 130 | the cloudx variable, you can specify it instead of cloud, and pick |
|---|
| 131 | mask options appropriate for it instead.</p></td></tr><tr><td class="info">{sunZenithVariable}</td><td class="info" align="left"><p>Name of the CoastWatch variable to extract from the input |
|---|
| 132 | CoastWatch file and use as the solar zenith image (e.g. "sun_zenith").</p><p>A limitation of this tool is that it can only extract the solar zenith |
|---|
| 133 | image from the input CoastWatch file; it cannot extract it from |
|---|
| 134 | another file. Therefore, because this tool uses the solar zenith image |
|---|
| 135 | when performing cloud masking on images with a day/night scene time, |
|---|
| 136 | cannot perform cloud masking on CWF files, because CWFs usually only |
|---|
| 137 | contain one variable (e.g. sst) in addition to the graphics variable. |
|---|
| 138 | If you need to perform cloud masking on CWF files, I recommend you |
|---|
| 139 | convert the CWFs containing the cloud, sun_zenith, and the other |
|---|
| 140 | variables of interest into a single HDF, and then process the HDF |
|---|
| 141 | instead.</p><p>According to CoastWatch researcher Peter Hollemans, when an image's |
|---|
| 142 | scene time is "day", all pixels of the cloud mask use daytime cloud |
|---|
| 143 | tests, and when it is "night", all pixels use nighttime cloud tests. |
|---|
| 144 | When the scene time is "day/night", the decision of which tests to use |
|---|
| 145 | is based on the solar zenith for that pixel.</p><p>According to Peter, for CoastWatch HDF files, pixels with a solar |
|---|
| 146 | zenith > 80 degrees use the nighttime cloud tests, and <= 80 use the |
|---|
| 147 | daytime cloud tests. This tool implements that logic. If you specify |
|---|
| 148 | that cloud masking should be performed for a day/night image but no |
|---|
| 149 | solar zenith image is available, this tool will assume that nighttime |
|---|
| 150 | cloud tests were used for every pixel and a warning will be issued. |
|---|
| 151 | For some reason, CoastWatch occasionally produces day/night images |
|---|
| 152 | with no sun_zenith or other variables that are present in day images. |
|---|
| 153 | My recollection is that Peter said it is safe to assume for these |
|---|
| 154 | images that all pixels are nighttime.</p><p>The solar zenith image is ignored for scene times other than |
|---|
| 155 | "day/night" (e.g. "day" or "night").</p><p>After some investigation, I find that the cloud mask pixels near the |
|---|
| 156 | 80 degree solar zenith line are problematic, for two reasons:</p><ul><li><p>According to Peter, the solar zenith <= 80 cutoff line is not going |
|---|
| 157 | to line up perfectly with the switch from daytime to nighttime cloud |
|---|
| 158 | tests because the solar zenith angles are rounded to the nearest |
|---|
| 159 | 0.01 when written to the HDF file so a few pixels with values of say |
|---|
| 160 | 80.003 will get rounded to 80 even though they underwent processing |
|---|
| 161 | with the nighttime cloud tests. Peter said, "I guess that's the flaw |
|---|
| 162 | with storing angle data in HDF as scaled integers (that decision was |
|---|
| 163 | mainly due to file size concerns)."</p></li></ul><ul><li><p>The switch between daytime tests and nighttime tests does not |
|---|
| 164 | manifest as a clean transition in the cloud mask pixels. The daytime |
|---|
| 165 | pixels do not seem to cleanly abut the nighttime pixels. Rather, a |
|---|
| 166 | strip of pixels with strange values raggedly separates the two. |
|---|
| 167 | Peter said: "The apparent unclean transition between day and night |
|---|
| 168 | tests is related to neighborhood functions. The uniformity tests |
|---|
| 169 | use a 2x2 box of data values to the right and below a given value in |
|---|
| 170 | the array to check for a condition being true, and the results of |
|---|
| 171 | the uniformity test flag all pixels in the 2x2 box with the test |
|---|
| 172 | results, regardless of whether all those pixels are day or |
|---|
| 173 | nighttime. Both day and nighttime have uniformity tests, so the |
|---|
| 174 | results of uniformity tests at the day/night boundary are mixed. The |
|---|
| 175 | mixing is generally acceptable because the results are intended to |
|---|
| 176 | be used for SST masking not cloud type evaluation and the mixing |
|---|
| 177 | only occurs in cloudy conditions, not clear SST conditions."</p></li></ul><p>Peter said he did not know what was done for CoastWatch day/night CWF |
|---|
| 178 | files. I examined a few of these from the North East region, and it |
|---|
| 179 | appeared that they also switched from daytime to nighttime cloud tests |
|---|
| 180 | in the middle of the image. But the NOAA distribution site |
|---|
| 181 | (<a href="http://www.class.noaa.gov">http://www.class.noaa.gov</a>) only appeared to have CWFs containing the |
|---|
| 182 | sun_zenith variable for dates after late 1999.</p><p>Peter mentioned that the cwangles program from the CoastWatch |
|---|
| 183 | Utilities could compute the solar zenith, but the values would only be |
|---|
| 184 | approximate beacuse the program assumed that all pixels were obtained |
|---|
| 185 | by the sensor at the same moment in time. I tried this approach but |
|---|
| 186 | the 80 degree solar zenith line did not line up with the line where |
|---|
| 187 | the cloud tests appeared to switch. Because of this, I do not believe |
|---|
| 188 | that day/night CWF files will be useable for users who want to use |
|---|
| 189 | some cloud tests and ignore others.</p></td></tr><tr><td class="info">{useDayCloudTest1}</td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Reflective Gross |
|---|
| 190 | Cloud Test (bit 1 of the cloud mask) will be masked. If False, this |
|---|
| 191 | cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 |
|---|
| 192 | test is used for both CWF and HDF files, but for HDF files, the |
|---|
| 193 | CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 194 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 195 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 196 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 197 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 198 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useDayCloudTest2}</td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Reflectance |
|---|
| 199 | Uniformity Test (bit 2 of the cloud mask) will be masked. If False, |
|---|
| 200 | this cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 |
|---|
| 201 | test is used for both CWF and HDF files, but for HDF files, the |
|---|
| 202 | CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 203 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 204 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 205 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 206 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 207 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useDayCloudTest3}</td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Reflectance Ratio |
|---|
| 208 | Cloud Test (bit 3 of the cloud mask) will be masked. If False, this |
|---|
| 209 | cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 |
|---|
| 210 | test is used for both CWF and HDF files, but for HDF files, the |
|---|
| 211 | CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 212 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 213 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 214 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 215 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 216 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useDayCloudTest4}</td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Channel 3 Albedo |
|---|
| 217 | Test (bit 4 of the cloud mask) will be masked. If False, this cloud |
|---|
| 218 | test will be ignored.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 219 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 220 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 221 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 222 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 223 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useDayCloudTest5}</td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Thermal Uniformity |
|---|
| 224 | Test (bit 5 of the cloud mask) will be masked. If False, this cloud |
|---|
| 225 | test will be ignored.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 226 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 227 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 228 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 229 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 230 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useDayCloudTest6}</td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Four Minus Five |
|---|
| 231 | Test (bit 6 of the cloud mask) will be masked. If False, this cloud |
|---|
| 232 | test will be ignored.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 233 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 234 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 235 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 236 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 237 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useDayCloudTest7}</td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Thermal Gross |
|---|
| 238 | Cloud Test (bit 7 of the cloud mask) will be masked. If False, this |
|---|
| 239 | cloud test will be ignored.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 240 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 241 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 242 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 243 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 244 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{maskWhenDayCloudMaskExceeds}</td><td class="info" align="left"><p>If a value is provided, daytime pixels with a cloud mask value |
|---|
| 245 | greater than this value will be masked.</p><p>The CoastWatch cloud mask is a bitmask, where each bit represents the |
|---|
| 246 | success (0) or failure (1) of a given CLAVR cloud test. Thus the cloud |
|---|
| 247 | mask values are NOT intended to be interpreted as range, like a |
|---|
| 248 | spectrum, where 0 represents "very clear" and 255 represents "very |
|---|
| 249 | cloudy". Nevertheless, some users of this tool determined that for |
|---|
| 250 | their study the best tradeoff between minimizing SST error and |
|---|
| 251 | minimizing the number of pixels masked by clouds was obtained by |
|---|
| 252 | masking all pixels where the cloud mask exceeded a certain value. This |
|---|
| 253 | option was implemented specifically for those users and is not |
|---|
| 254 | recommended for general use. If you do use this option, be sure to |
|---|
| 255 | study many cloud mask images before selecting a value.</p><p>If a value is provided both for this parameter and for the cloud test |
|---|
| 256 | bits specified by the previous parameters, all of these parameters |
|---|
| 257 | will be effective. In other words, a cloudy pixel can be masked by |
|---|
| 258 | failing a specific cloud test, or by exceeding the minimum cloud mask |
|---|
| 259 | value, or both. .</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 260 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 261 | documentation for the cloud mask file parameter. For more information |
|---|
| 262 | about the cloud tests, please see the CoastWatch and CLAVR |
|---|
| 263 | documentation.</p></td></tr><tr><td class="info">{useNightCloudTest1}</td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Thermal Gross |
|---|
| 264 | Cloud Test (bit 1 of the cloud mask) will be masked. If False, this |
|---|
| 265 | cloud test will be ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 266 | pixels are classified as daytime or nighttime, please see the |
|---|
| 267 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 268 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 269 | indicates it failed. For more details about the cloud tests, please |
|---|
| 270 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useNightCloudTest2}</td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Thermal |
|---|
| 271 | Uniformity Test (bit 2 of the cloud mask) will be masked. If False, |
|---|
| 272 | this cloud test will be ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 273 | pixels are classified as daytime or nighttime, please see the |
|---|
| 274 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 275 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 276 | indicates it failed. For more details about the cloud tests, please |
|---|
| 277 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useNightCloudTest3}</td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Uniform Low |
|---|
| 278 | Stratus Test (bit 3 of the cloud mask) will be masked. If False, this |
|---|
| 279 | cloud test will be ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 280 | pixels are classified as daytime or nighttime, please see the |
|---|
| 281 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 282 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 283 | indicates it failed. For more details about the cloud tests, please |
|---|
| 284 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useNightCloudTest4}</td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Four Minus Five |
|---|
| 285 | Test (bit 4 of the cloud mask) will be masked. If False, this cloud |
|---|
| 286 | test will be ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 287 | pixels are classified as daytime or nighttime, please see the |
|---|
| 288 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 289 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 290 | indicates it failed. For more details about the cloud tests, please |
|---|
| 291 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useNightCloudTest5}</td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Cirrus Test (bit |
|---|
| 292 | 5 of the cloud mask) will be masked. If False, this cloud test will be |
|---|
| 293 | ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 294 | pixels are classified as daytime or nighttime, please see the |
|---|
| 295 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 296 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 297 | indicates it failed. For more details about the cloud tests, please |
|---|
| 298 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useNightCloudTest6}</td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-x Channel 3B |
|---|
| 299 | Albedo Test (bit 6 of the cloud mask) will be masked. If False, this |
|---|
| 300 | cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, this test was not |
|---|
| 301 | used for CoastWatch CWF files and thus bit 6 will always be 0, |
|---|
| 302 | indicating success, for CWF nighttime cloud mask pixels.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 303 | pixels are classified as daytime or nighttime, please see the |
|---|
| 304 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 305 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 306 | indicates it failed. For more details about the cloud tests, please |
|---|
| 307 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{useNightCloudTest7}</td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-x Channel 3B |
|---|
| 308 | Albedo Uniformity Test (bit 7 of the cloud mask) will be masked. If |
|---|
| 309 | False, this cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, this test was not |
|---|
| 310 | used for CoastWatch CWF files and thus bit 7 will always be 0, |
|---|
| 311 | indicating success, for CWF nighttime cloud mask pixels.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 312 | pixels are classified as daytime or nighttime, please see the |
|---|
| 313 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 314 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 315 | indicates it failed. For more details about the cloud tests, please |
|---|
| 316 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">{maskWhenNightCloudMaskExceeds}</td><td class="info" align="left"><p>If a value is provided, nighttime pixels with a cloud mask value |
|---|
| 317 | greater than this value will be masked.</p><p>The CoastWatch cloud mask is a bitmask, where each bit represents the |
|---|
| 318 | success (0) or failure (1) of a given CLAVR cloud test. Thus the cloud |
|---|
| 319 | mask values are NOT intended to be interpreted as range, like a |
|---|
| 320 | spectrum, where 0 represents "very clear" and 255 represents "very |
|---|
| 321 | cloudy". Nevertheless, some users of this tool determined that for |
|---|
| 322 | their study the best tradeoff between minimizing SST error and |
|---|
| 323 | minimizing the number of pixels masked by clouds was obtained by |
|---|
| 324 | masking all pixels where the cloud mask exceeded a certain value. This |
|---|
| 325 | option was implemented specifically for those users and is not |
|---|
| 326 | recommended for general use. If you do use this option, be sure to |
|---|
| 327 | study many cloud mask images before selecting a value.</p><p>If a value is provided both for this parameter and for the cloud test |
|---|
| 328 | bits specified by the previous parameters, all of these parameters |
|---|
| 329 | will be effective. In other words, a cloudy pixel can be masked by |
|---|
| 330 | failing a specific cloud test, or by exceeding the minimum cloud mask |
|---|
| 331 | value, or both. .</p><p>This parameter is ignored for daytime pixels. For a discussion of |
|---|
| 332 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 333 | documentation for the cloud mask file parameter. For more information |
|---|
| 334 | about the cloud tests, please see the CoastWatch and CLAVR |
|---|
| 335 | documentation.</p></td></tr><tr><td class="info">{minCloudyNeighbors}</td><td class="info" align="left"><p>Minimum number of neighbors that a cloudy pixel must have in order |
|---|
| 336 | for that pixel to be masked.</p><p>You can use this option to ignore isolated cloudy pixels that are not |
|---|
| 337 | clumped together. For example, if you specify the value 1, cloudy |
|---|
| 338 | pixels will be ignored and not used in the masking process unless at |
|---|
| 339 | least one of their eight neighbors is also cloudy.</p><p>If a neighbor is not cloudy but it is masked for some other reason |
|---|
| 340 | (e.g. it is land), it does not count as being cloudy.</p><p>This option is ignored when cloud masking is not performed.</p></td></tr><tr><td class="info">{medianFilterWindowSize}</td><td class="info" align="left"><p>Window size, in pixels, of the median filter to apply to the input |
|---|
| 341 | image prior to running the histogram analysis step of the |
|---|
| 342 | Cayula-Cornillon algorithm. If not provided, median filtering will not |
|---|
| 343 | be performed.</p><p>If you provide a value, it must be an odd integer greater than or |
|---|
| 344 | equal to 3. The filter window is square and advances across the image |
|---|
| 345 | 1 pixel at a time. The center pixel, if it is not masked, is replaced |
|---|
| 346 | with the median value of the non-masked pixels in the surrounding |
|---|
| 347 | window. All masks are applied before the median filter is executed.</p><p>Median filtering is a traditional first step for certain classes of |
|---|
| 348 | edge detection algorithms. The original Cayula-Cornillon paper used a |
|---|
| 349 | window size of 3.</p></td></tr><tr><td class="info">{histogramWindowSize}</td><td class="info" align="left"><p>Size of the histogram window to use for the Cayula-Cornillon |
|---|
| 350 | algorithm.</p><p>The window is square. The original paper used a window size of 32. |
|---|
| 351 | Although the algorithm is claimed to obtain similar results regardless |
|---|
| 352 | of window size, I have noticed that some fronts may only be detected |
|---|
| 353 | by using a smaller window size such as 16. I highly recommend you read |
|---|
| 354 | the paper carefully before experimenting with different window |
|---|
| 355 | sizes.</p></td></tr><tr><td class="info">{histogramWindowStride}</td><td class="info" align="left"><p>Number of pixels to move the histogram window after each iteration |
|---|
| 356 | of the Cayula-Cornillon algorithm.</p><p>The original paper used a 32x32 window and a stride of 16, to minimize |
|---|
| 357 | the CPU time required to execute the algorithm. Cutting the stride in |
|---|
| 358 | half increases the CPU time by a factor of about four. For example, a |
|---|
| 359 | stride of 1 requires about 256 times more CPU time than a stride of |
|---|
| 360 | 16.</p><p>In my experience, smaller stride values identify more fronts, and the |
|---|
| 361 | resulting fronts are longer and thicker. If you have a powerful |
|---|
| 362 | computer, want to find more fronts, and are comfortable deviating from |
|---|
| 363 | the published method, you can use a smaller value. If you do this, you |
|---|
| 364 | may want to apply a thinning algorithm after running this tool, to |
|---|
| 365 | reduce the widths of the resulting fronts.</p></td></tr><tr><td class="info">{minPropNonMaskedCells}</td><td class="info" align="left"><p>Minimum proportion of pixels in a histogram window that must not |
|---|
| 366 | be masked for the algorithm to proceed with histogram analysis on that |
|---|
| 367 | window.</p><p>For example, if the value 0.75 is used and the histogram window is |
|---|
| 368 | 20x20, at least 300 out of the 400 pixels must not be masked for |
|---|
| 369 | analysis to proceed on that window. If more than 100 pixels are |
|---|
| 370 | masked, the algorithm discards the current window, advances to next |
|---|
| 371 | one, and starts over.</p><p>The Fortran code I obtained from Dave Ullman used the value 0.65.</p></td></tr><tr><td class="info">{minPopProp}</td><td class="info" align="left"><p>Minimum proportional size of the smaller population.</p><p>If the histogram algorithm determines that the values of the |
|---|
| 372 | non-masked pixels in the window have a bimodal distribution, it then |
|---|
| 373 | selects the value that optimally separates them into two populations. |
|---|
| 374 | As described on page 73 of the 1992 paper, if the proportion of |
|---|
| 375 | non-masked pixels allocated to the smaller population is smaller than |
|---|
| 376 | 0.25, the subsequent statistical tests will not be accurate. In this |
|---|
| 377 | case, and the algorithm discards the current window, advances to next |
|---|
| 378 | one, and starts over.</p><p>I do not recommend selecting a value other than 0.25 unless you |
|---|
| 379 | understand the statistical analysis presented in the 1992 paper.</p></td></tr><tr><td class="info">{minPopMeanDifference}</td><td class="info" align="left"><p>Minimum difference in population means.</p><p>After the histogram algorithm separates the non-masked pixels into two |
|---|
| 380 | populations, it computes the means of the two populations. If the |
|---|
| 381 | means differ by less than this parameter value, the algorithm discards |
|---|
| 382 | the current window, advances to next one, and starts over.</p><p>The original intent of this parameter is obscure. The Fortran code I |
|---|
| 383 | obtained from Dave Ullman used the value 3 and contained the |
|---|
| 384 | explanation "a temperature difference of less than three digital |
|---|
| 385 | counts between the 2 populations is likely to be a result of the |
|---|
| 386 | discrete nature of the data."</p><p>You can use this parameter to eliminate weak fronts by selecting a |
|---|
| 387 | value that corresponds to a desired minimum mean temperature |
|---|
| 388 | difference. For example, the NOAA NODC 4km AVHRR Pathfinder Project |
|---|
| 389 | (<a href="http://www.nodc.noaa.gov/SatelliteData/pathfinder4km/">http://www.nodc.noaa.gov/SatelliteData/pathfinder4km/</a>) publishes SST |
|---|
| 390 | data as 16-bit unsigned integers where each integer represents 0.075 |
|---|
| 391 | degrees. To eliminate fronts where the mean temperature difference is |
|---|
| 392 | less than 0.5 degrees, set this parameter to 0.5 / 0.075 = |
|---|
| 393 | 6.666667.</p></td></tr><tr><td class="info">{minTheta}</td><td class="info" align="left"><p>Minimum criterion function, theta(Topt), as described on pages |
|---|
| 394 | 71-72 of the 1992 paper.</p><p>The criterion function is used to determine whether the histogram |
|---|
| 395 | window contains a bimodal distribution. Cayula and Cornillon performed |
|---|
| 396 | an extensive analysis to determine that the value 0.76 produced |
|---|
| 397 | optimal results for the SST data they worked with. Selecting a smaller |
|---|
| 398 | value will allow windows with more homogenous, less bimodal |
|---|
| 399 | distributions to be considered by the algorithm. If the window yields |
|---|
| 400 | a value less than this parameter, the algorithm discards the current |
|---|
| 401 | window, advances to next one, and starts over.</p><p>I do not recommend selecting a value other than 0.76 unless you |
|---|
| 402 | understand the statistics presented in the original paper.</p></td></tr><tr><td class="info">{minSinglePopCohesion}</td><td class="info" align="left"><p>Minimum cohesion of a single population.</p><p>If the histogram window is found to have a sufficiently bimodal |
|---|
| 403 | distribution of values, the cohesion algorithm is executed to check |
|---|
| 404 | whether the pixels of the two populations are sufficiently spatially |
|---|
| 405 | separated. High values indicate that they are separated, suggesting |
|---|
| 406 | that two distinct populations (e.g. water masses) are present in the |
|---|
| 407 | window. Low values indicate the populations are all mixed up, like a |
|---|
| 408 | checkerboard, and suggest that the pattern results from clouds, noise |
|---|
| 409 | or other random processes.</p><p>The first part of the cohesion algorithm checks the cohesion of each |
|---|
| 410 | population by itself (equations 19 and 20 in the 1992 paper). As |
|---|
| 411 | described in Appendix B of the 1992 paper, the optimal cohesion |
|---|
| 412 | coefficients depend on the size of the histogram window. Cayula and |
|---|
| 413 | Cornillon used the value 0.90 for a 32x32 window, which was |
|---|
| 414 | calculated:</p><dl><dt></dt><dd><pre>C = 1.0 - 0.02 - 1/winsize - 2*P(error) = 0.98 - 1/32 - 2(0.025) = 0.90</pre></dd></dl><p>For a 16x16 window, the equation evaluates to 0.8675.</p></td></tr><tr><td class="info">{minGlobalPopCohesion}</td><td class="info" align="left"><p>Minimum cohesion of both populations.</p><p>The second part of the cohesion algorithm checks the cohesion of both |
|---|
| 415 | populations together (equation 21 in the 1992 paper). As described in |
|---|
| 416 | Appendix B of the 1992 paper, the optimal cohesion coefficients depend |
|---|
| 417 | on the size of the histogram window. Cayula and Cornillon used the |
|---|
| 418 | value 0.92 for a 32x32 window, which was calculated:</p><dl><dt></dt><dd><pre>C = 1.0 - 1/winsize - 2*P(error) = 1.0 - 1/32 - 2(0.025) = 0.92</pre></dd></dl><p>For a 16x16 window, the equation evaluates to 0.8875.</p></td></tr><tr><td class="info">{threads}</td><td class="info" align="left"><p>Number of threads to start for parallel processing.</p><p>The histogram and cohesion algorithms are CPU intensive but are |
|---|
| 419 | designed to run in parallel on machines that have multiple processors. |
|---|
| 420 | To maximize utilization of your machine's processors and shorten the |
|---|
| 421 | time required to execute the algorithms, set the number of threads to |
|---|
| 422 | the number of processors you wish to utilize. Do not set the number of |
|---|
| 423 | threads to more than the number of processors you have; this will |
|---|
| 424 | reduce performance.</p><p>For this option to have any effect, your version of Python must |
|---|
| 425 | include the threading module. Most recent versions of Python include |
|---|
| 426 | this module.</p></td></tr><tr><td class="info">{projectedCoordinateSystem}</td><td class="info" align="left"><p>New coordinate system to project the output raster to.</p><p>The raster may only be projected to a new coordinate system if the |
|---|
| 427 | original projection is defined. An error will be raised if you specify |
|---|
| 428 | a new coordinate system without defining the original coordinate |
|---|
| 429 | system.</p><p>The ArcGIS Project Raster tool is used to perform the projection. The |
|---|
| 430 | documentation for that tool recommends that you also specify a cell |
|---|
| 431 | size for the new coordinate system.</p><p>I have noticed that for certain coordinate systems the ArcGIS 9.2 |
|---|
| 432 | Project Raster tool seems to clip the projected raster to an arbitrary |
|---|
| 433 | extent that is too small. For example, when projecting a global MODIS |
|---|
| 434 | Aqua 4 km chlorophyll image in geographic coordinates to |
|---|
| 435 | Lambert_Azimuthal_Equal_Area with central meridian of -60 and latitude |
|---|
| 436 | of origin of -63, the resulting image is clipped to show only |
|---|
| 437 | one-quarter of the planet. This problem does not occur when Project |
|---|
| 438 | Raster is invoked interactively from the ArcGIS user interface; it |
|---|
| 439 | only occurs when the tool is invoked programmatically (the |
|---|
| 440 | ProjectRaster_management method of the geoprocessor). Thus you may |
|---|
| 441 | not see it when you use Project Raster yourself but it may happen when |
|---|
| 442 | you use MGET tools that invoke Project Raster as part of their |
|---|
| 443 | geoprocessing operations.</p><p>If you encounter this problem, you can work around it like this:</p><ul><li><p>First, run this tool without specifying a new coordinate system, to |
|---|
| 444 | obtain the output raster in the original coordinate system.</p></li></ul><ul><li><p>In ArcCatalog, use the Project Raster tool to project the raster to |
|---|
| 445 | the new coordinate system. Verify that the entire raster is present, |
|---|
| 446 | that it has not been clipped to an extent that is too small.</p></li></ul><ul><li><p>In ArcCatalog, look up the extent of the projected raster by |
|---|
| 447 | right-clicking on it in the catalog tree, selecting Properties, and |
|---|
| 448 | scrolling down to Extent.</p></li></ul><ul><li><p>Now, before running the MGET tool that projects the raster, set the |
|---|
| 449 | Extent environment setting to the values you looked up. If you are |
|---|
| 450 | invoking the MGET tool interactively from ArcCatalog or ArcMap, |
|---|
| 451 | click the Environments button on the tool's dialog box, open General |
|---|
| 452 | Settings, change the Extent drop-down to "As Specified Below", and |
|---|
| 453 | type in the values you looked up. If you're invoking it from a |
|---|
| 454 | geoprocessing model, right-click on the tool in the model, select |
|---|
| 455 | Make Variable, From Environment, General Settings, Extent. This will |
|---|
| 456 | place Extent as a variable in your model, attached to the MGET tool. |
|---|
| 457 | Open the Extent variable, change it to "As Specified Below" and type |
|---|
| 458 | in the values you looked up. If you're invoking the MGET tool |
|---|
| 459 | programmatically, you must set the Extent property of the |
|---|
| 460 | geoprocessor to the values you looked up. Please see the ArcGIS |
|---|
| 461 | documentation for more information about this and Environment |
|---|
| 462 | settings in general.</p></li></ul><ul><li><p>Run the MGET tool. The extent of the output raster should now be the |
|---|
| 463 | proper size.</p></li></ul></td></tr><tr><td class="info">{geographicTransformation}</td><td class="info" align="left"><p>A transformation method used to convert between the original |
|---|
| 464 | coordinate system and the new coordinate system.</p><p>This parameter is a new option introduced by ArcGIS 9.2. You must have |
|---|
| 465 | ArcGIS 9.2 to use this parameter.</p><p>This parameter is only needed when you specify that the raster should |
|---|
| 466 | be projected to a new coordinate system and that new system uses a |
|---|
| 467 | different datum than the original coordinate system, or there is some |
|---|
| 468 | other difference between the two coordinate systems that requires a |
|---|
| 469 | transformation. To determine if a transformation is needed, I |
|---|
| 470 | recommend the following procedure:</p><ul><li><p>First, run this tool without specifying a new coordinate system, to |
|---|
| 471 | obtain the output raster in the original coordinate system.</p></li></ul><ul><li><p>Next, use the ArcGIS 9.2 Project Raster tool on the output raster to |
|---|
| 472 | project it to the desired coordinate system. If a geographic |
|---|
| 473 | transformation is needed, that tool will prompt you for one. Write |
|---|
| 474 | down the exact name of the transformation you used.</p></li></ul><ul><li><p>Finally, if a transformation was needed, type in the exact name into |
|---|
| 475 | this tool, rerun it, and verify that the output raster was projected |
|---|
| 476 | as you desired.</p></li></ul></td></tr><tr><td class="info">{NEAREST | BILINEAR | CUBIC}</td><td class="info" align="left"><p>The resampling algorithm to be used to project the original raster |
|---|
| 477 | to a new coordinate system. The ArcGIS Project Raster tool is used to |
|---|
| 478 | perform the projection and accepts the following values:</p><ul><li><p>NEAREST - nearest neighbor interpolation</p></li></ul><ul><li><p>BILINEAR - bilinear interpolation</p></li></ul><ul><li><p>CUBIC - cubic convolution</p></li></ul><p>You must specify one of these algorithms to project to a new |
|---|
| 479 | coordinate system. An error will be raised if you specify a new |
|---|
| 480 | coordinate system without selecting an algorithm.</p></td></tr><tr><td class="info">{projectedCellSize}</td><td class="info" align="left"><p>The cell size of the projected coordinate system. Although this |
|---|
| 481 | parameter is optional, to receive the best results, the ArcGIS |
|---|
| 482 | documentation recommends you always specify it when projecting to a |
|---|
| 483 | new coordinate system.</p></td></tr><tr><td class="info">{registrationPoint}</td><td class="info" align="left"><p>The x and y coordinates (in the output space) used for pixel |
|---|
| 484 | alignment.</p><p>This parameter is a new option introduced by ArcGIS 9.2. You must have |
|---|
| 485 | ArcGIS 9.2 to use this parameter. It is ignored if you do not specify |
|---|
| 486 | that the raster should be projected to a new coordinate system.</p></td></tr><tr><td class="info">{clippingRectangle}</td><td class="info" align="left"><p>Rectangle to which the raster should be clipped.</p><p>If a projected coordinate system was specified, the clipping is |
|---|
| 487 | performed after the projection and the rectangle's coordinates should |
|---|
| 488 | be specified in the new coordinate system. If no projected coordinate |
|---|
| 489 | system was specified, the coordinates should be specified in the |
|---|
| 490 | original coordinate system.</p><p>The ArcGIS Clip tool is used to perfom the clip. The clipping |
|---|
| 491 | rectangle must be passed to this tool as a string of four numbers |
|---|
| 492 | separated by spaces. The ArcGIS user interface automatically formats |
|---|
| 493 | the string properly; when invoking this tool from the ArcGIS UI, |
|---|
| 494 | you need not worry about the format. But when invoking it |
|---|
| 495 | programmatically, take care to provide a properly-formatted string. |
|---|
| 496 | The numbers are ordered LEFT, BOTTOM, RIGHT, TOP. For example, if the |
|---|
| 497 | raster is in a geographic coordinate system, it may be clipped to 10 |
|---|
| 498 | W, 15 S, 20 E, and 25 N with the string:</p><dl><dt></dt><dd><p>10 15 20 25</p></dd></dl><p>Integers or decimal numbers may be provided.</p></td></tr><tr><td class="info">{buildPyramids}</td><td class="info" align="left"><p>If True, pyramids will be built for the output raster, which will |
|---|
| 499 | improve its display speed in the ArcGIS user interface. This is the |
|---|
| 500 | last step performed in post-conversion processing.</p></td></tr><tr><td class="info">{outputFrontsRasterPythonExpression}</td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 501 | output raster that shows the fronts detected in the input image.</p><p>The raster will have the same dimensions as the input image and |
|---|
| 502 | contain 8-bit signed integers with three possible values:</p><ul><li><p>NoData - the pixel was never a candidate for containing a front, |
|---|
| 503 | either because it was masked or because because it did not appear in |
|---|
| 504 | any histogram windows that had sufficiently large numbers of |
|---|
| 505 | non-masked pixels to proceed with the histogramming step of the |
|---|
| 506 | Cayula-Cornillon algorithm.</p></li></ul><ul><li><p>0 - The pixel was a candidate for containing a front -- it was not |
|---|
| 507 | masked and it appeared in at least one histogram window with a |
|---|
| 508 | sufficient number of non-masked pixels to proceed with the |
|---|
| 509 | histogramming step -- but it was never marked as a front pixel in |
|---|
| 510 | any of the histogram windows it appeared in.</p></li></ul><ul><li><p>1 - The pixel was a candidate for containing a front and it was marked |
|---|
| 511 | as a front pixel in at least one of the histogram windows it |
|---|
| 512 | appeared in.</p></li></ul><p>The expression may be any Python statement appropriate for passing to |
|---|
| 513 | the eval function and must return a Unicode string. The expression may |
|---|
| 514 | reference the following variables:</p><ul><li><p>directoryToSearch - the value provided for the directory to search |
|---|
| 515 | parameter</p></li></ul><ul><li><p>outputWorkspace - the value provided for the output |
|---|
| 516 | workspace parameter</p></li></ul><ul><li><p>inputFile - the absolute path to the input CoastWatch file</p></li></ul><ul><li><p>metadata - a dictionary of CoastWatch metadata about the file and |
|---|
| 517 | variable (see below)</p></li></ul><p>The default expression:</p><dl><dt></dt><dd><pre>os.path.join(outputWorkspace, metadata['Region code'], metadata['Satellite'], 'fronts', metadata['Image datetime'].strftime('%Y'), metadata['Image datetime'].strftime('fr%Y%j%H%M'))</pre></dd></dl><p>stores the raster in the output workspace in a subdirectory structure |
|---|
| 518 | based on the CoastWatch region code, satellite and so on. For example, |
|---|
| 519 | if fronts were detected in the file 2007_066_0459_n17_wn.hdf and the |
|---|
| 520 | output workspace was C:CoastWatch, the output raster path would be:</p><dl><dt></dt><dd><pre>C:\CoastWatch\wn\noaa-17\fronts\2007\fr20070660459</pre></dd></dl><p>The following keys are available in the metadata dictionary. The |
|---|
| 521 | Python data type of the value for the key appears in parentheses. |
|---|
| 522 | Remember that if the value is not a string, you must convert it to one |
|---|
| 523 | before you can use it in Python's os.path function:</p><ul><li><p>'Variable' (str) - Full name of the CoastWatch variable that was |
|---|
| 524 | extracted from the file for processing. At the time of this writing, |
|---|
| 525 | the CoastWatch program was known to have published files with these |
|---|
| 526 | variables:</p><dl><dt></dt><dd><pre>avhrr_ch1 |
|---|
| 527 | avhrr_ch2 |
|---|
| 528 | avhrr_ch3 |
|---|
| 529 | avhrr_ch3a |
|---|
| 530 | avhrr_ch4 |
|---|
| 531 | avhrr_ch5 |
|---|
| 532 | cloud |
|---|
| 533 | cloudx |
|---|
| 534 | graphics |
|---|
| 535 | sst |
|---|
| 536 | rel_azimuth |
|---|
| 537 | sat_zenith |
|---|
| 538 | sun_zenith</pre></dd></dl></li></ul><ul><li><p>'Abbreviation' (str) - 2 character abbreviation for the CoastWatch |
|---|
| 539 | variable that was extracted from the file for processing. These |
|---|
| 540 | abbreviations were invented by the author of this tool, not by the |
|---|
| 541 | CoastWatch program. For the variables mentioned above, the |
|---|
| 542 | abbreviations are:</p><dl><dt></dt><dd><pre>c1 |
|---|
| 543 | c2 |
|---|
| 544 | c3 |
|---|
| 545 | ca |
|---|
| 546 | c4 |
|---|
| 547 | c5 |
|---|
| 548 | cl |
|---|
| 549 | gr |
|---|
| 550 | st |
|---|
| 551 | ra |
|---|
| 552 | sz |
|---|
| 553 | uz</pre></dd></dl></li></ul><ul><li><p>'Region code' (str) - 2 character CoastWatch region code. The |
|---|
| 554 | CoastWatch program assigns the region code, but because the file |
|---|
| 555 | metadata does not include it, the tool must infer it using |
|---|
| 556 | hard-coded rules that examine other metadata such as the image |
|---|
| 557 | coordinates. The tool recognizes the following regions, taken from |
|---|
| 558 | the <a href="http://www2.ncdc.noaa.gov/docs/klm/html/c9/sec9-5.htm">NOAA KLM User's Guide Section 9.5</a> |
|---|
| 559 | amended November 7, 2005:</p><dl><dt></dt><dd><pre>aa - Alaska Sitka |
|---|
| 560 | ax - Alaska South |
|---|
| 561 | gb - Great Barrier Reef |
|---|
| 562 | ay - Alaska West |
|---|
| 563 | az - Alaska North |
|---|
| 564 | ce - Caribbean East |
|---|
| 565 | cw - Caribbean West |
|---|
| 566 | er - East Coast North |
|---|
| 567 | gr - Great Lakes |
|---|
| 568 | hr - Hawaii |
|---|
| 569 | mr - Gulf of Mexico |
|---|
| 570 | sb - East Coast Bermuda |
|---|
| 571 | sl - Great Salt Lake |
|---|
| 572 | sr - East Coast South |
|---|
| 573 | wa - West Coast Acapulco |
|---|
| 574 | wj - West Coast Baja |
|---|
| 575 | wn - West Coast North |
|---|
| 576 | ws - West Coast South |
|---|
| 577 | uk - the CoastWatch region is unknown (the image coordinates were not recognized by this tool)</pre></dd></dl></li></ul><ul><li><p>'Satellite' (str) - satellite that took the image. At the time of |
|---|
| 578 | this writing, the CoastWatch program was known to have published |
|---|
| 579 | data from the following satellites:</p><dl><dt></dt><dd><pre>noaa-12 |
|---|
| 580 | noaa-14 |
|---|
| 581 | noaa-15 |
|---|
| 582 | noaa-16 |
|---|
| 583 | noaa-17 |
|---|
| 584 | noaa-18</pre></dd></dl></li></ul><ul><li><p>'Sensor' (str) - sensor that took the image (e.g. "avhrr").</p></li></ul><ul><li><p>'Image datetime' (datetime.datetime) - date and time the image was |
|---|
| 585 | taken, in UTC.</p></li></ul><ul><li><p>'Image unix time' (int) - date and time the image was taken, in |
|---|
| 586 | "UNIX time" format. UNIX times are 32-bit signed integers that are |
|---|
| 587 | the number of seconds since 1970-01-01 00:00:00 UTC. The UNIX time |
|---|
| 588 | values produced by this tool do not include leap seconds; this tool |
|---|
| 589 | assumes that a regular year is 31536000 seconds and a leap year is |
|---|
| 590 | 31622400 seconds.</p></li></ul><ul><li><p>'Scene time' (str) - the CoastWatch "scene" time for image. At the |
|---|
| 591 | time of this writing, the CoastWatch program was known to have |
|---|
| 592 | published data with the following scene times:</p><dl><dt></dt><dd><pre>day |
|---|
| 593 | day/night |
|---|
| 594 | night</pre></dd></dl></li></ul><ul><li><p>'Projection type' (str) - projection type for the image (e.g. |
|---|
| 595 | "mapped").</p></li></ul><ul><li><p>'Map projection' (str) - map projection for the image (e.g. |
|---|
| 596 | "Mercator").</p></li></ul><ul><li><p>'Map affine a' (float) - the a coefficient for the map affine for the |
|---|
| 597 | file, in meters.</p></li></ul><ul><li><p>'Map affine b' (float) - the b coefficient for the map affine for the |
|---|
| 598 | file, in meters.</p></li></ul><ul><li><p>'Map affine c' (float) - the c coefficient for the map affine for the |
|---|
| 599 | file, in meters.</p></li></ul><ul><li><p>'Map affine d' (float) - the d coefficient for the map affine for the |
|---|
| 600 | file, in meters.</p></li></ul><ul><li><p>'Map affine e' (float) - the e coefficient for the map affine for the |
|---|
| 601 | file, in meters.</p></li></ul><ul><li><p>Map affine f' (float) - the f coefficient for the map affine for the |
|---|
| 602 | file, in meters.</p></li></ul><ul><li><p>'Spheroid' (str) - spheroid used for the image (e.g. "WGS 84").</p></li></ul><ul><li><p>'Origin' (str) - organization that produced the file (e.g. |
|---|
| 603 | "USDOC/NOAA/NESDIS CoastWatch").</p></li></ul><ul><li><p>Format' (str) - format version of the file (e.g. |
|---|
| 604 | "CoastWatch HDF version 3.4").</p></li></ul><ul><li><p>'Pixel width' (float) - the width of each pixel, in km. This should not |
|---|
| 605 | be used as the raster cell size. Please see the CoastWatch |
|---|
| 606 | documentation for more information.</p></li></ul><ul><li><p>'Pixel height' (float) - the height of each pixel, in km. This should not |
|---|
| 607 | be used as the raster cell size. Please see the CoastWatch |
|---|
| 608 | documentation for more information.</p></li></ul><ul><li><p>'Total width' (float) - the width of the image, in km. Please see the |
|---|
| 609 | CoastWatch documentation for more information.</p></li></ul><ul><li><p>'Total height' (float) - the height of the image, in km. Please see the |
|---|
| 610 | CoastWatch documentation for more information.</p></li></ul><ul><li><p>'Center y' (float) - the latitude, in decimal degrees, of the center of |
|---|
| 611 | the image.</p></li></ul><ul><li><p>'Center x' (float) - the longitude, in decimal degrees, of the center of |
|---|
| 612 | the image.</p></li></ul><ul><li><p>'Upper-left y' (float) - the latitude, in decimal degrees, of the upper |
|---|
| 613 | left corner of the image.</p></li></ul><ul><li><p>'Upper-left x' (float) - the longitude, in decimal degrees, of the |
|---|
| 614 | upper left corner of the image.</p></li></ul><ul><li><p>'Upper-right y' (float) - the latitude, in decimal degrees, of the upper |
|---|
| 615 | right corner of the image.</p></li></ul><ul><li><p>'Upper-right x' (float) - the longitude, in decimal degrees, of the |
|---|
| 616 | upper right corner of the image.</p></li></ul><ul><li><p>'Lower-left y' (float) - the latitude, in decimal degrees, of the lower |
|---|
| 617 | left corner of the image.</p></li></ul><ul><li><p>'Lower-left x' (float) - the longitude, in decimal degrees, of the |
|---|
| 618 | lower left corner of the image.</p></li></ul><ul><li><p>'Lower-right y' (float) - the latitude, in decimal degrees, of the lower |
|---|
| 619 | right corner of the image.</p></li></ul><ul><li><p>'Lower-right x' (float) - the longitude, in decimal degrees, of the |
|---|
| 620 | lower right corner of the image.</p></li></ul><ul><li><p>'Type' (str) - the Java data type of the variable (e.g. "short").</p></li></ul><ul><li><p>'Rows' (int) - the number of rows in the image of this variable.</p></li></ul><ul><li><p>'Columns' (int) - the number of columns in the image of this |
|---|
| 621 | variable.</p></li></ul><ul><li><p>'Units' (str) - the units for this variable, or "-" or blank |
|---|
| 622 | if this variable is unitless.</p></li></ul><ul><li><p>'Scale' (float) - the scale factor for computing the true value of this |
|---|
| 623 | variable. Please see the CoastWatch documentation for more |
|---|
| 624 | information.</p></li></ul><ul><li><p>'Offset' (float) - the offset for computing the true value of this |
|---|
| 625 | variable. Please see the CoastWatch documentation for more |
|---|
| 626 | information.</p></li></ul><ul><li><p>'Nav offset y' (float) - the shift, in pixels, that has been applied to the |
|---|
| 627 | variable's image in the north/south direction to georectify it. |
|---|
| 628 | North is positive.</p></li></ul><ul><li><p>'Nav offset x' (float) - the shift, in pixels, that has been applied to the |
|---|
| 629 | variable's image in the east/west direction to georectify it. East |
|---|
| 630 | is positive.</p></li></ul><p>For more information on Python syntax, please see the <a href="http://www.python.org/doc/">Python |
|---|
| 631 | documentation</a>.</p></td></tr><tr><td class="info">{outputMaskRasterPythonExpression}</td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 632 | output raster that shows the pixels of the input image that were |
|---|
| 633 | masked prior to executing the Cayula-Cornillon algorithm. If an |
|---|
| 634 | expression is not provided, this raster will not be created.</p><p>The raster will contain 8-bit integers and have the same dimensions as |
|---|
| 635 | the input image. The value 1 indicates that the corresponding pixel of |
|---|
| 636 | the input image was masked; 0 indicates the pixel was not masked.</p><p>Please see the documentation for the Output Fronts Raster Python |
|---|
| 637 | Expression parameter for more information about writing the Python |
|---|
| 638 | expression.</p></td></tr><tr><td class="info">{outputFilteredImageRasterPythonExpression}</td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 639 | output raster that shows the median-filtered input image. If an |
|---|
| 640 | expression is not provided, this raster will not be created.</p><p>The raster will have the same data type and dimensions as the input |
|---|
| 641 | image (usually 16-bit signed integers). Only the non-masked cells are |
|---|
| 642 | filtered and may change from the values in the input image. Masked |
|---|
| 643 | cells are not filtered and remain unchanged. If median filtering was |
|---|
| 644 | not performed, the entire filtered image will be identical to the |
|---|
| 645 | input image.</p><p>Even though masked cells appear in the filtered image, they are not |
|---|
| 646 | considered in the selection of median values for nearby non-masked |
|---|
| 647 | cells. Only non-masked cells are considered in the selection of median |
|---|
| 648 | values.</p><p>Please see the documentation for the Output Fronts Raster Python |
|---|
| 649 | Expression parameter for more information about writing the Python |
|---|
| 650 | expression.</p></td></tr><tr><td class="info">{outputCandidateCountsRasterPythonExpression}</td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 651 | output raster that indicates how many times the corresponding pixels |
|---|
| 652 | of the input image were candidates for containing fronts, i.e. the |
|---|
| 653 | number of times the pixels appeared in histogram windows that had a |
|---|
| 654 | sufficiently large number of non-masked pixels to proceed with the |
|---|
| 655 | histogramming step of the Cayula-Cornillon algorithm. If an expression |
|---|
| 656 | is not provided, this raster will not be created.</p><p>The raster will contain 16-bit signed integers and have the same |
|---|
| 657 | dimensions as the input image. Because the histogram window stride is |
|---|
| 658 | typically less than the window size, successive histogram windows |
|---|
| 659 | typically overlap, causing many non-masked pixels to have candidate |
|---|
| 660 | counts greater than 1. Masked pixels can never be candidates for |
|---|
| 661 | containing a front and will be marked as NoData.</p><p>Please see the documentation for the Output Fronts Raster Python |
|---|
| 662 | Expression parameter for more information about writing the Python |
|---|
| 663 | expression.</p></td></tr><tr><td class="info">{outputFrontCountsRasterPythonExpression}</td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 664 | output raster indicates how many times fronts were detected at the |
|---|
| 665 | corresponding pixels of the input image. If an expression is not |
|---|
| 666 | provided, this raster will not be created.</p><p>The raster will contain 16-bit signed integers and have the same |
|---|
| 667 | dimensions as the input image. The value will range from 0 (the input |
|---|
| 668 | image pixel never contained a front) to the candidate count value for |
|---|
| 669 | the pixel (it always contained a front in every histogram window that |
|---|
| 670 | contained it). Masked pixels can never be candidates for containing a |
|---|
| 671 | front and will be marked as NoData.</p><p>Please see the documentation for the Output Fronts Raster Python |
|---|
| 672 | Expression parameter for more information about writing the Python |
|---|
| 673 | expression.</p></td></tr><tr><td class="info">{outputWindowStatusCodesRasterPythonExpression}</td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 674 | output raster that indicates the result of the algorithm for the |
|---|
| 675 | histogram window centered on the pixel. You can use this image to |
|---|
| 676 | diagnose why the algorithm did not find fronts in a particular region |
|---|
| 677 | of your image.</p><p>The raster will contain 8-bit signed integers and have the same |
|---|
| 678 | dimensions as the input image. The pixel values will be one of these |
|---|
| 679 | code numbers:</p><ul><li><p>Code 0 - The algorithm was not executed for the window because the |
|---|
| 680 | histogram window stride was greater than 1, causing the algorithm to |
|---|
| 681 | skip over this window.</p></li></ul><ul><li><p>Code 1 - The proportion of the window's pixels that had data was |
|---|
| 682 | found to be too small. This typically occurs when the window occurs |
|---|
| 683 | in a region where many of the pixels are masked due to land, clouds, |
|---|
| 684 | or insufficient satellite coverage.</p></li></ul><ul><li><p>Code 2 - After the histogram algorithm optimally separated the |
|---|
| 685 | window's pixels into two populations, the proportion of pixels |
|---|
| 686 | allocated to the smaller population was found to be too small. This |
|---|
| 687 | can occur when a front occurs in the window, but the window is not |
|---|
| 688 | centered on the front, causing it to contain a disproportionate |
|---|
| 689 | number of pixels from one population. This is usually not a problem. |
|---|
| 690 | As long as the histogram window stride is sufficiently small, the |
|---|
| 691 | histogram window will eventually pass over the front and proceed to |
|---|
| 692 | the next step of the algorithm.</p></li></ul><ul><li><p>Code 3 - After the histogram algorithm optimally separated the |
|---|
| 693 | window's pixels into two populations, the difference between the |
|---|
| 694 | mean values of the two populations was found to be too small. This |
|---|
| 695 | typically happens when the window does not contain a front or when |
|---|
| 696 | the gradient along the front is small (i.e. it is a weak front).</p></li></ul><ul><li><p>Code 4 - After the histogram algorithm optimally separated the |
|---|
| 697 | window's pixels into two populations, the criterion function that |
|---|
| 698 | was calculated was found to be too small (the criterion function is |
|---|
| 699 | theta(Topt) described on pages 71-72 of the 1992 paper). This means |
|---|
| 700 | that the two populations are not sufficiently bimodal to indicate |
|---|
| 701 | that a front exists in the window.</p></li></ul><ul><li><p>Code 5 - The window was found to have two populations that were |
|---|
| 702 | sufficiently proportional, different in their means, and bimodal, |
|---|
| 703 | but the cohesion of one or the other population was insufficient (as |
|---|
| 704 | described by equations 19 and 20 in the 1992 paper). This indicates |
|---|
| 705 | that the cells of the two populations are spatially intermixed like |
|---|
| 706 | a checkerboard, rather than being spatially separate, as occurs when |
|---|
| 707 | a front is present.</p></li></ul><ul><li><p>Code 6 - The window was found to have two populations that were |
|---|
| 708 | sufficiently proportional, different in their means, and bimodal, |
|---|
| 709 | and each population was found to be sufficiently cohesive, but the |
|---|
| 710 | cohesion of the two populations together was insufficient (as |
|---|
| 711 | described by equation 21 of the 1992 paper). As with code 5, this |
|---|
| 712 | indicates that the cells of the two populations are spatially |
|---|
| 713 | intermixed like a checkerboard, rather than being spatially |
|---|
| 714 | separate, as occurs when a front is present.</p></li></ul><ul><li><p>Code 7 - The window passed all of the algorithm's tests and was |
|---|
| 715 | classified as containing a front.</p></li></ul><p>When the width and height of histogram window is an even number, the |
|---|
| 716 | center pixel is the one to the lower right of the exact center of the |
|---|
| 717 | window, which falls at the intersection of four pixels. For example, |
|---|
| 718 | in a 6x6 window, the center pixel is the fourth from the left and |
|---|
| 719 | fourth from the top. |
|---|
| 720 | Please see the documentation for the Output Fronts Raster Python |
|---|
| 721 | Expression parameter for more information about writing the Python |
|---|
| 722 | expression.</p></td></tr><tr><td class="info">{outputWindowStatusValuesRasterPythonExpression}</td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 723 | output raster that you can use in conjunction with the window status |
|---|
| 724 | codes when diagnosing the results of the algorithm.</p><p>The raster will contain 32-bit floating point numbers and have the |
|---|
| 725 | same dimensions as the input image. The value of each pixel depends on |
|---|
| 726 | the window status code for that pixel:</p><ul><li><p>Codes 0, 1, 7 - The pixel value is always 0.0.</p></li></ul><ul><li><p>Code 2 - The pixel value is the proportion of the window's pixels |
|---|
| 727 | that were allocated to the smaller population.</p></li></ul><ul><li><p>Code 3 - The pixel value is the difference in the mean values of |
|---|
| 728 | the window's two populations.</p></li></ul><ul><li><p>Code 4 - The pixel value is the criterion function that was |
|---|
| 729 | calculated for the window.</p></li></ul><ul><li><p>Code 5 - The pixel value is the cohesion of the window's population |
|---|
| 730 | that was found to be insufficiently cohesive. If both populations |
|---|
| 731 | were insufficiently cohesive, it is the cohesion of the "cold" |
|---|
| 732 | population.</p></li></ul><ul><li><p>Code 6 - The pixel value is the cohesion of the window's two |
|---|
| 733 | populations together.</p></li></ul><p>By examining the pixel values, you can determine how to adjust the |
|---|
| 734 | algorithm's parameters to cause more or fewer windows to pass the |
|---|
| 735 | algorithm's tests, increasing or decreasing the number of fronts |
|---|
| 736 | identified in the image. You should only adjust the parameters if you |
|---|
| 737 | feel comfortable deviating from their published values. |
|---|
| 738 | Please see the documentation for the Output Fronts Raster Python |
|---|
| 739 | Expression parameter for more information about writing the Python |
|---|
| 740 | expression.</p></td></tr><tr><td class="info">{modulesToImport;modulesToImport...}</td><td class="info" align="left"><p>Python modules to import prior to evaluating the expression. If |
|---|
| 741 | you need to access Python functions or classes that are provided by a |
|---|
| 742 | module rather than being built-in to the interpreter, list the module |
|---|
| 743 | here. For example, to be able to use the datetime class in your |
|---|
| 744 | expression, list the datetime module here. In your expression, you |
|---|
| 745 | must refer to the class using its fully-qualified name, |
|---|
| 746 | datetime.datetime.</p></td></tr><tr><td class="info">{skipExisting}</td><td class="info" align="left"><p>If True, conversion will be skipped for output rasters that already exist.</p></td></tr></tbody></table></div><p><h2><img width="11" height="11" border="0" src="sm_arrow_down.gif?format=raw" /> Scripting syntax</h2></p><div Class="expand" id="TEST">CoastWatchAVHRRFindCoastWatchFilesAndFindFrontsAsArcGISRasters_GeoEco (inputDirectory, outputWorkspace, wildcard, searchTree, minSize, maxSize, minDateCreated, maxDateCreated, minDateModified, maxDateModified, variables, regionCodes, satellites, minImageDate, maxImageDate, minDayOfYear, maxDayOfYear, sceneTimes, cloudVariable, sunZenithVariable, useDayCloudTest1, useDayCloudTest2, useDayCloudTest3, useDayCloudTest4, useDayCloudTest5, useDayCloudTest6, useDayCloudTest7, maskWhenDayCloudMaskExceeds, useNightCloudTest1, useNightCloudTest2, useNightCloudTest3, useNightCloudTest4, useNightCloudTest5, useNightCloudTest6, useNightCloudTest7, maskWhenNightCloudMaskExceeds, minCloudyNeighbors, medianFilterWindowSize, histogramWindowSize, histogramWindowStride, minPropNonMaskedCells, minPopProp, minPopMeanDifference, minTheta, minSinglePopCohesion, minGlobalPopCohesion, threads, projectedCoordinateSystem, geographicTransformation, resamplingTechnique, projectedCellSize, registrationPoint, clippingRectangle, buildPyramids, outputFrontsRasterPythonExpression, outputMaskRasterPythonExpression, outputFilteredImageRasterPythonExpression, outputCandidateCountsRasterPythonExpression, outputFrontCountsRasterPythonExpression, outputWindowStatusCodesRasterPythonExpression, outputWindowStatusValuesRasterPythonExpression, modulesToImport, skipExisting) <br /><br /><b>Parameters</b><br /><table width="100%" border="0" cellpadding="5"><tbody><tr><th width="40%"><b>Expression</b></th><th width="60%"><b>Explanation</b></th></tr><tr><td class="info">Directory to search (Required) </td><td class="info" align="left"><p>Directory to search.</p></td></tr><tr><td class="info">Output workspace (Required) </td><td class="info" align="left"><p>Workspace to receive the ArcGIS rasters.</p></td></tr><tr><td class="info">Wildcard expression (Optional) </td><td class="info" align="left"><p>UNIX-style "glob" wildcard expression specifying the CoastWatch |
|---|
| 747 | files to find.</p><p>The glob syntax supports the following patterns:</p><ul><li><p>? - matches any single character</p></li></ul><ul><li><p>* - matches zero or more characters</p></li></ul><ul><li><p>[seq] - matches any single character in <i>seq</i></p></li></ul><ul><li><p>[!seq] - matches any single character not in <i>seq</i></p></li></ul><p><i>seq</i> is one or more characters, such as abc. You may specify |
|---|
| 748 | character ranges using a dash. For example, a-z0-9 specifies all of |
|---|
| 749 | the characters in the English alphabet and the decimal digits 0 |
|---|
| 750 | through 9.</p><p>You may specify subdirectories in the glob expression. For example, |
|---|
| 751 | the expression CoastWatch*/2006* will find all files beginning with |
|---|
| 752 | 2006 that are contained in directories beginning with CoastWatch.</p><p>The operating system determines whether / or \ is used as the |
|---|
| 753 | directory separator. On Windows, both will work. On most flavors of |
|---|
| 754 | UNIX, / must be used.</p><p>The operating system determines if matching is case sensitive. On |
|---|
| 755 | Windows, matching is case-insensitive. On most flavors of UNIX, |
|---|
| 756 | matching is case-sensitive.</p><p>It is ok if your expression matches files that are not CoastWatch |
|---|
| 757 | files. For example, the expression *.hdf might match some |
|---|
| 758 | non-CoastWatch HDF files. These files will be ignored.</p></td></tr><tr><td class="info">Search directory tree (Optional) </td><td class="info" align="left"><p>If True, subdirectories will be searched.</p></td></tr><tr><td class="info">Minimum size (Optional) </td><td class="info" align="left"><p>Minimum size, in bytes, of files to find. If provided, only files |
|---|
| 759 | that are this size or larger will be found.</p></td></tr><tr><td class="info">Maximum size (Optional) </td><td class="info" align="left"><p>Maximum size, in bytes, of files to find. If provided, only files |
|---|
| 760 | that are this size or smaller will be found.</p></td></tr><tr><td class="info">Minimum creation date (Optional) </td><td class="info" align="left"><p>Minimum creation date, in the local time zone, of the files to |
|---|
| 761 | find, as reported by the operating system. If provided, only files |
|---|
| 762 | that were created on or after this date will be found. You may provide |
|---|
| 763 | a date with or without a time. If you do not provide a time, it is |
|---|
| 764 | assumed to be midnight.</p></td></tr><tr><td class="info">Maximum creation date (Optional) </td><td class="info" align="left"><p>Maximum creation date, in the local time zone, of the files to |
|---|
| 765 | find, as reported by the operating system. If provided, only files |
|---|
| 766 | that were created on or before this date will be found. You may |
|---|
| 767 | provide a date with or without a time. If you do not provide a time, |
|---|
| 768 | it is assumed to be midnight.</p></td></tr><tr><td class="info">Minimum modification date (Optional) </td><td class="info" align="left"><p>Minimum modification date, in the local time zone, of the files to |
|---|
| 769 | find, as reported by the operating system. If provided, only files |
|---|
| 770 | that were modified on or after this date will be found. You may |
|---|
| 771 | provide a date with or without a time. If you do not provide a time, |
|---|
| 772 | it is assumed to be midnight.</p></td></tr><tr><td class="info">Maximum modification date (Optional) </td><td class="info" align="left"><p>Maximum modification date, in the local time zone, of the files to |
|---|
| 773 | find, as reported by the operating system. If provided, only files |
|---|
| 774 | that were modified on or before this date will be found. You may |
|---|
| 775 | provide a date with or without a time. If you do not provide a time, |
|---|
| 776 | it is assumed to be midnight.</p></td></tr><tr><td class="info">CoastWatch variables (Optional) </td><td class="info" align="left"><p>CoastWatch variables to find in the files that are found. Each |
|---|
| 777 | variable corresponds to an image in the file. If any variables are |
|---|
| 778 | provided, only the images for those variables will be found in the |
|---|
| 779 | files. If none are provided, all images in the files will be found.</p><p>At the time of this writing, the CoastWatch program was known to have |
|---|
| 780 | published files with these variables:</p><dl><dt></dt><dd><pre>avhrr_ch1 |
|---|
| 781 | avhrr_ch2 |
|---|
| 782 | avhrr_ch3 |
|---|
| 783 | avhrr_ch3a |
|---|
| 784 | avhrr_ch4 |
|---|
| 785 | avhrr_ch5 |
|---|
| 786 | cloud |
|---|
| 787 | cloudx |
|---|
| 788 | graphics |
|---|
| 789 | sst |
|---|
| 790 | rel_azimuth |
|---|
| 791 | sat_zenith |
|---|
| 792 | sun_zenith</pre></dd></dl><p>Please see the CoastWatch documentation for more information about |
|---|
| 793 | these variables. In general, most users are interested in the "sst" |
|---|
| 794 | variable, which is the estimated sea surface temperature, and the |
|---|
| 795 | "cloud" variable, which is a bit mask indicating which cloud tests |
|---|
| 796 | failed for that pixel. A value of 0 for the cloud variable indicates |
|---|
| 797 | that all cloud tests passed and CoastWatch has high confidence in the |
|---|
| 798 | validity of the SST value for that pixel.</p></td></tr><tr><td class="info">CoastWatch region codes (Optional) </td><td class="info" align="left"><p>CoastWatch region codes for the files to find. If any regions are |
|---|
| 799 | provided, only files matching those regions will be found. If none are |
|---|
| 800 | provided, all files will be found.</p><p>This function finds the region codes by examining the CoastWatch |
|---|
| 801 | metadata inside the files, not be examining the file name. Thus it |
|---|
| 802 | will work properly with older CoastWatch files that do not include the |
|---|
| 803 | region in the file name.</p><p>Because the CoastWatch metadata does not include the region code |
|---|
| 804 | explicitly, it must be inferred from the other image metadata. The |
|---|
| 805 | current implementation of this function recognizes the following |
|---|
| 806 | regions:</p><dl><dt></dt><dd><pre>aa - Alaska Sitka |
|---|
| 807 | ax - Alaska South |
|---|
| 808 | gb - Great Barrier Reef |
|---|
| 809 | ay - Alaska West |
|---|
| 810 | az - Alaska North |
|---|
| 811 | ce - Caribbean East |
|---|
| 812 | cw - Caribbean West |
|---|
| 813 | er - East Coast North |
|---|
| 814 | gr - Great Lakes |
|---|
| 815 | hr - Hawaii |
|---|
| 816 | mr - Gulf of Mexico |
|---|
| 817 | sb - East Coast Bermuda |
|---|
| 818 | sl - Great Salt Lake |
|---|
| 819 | sr - East Coast South |
|---|
| 820 | wa - West Coast Acapulco |
|---|
| 821 | wj - West Coast Baja |
|---|
| 822 | wn - West Coast North |
|---|
| 823 | ws - West Coast South |
|---|
| 824 | uk - the CoastWatch region is unknown (the image coordinates were not recognized by this tool)</pre></dd></dl><p>These regions were taken from the <a href="http://www2.ncdc.noaa.gov/docs/klm/html/c9/sec9-5.htm">NOAA KLM User's Guide Section 9.5</a> amended |
|---|
| 825 | November 7, 2005. If a file is not for one of these regions, it will |
|---|
| 826 | only be found if you do not specify any region codes. If you would |
|---|
| 827 | like more region codes added to this tool, please contact the |
|---|
| 828 | author.</p></td></tr><tr><td class="info">Satellites (Optional) </td><td class="info" align="left"><p>Satellites for the files to find. If any satellites are provided, |
|---|
| 829 | only files that contain data from these satellites will be found. If |
|---|
| 830 | none are provided, all files will be found.</p><p>At the time of this writing, the CoastWatch program was known to have |
|---|
| 831 | published data from the following satellites:</p><dl><dt></dt><dd><pre>NOAA-12 |
|---|
| 832 | NOAA-14 |
|---|
| 833 | NOAA-15 |
|---|
| 834 | NOAA-16 |
|---|
| 835 | NOAA-17 |
|---|
| 836 | NOAA-18</pre></dd></dl></td></tr><tr><td class="info">Minimum image date (Optional) </td><td class="info" align="left"><p>Minimum image date, in UTC, for the files to find. If provided, |
|---|
| 837 | only files that contain images taken on or after this date will be |
|---|
| 838 | found. You may provide a date with or without a time. If you do not |
|---|
| 839 | provide a time, it is assumed to be midnight.</p></td></tr><tr><td class="info">Maximum image date (Optional) </td><td class="info" align="left"><p>Maximum image date, in UTC, for the files to find. If provided, |
|---|
| 840 | only files that contain images taken on or before this date will be |
|---|
| 841 | found. You may provide a date with or without a time. If you do not |
|---|
| 842 | provide a time, it is assumed to be midnight.</p></td></tr><tr><td class="info">Minimum image day of the year (Optional) </td><td class="info" align="left"><p>Minimum image day of the year, in UTC, for the for the files to |
|---|
| 843 | find. If provided, only files that contain images taken on or after |
|---|
| 844 | this day of the year will be found. The first day of the year is |
|---|
| 845 | always 1, and the last day of the year is 365 during non-leap years |
|---|
| 846 | and 366 during leap years.</p></td></tr><tr><td class="info">Maximum image day of the year (Optional) </td><td class="info" align="left"><p>Maximum image day of the year, in UTC, for the for the files to |
|---|
| 847 | find. If provided, only files that contain images taken on or before |
|---|
| 848 | this day of the year will be found. The first day of the year is |
|---|
| 849 | always 1, and the last day of the year is 365 during non-leap years |
|---|
| 850 | and 366 during leap years.</p></td></tr><tr><td class="info">Scene times (Optional) </td><td class="info" align="left"><p>CoastWatch "scene times" for the files to find. If provided, only |
|---|
| 851 | files that contain images with these scene times will be found. If |
|---|
| 852 | none are provided, all files will be found.</p><p>At the time of this writing, the CoastWatch program was known to have |
|---|
| 853 | published data with the following scene times:</p><dl><dt></dt><dd><pre>day |
|---|
| 854 | day/night |
|---|
| 855 | night</pre></dd></dl><p>The scene time affects which cloud tests are used to generate the |
|---|
| 856 | cloud mask image, among other things. Please consult the CoastWatch |
|---|
| 857 | documentation for more information.</p></td></tr><tr><td class="info">Cloud mask variable (Optional) </td><td class="info" align="left"><p>Name of the CoastWatch variable to extract from the input |
|---|
| 858 | CoastWatch file and use as the cloud mask (e.g. "cloud"). If the input |
|---|
| 859 | file does not contain the cloud variable, cloud masking will not be |
|---|
| 860 | performed for this file.</p><p>A limitation of this tool is that it can only extract the cloud |
|---|
| 861 | variable from the input CoastWatch file; it cannot extract it from |
|---|
| 862 | another file. This tool, therefore, cannot perform cloud masking on |
|---|
| 863 | CWF files (except those that contain the cloud variable), because CWFs |
|---|
| 864 | usually only contain one variable (e.g. sst) in addition to the |
|---|
| 865 | graphics variable. If you need to perform cloud masking on CWF files, |
|---|
| 866 | I recommend you convert the CWFs containing the cloud variable and the |
|---|
| 867 | other variables of interest into a single HDF, and then process the |
|---|
| 868 | HDF instead.</p><p>The current implementation of this tool was designed to operate on the |
|---|
| 869 | 8-bit CLAVR cloud mask represented by the "cloud" variable in |
|---|
| 870 | CoastWatch files. It was not designed to operate on the "cloudx" |
|---|
| 871 | variable, which is a new experimental CLAVR-x cloud mask available in |
|---|
| 872 | recent CoastWatch HDF files. Nonetheless, if you wish to operate on |
|---|
| 873 | the cloudx variable, you can specify it instead of cloud, and pick |
|---|
| 874 | mask options appropriate for it instead.</p></td></tr><tr><td class="info">Solar zenith variable (Optional) </td><td class="info" align="left"><p>Name of the CoastWatch variable to extract from the input |
|---|
| 875 | CoastWatch file and use as the solar zenith image (e.g. "sun_zenith").</p><p>A limitation of this tool is that it can only extract the solar zenith |
|---|
| 876 | image from the input CoastWatch file; it cannot extract it from |
|---|
| 877 | another file. Therefore, because this tool uses the solar zenith image |
|---|
| 878 | when performing cloud masking on images with a day/night scene time, |
|---|
| 879 | cannot perform cloud masking on CWF files, because CWFs usually only |
|---|
| 880 | contain one variable (e.g. sst) in addition to the graphics variable. |
|---|
| 881 | If you need to perform cloud masking on CWF files, I recommend you |
|---|
| 882 | convert the CWFs containing the cloud, sun_zenith, and the other |
|---|
| 883 | variables of interest into a single HDF, and then process the HDF |
|---|
| 884 | instead.</p><p>According to CoastWatch researcher Peter Hollemans, when an image's |
|---|
| 885 | scene time is "day", all pixels of the cloud mask use daytime cloud |
|---|
| 886 | tests, and when it is "night", all pixels use nighttime cloud tests. |
|---|
| 887 | When the scene time is "day/night", the decision of which tests to use |
|---|
| 888 | is based on the solar zenith for that pixel.</p><p>According to Peter, for CoastWatch HDF files, pixels with a solar |
|---|
| 889 | zenith > 80 degrees use the nighttime cloud tests, and <= 80 use the |
|---|
| 890 | daytime cloud tests. This tool implements that logic. If you specify |
|---|
| 891 | that cloud masking should be performed for a day/night image but no |
|---|
| 892 | solar zenith image is available, this tool will assume that nighttime |
|---|
| 893 | cloud tests were used for every pixel and a warning will be issued. |
|---|
| 894 | For some reason, CoastWatch occasionally produces day/night images |
|---|
| 895 | with no sun_zenith or other variables that are present in day images. |
|---|
| 896 | My recollection is that Peter said it is safe to assume for these |
|---|
| 897 | images that all pixels are nighttime.</p><p>The solar zenith image is ignored for scene times other than |
|---|
| 898 | "day/night" (e.g. "day" or "night").</p><p>After some investigation, I find that the cloud mask pixels near the |
|---|
| 899 | 80 degree solar zenith line are problematic, for two reasons:</p><ul><li><p>According to Peter, the solar zenith <= 80 cutoff line is not going |
|---|
| 900 | to line up perfectly with the switch from daytime to nighttime cloud |
|---|
| 901 | tests because the solar zenith angles are rounded to the nearest |
|---|
| 902 | 0.01 when written to the HDF file so a few pixels with values of say |
|---|
| 903 | 80.003 will get rounded to 80 even though they underwent processing |
|---|
| 904 | with the nighttime cloud tests. Peter said, "I guess that's the flaw |
|---|
| 905 | with storing angle data in HDF as scaled integers (that decision was |
|---|
| 906 | mainly due to file size concerns)."</p></li></ul><ul><li><p>The switch between daytime tests and nighttime tests does not |
|---|
| 907 | manifest as a clean transition in the cloud mask pixels. The daytime |
|---|
| 908 | pixels do not seem to cleanly abut the nighttime pixels. Rather, a |
|---|
| 909 | strip of pixels with strange values raggedly separates the two. |
|---|
| 910 | Peter said: "The apparent unclean transition between day and night |
|---|
| 911 | tests is related to neighborhood functions. The uniformity tests |
|---|
| 912 | use a 2x2 box of data values to the right and below a given value in |
|---|
| 913 | the array to check for a condition being true, and the results of |
|---|
| 914 | the uniformity test flag all pixels in the 2x2 box with the test |
|---|
| 915 | results, regardless of whether all those pixels are day or |
|---|
| 916 | nighttime. Both day and nighttime have uniformity tests, so the |
|---|
| 917 | results of uniformity tests at the day/night boundary are mixed. The |
|---|
| 918 | mixing is generally acceptable because the results are intended to |
|---|
| 919 | be used for SST masking not cloud type evaluation and the mixing |
|---|
| 920 | only occurs in cloudy conditions, not clear SST conditions."</p></li></ul><p>Peter said he did not know what was done for CoastWatch day/night CWF |
|---|
| 921 | files. I examined a few of these from the North East region, and it |
|---|
| 922 | appeared that they also switched from daytime to nighttime cloud tests |
|---|
| 923 | in the middle of the image. But the NOAA distribution site |
|---|
| 924 | (<a href="http://www.class.noaa.gov">http://www.class.noaa.gov</a>) only appeared to have CWFs containing the |
|---|
| 925 | sun_zenith variable for dates after late 1999.</p><p>Peter mentioned that the cwangles program from the CoastWatch |
|---|
| 926 | Utilities could compute the solar zenith, but the values would only be |
|---|
| 927 | approximate beacuse the program assumed that all pixels were obtained |
|---|
| 928 | by the sensor at the same moment in time. I tried this approach but |
|---|
| 929 | the 80 degree solar zenith line did not line up with the line where |
|---|
| 930 | the cloud tests appeared to switch. Because of this, I do not believe |
|---|
| 931 | that day/night CWF files will be useable for users who want to use |
|---|
| 932 | some cloud tests and ignore others.</p></td></tr><tr><td class="info">Use daytime Reflective Gross Cloud Test (bit 1) (Optional) </td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Reflective Gross |
|---|
| 933 | Cloud Test (bit 1 of the cloud mask) will be masked. If False, this |
|---|
| 934 | cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 |
|---|
| 935 | test is used for both CWF and HDF files, but for HDF files, the |
|---|
| 936 | CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 937 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 938 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 939 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 940 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 941 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use daytime Reflectance Uniformity Test (bit 2) (Optional) </td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Reflectance |
|---|
| 942 | Uniformity Test (bit 2 of the cloud mask) will be masked. If False, |
|---|
| 943 | this cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 |
|---|
| 944 | test is used for both CWF and HDF files, but for HDF files, the |
|---|
| 945 | CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 946 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 947 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 948 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 949 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 950 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use daytime Reflectance Ratio Cloud Test (bit 3) (Optional) </td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Reflectance Ratio |
|---|
| 951 | Cloud Test (bit 3 of the cloud mask) will be masked. If False, this |
|---|
| 952 | cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, the same CLAVR-1 |
|---|
| 953 | test is used for both CWF and HDF files, but for HDF files, the |
|---|
| 954 | CLAVR-x thresholds are used instead of than of the CLAVR-1 thresholds.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 955 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 956 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 957 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 958 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 959 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use daytime Channel 3 Albedo Test (bit 4) (Optional) </td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Channel 3 Albedo |
|---|
| 960 | Test (bit 4 of the cloud mask) will be masked. If False, this cloud |
|---|
| 961 | test will be ignored.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 962 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 963 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 964 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 965 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 966 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use daytime Thermal Uniformity Test (bit 5) (Optional) </td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Thermal Uniformity |
|---|
| 967 | Test (bit 5 of the cloud mask) will be masked. If False, this cloud |
|---|
| 968 | test will be ignored.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 969 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 970 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 971 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 972 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 973 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use daytime Four Minus Five Test (bit 6) (Optional) </td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Four Minus Five |
|---|
| 974 | Test (bit 6 of the cloud mask) will be masked. If False, this cloud |
|---|
| 975 | test will be ignored.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 976 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 977 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 978 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 979 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 980 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use daytime Thermal Gross Cloud Test (bit 7) (Optional) </td><td class="info" align="left"><p>If True, daytime pixels that failed the CLAVR-1 Thermal Gross |
|---|
| 981 | Cloud Test (bit 7 of the cloud mask) will be masked. If False, this |
|---|
| 982 | cloud test will be ignored.</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 983 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 984 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 985 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 986 | indicates it failed. For more details about the cloud tests, please see the |
|---|
| 987 | CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Mask when daytime cloud mask exceeds value (Optional) </td><td class="info" align="left"><p>If a value is provided, daytime pixels with a cloud mask value |
|---|
| 988 | greater than this value will be masked.</p><p>The CoastWatch cloud mask is a bitmask, where each bit represents the |
|---|
| 989 | success (0) or failure (1) of a given CLAVR cloud test. Thus the cloud |
|---|
| 990 | mask values are NOT intended to be interpreted as range, like a |
|---|
| 991 | spectrum, where 0 represents "very clear" and 255 represents "very |
|---|
| 992 | cloudy". Nevertheless, some users of this tool determined that for |
|---|
| 993 | their study the best tradeoff between minimizing SST error and |
|---|
| 994 | minimizing the number of pixels masked by clouds was obtained by |
|---|
| 995 | masking all pixels where the cloud mask exceeded a certain value. This |
|---|
| 996 | option was implemented specifically for those users and is not |
|---|
| 997 | recommended for general use. If you do use this option, be sure to |
|---|
| 998 | study many cloud mask images before selecting a value.</p><p>If a value is provided both for this parameter and for the cloud test |
|---|
| 999 | bits specified by the previous parameters, all of these parameters |
|---|
| 1000 | will be effective. In other words, a cloudy pixel can be masked by |
|---|
| 1001 | failing a specific cloud test, or by exceeding the minimum cloud mask |
|---|
| 1002 | value, or both. .</p><p>This parameter is ignored for nighttime pixels. For a discussion of |
|---|
| 1003 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 1004 | documentation for the cloud mask file parameter. For more information |
|---|
| 1005 | about the cloud tests, please see the CoastWatch and CLAVR |
|---|
| 1006 | documentation.</p></td></tr><tr><td class="info">Use nighttime Thermal Gross Cloud Test (bit 1) (Optional) </td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Thermal Gross |
|---|
| 1007 | Cloud Test (bit 1 of the cloud mask) will be masked. If False, this |
|---|
| 1008 | cloud test will be ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 1009 | pixels are classified as daytime or nighttime, please see the |
|---|
| 1010 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 1011 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 1012 | indicates it failed. For more details about the cloud tests, please |
|---|
| 1013 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use nighttime Thermal Uniformity Test (bit 2) (Optional) </td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Thermal |
|---|
| 1014 | Uniformity Test (bit 2 of the cloud mask) will be masked. If False, |
|---|
| 1015 | this cloud test will be ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 1016 | pixels are classified as daytime or nighttime, please see the |
|---|
| 1017 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 1018 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 1019 | indicates it failed. For more details about the cloud tests, please |
|---|
| 1020 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use nighttime Uniform Low Stratus Test (bit 3) (Optional) </td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Uniform Low |
|---|
| 1021 | Stratus Test (bit 3 of the cloud mask) will be masked. If False, this |
|---|
| 1022 | cloud test will be ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 1023 | pixels are classified as daytime or nighttime, please see the |
|---|
| 1024 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 1025 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 1026 | indicates it failed. For more details about the cloud tests, please |
|---|
| 1027 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use nighttime Four Minus Five Test (bit 4) (Optional) </td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Four Minus Five |
|---|
| 1028 | Test (bit 4 of the cloud mask) will be masked. If False, this cloud |
|---|
| 1029 | test will be ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 1030 | pixels are classified as daytime or nighttime, please see the |
|---|
| 1031 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 1032 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 1033 | indicates it failed. For more details about the cloud tests, please |
|---|
| 1034 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use nighttime Cirrus Test (bit 5) (Optional) </td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-1 Cirrus Test (bit |
|---|
| 1035 | 5 of the cloud mask) will be masked. If False, this cloud test will be |
|---|
| 1036 | ignored.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 1037 | pixels are classified as daytime or nighttime, please see the |
|---|
| 1038 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 1039 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 1040 | indicates it failed. For more details about the cloud tests, please |
|---|
| 1041 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use nighttime Channel 3B Albedo Test (bit 6) (Optional) </td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-x Channel 3B |
|---|
| 1042 | Albedo Test (bit 6 of the cloud mask) will be masked. If False, this |
|---|
| 1043 | cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, this test was not |
|---|
| 1044 | used for CoastWatch CWF files and thus bit 6 will always be 0, |
|---|
| 1045 | indicating success, for CWF nighttime cloud mask pixels.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 1046 | pixels are classified as daytime or nighttime, please see the |
|---|
| 1047 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 1048 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 1049 | indicates it failed. For more details about the cloud tests, please |
|---|
| 1050 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Use nighttime Channel 3B Albedo Uniformity Test (bit 7) (Optional) </td><td class="info" align="left"><p>If True, nighttime pixels that failed the CLAVR-x Channel 3B |
|---|
| 1051 | Albedo Uniformity Test (bit 7 of the cloud mask) will be masked. If |
|---|
| 1052 | False, this cloud test will be ignored.</p><p>According to CoastWatch researcher Peter Hollemans, this test was not |
|---|
| 1053 | used for CoastWatch CWF files and thus bit 7 will always be 0, |
|---|
| 1054 | indicating success, for CWF nighttime cloud mask pixels.</p><p>This parameter is ignored for daytime pixels. For a discussion of how |
|---|
| 1055 | pixels are classified as daytime or nighttime, please see the |
|---|
| 1056 | documentation for the cloud mask file parameter.</p><p>In CoastWatch cloud masks, bit 1 is the least significant bit, and a |
|---|
| 1057 | value of 0 for a bit indicates that the cloud test passed, while 1 |
|---|
| 1058 | indicates it failed. For more details about the cloud tests, please |
|---|
| 1059 | see the CoastWatch and CLAVR documentation.</p></td></tr><tr><td class="info">Mask when nighttime cloud mask exceeds value (Optional) </td><td class="info" align="left"><p>If a value is provided, nighttime pixels with a cloud mask value |
|---|
| 1060 | greater than this value will be masked.</p><p>The CoastWatch cloud mask is a bitmask, where each bit represents the |
|---|
| 1061 | success (0) or failure (1) of a given CLAVR cloud test. Thus the cloud |
|---|
| 1062 | mask values are NOT intended to be interpreted as range, like a |
|---|
| 1063 | spectrum, where 0 represents "very clear" and 255 represents "very |
|---|
| 1064 | cloudy". Nevertheless, some users of this tool determined that for |
|---|
| 1065 | their study the best tradeoff between minimizing SST error and |
|---|
| 1066 | minimizing the number of pixels masked by clouds was obtained by |
|---|
| 1067 | masking all pixels where the cloud mask exceeded a certain value. This |
|---|
| 1068 | option was implemented specifically for those users and is not |
|---|
| 1069 | recommended for general use. If you do use this option, be sure to |
|---|
| 1070 | study many cloud mask images before selecting a value.</p><p>If a value is provided both for this parameter and for the cloud test |
|---|
| 1071 | bits specified by the previous parameters, all of these parameters |
|---|
| 1072 | will be effective. In other words, a cloudy pixel can be masked by |
|---|
| 1073 | failing a specific cloud test, or by exceeding the minimum cloud mask |
|---|
| 1074 | value, or both. .</p><p>This parameter is ignored for daytime pixels. For a discussion of |
|---|
| 1075 | how pixels are classified as daytime or nighttime, please see the |
|---|
| 1076 | documentation for the cloud mask file parameter. For more information |
|---|
| 1077 | about the cloud tests, please see the CoastWatch and CLAVR |
|---|
| 1078 | documentation.</p></td></tr><tr><td class="info">Minimum number of cloudy neighbors (Optional) </td><td class="info" align="left"><p>Minimum number of neighbors that a cloudy pixel must have in order |
|---|
| 1079 | for that pixel to be masked.</p><p>You can use this option to ignore isolated cloudy pixels that are not |
|---|
| 1080 | clumped together. For example, if you specify the value 1, cloudy |
|---|
| 1081 | pixels will be ignored and not used in the masking process unless at |
|---|
| 1082 | least one of their eight neighbors is also cloudy.</p><p>If a neighbor is not cloudy but it is masked for some other reason |
|---|
| 1083 | (e.g. it is land), it does not count as being cloudy.</p><p>This option is ignored when cloud masking is not performed.</p></td></tr><tr><td class="info">Median filter window size (Optional) </td><td class="info" align="left"><p>Window size, in pixels, of the median filter to apply to the input |
|---|
| 1084 | image prior to running the histogram analysis step of the |
|---|
| 1085 | Cayula-Cornillon algorithm. If not provided, median filtering will not |
|---|
| 1086 | be performed.</p><p>If you provide a value, it must be an odd integer greater than or |
|---|
| 1087 | equal to 3. The filter window is square and advances across the image |
|---|
| 1088 | 1 pixel at a time. The center pixel, if it is not masked, is replaced |
|---|
| 1089 | with the median value of the non-masked pixels in the surrounding |
|---|
| 1090 | window. All masks are applied before the median filter is executed.</p><p>Median filtering is a traditional first step for certain classes of |
|---|
| 1091 | edge detection algorithms. The original Cayula-Cornillon paper used a |
|---|
| 1092 | window size of 3.</p></td></tr><tr><td class="info">Histogram window size (Optional) </td><td class="info" align="left"><p>Size of the histogram window to use for the Cayula-Cornillon |
|---|
| 1093 | algorithm.</p><p>The window is square. The original paper used a window size of 32. |
|---|
| 1094 | Although the algorithm is claimed to obtain similar results regardless |
|---|
| 1095 | of window size, I have noticed that some fronts may only be detected |
|---|
| 1096 | by using a smaller window size such as 16. I highly recommend you read |
|---|
| 1097 | the paper carefully before experimenting with different window |
|---|
| 1098 | sizes.</p></td></tr><tr><td class="info">Histogram window stride (Optional) </td><td class="info" align="left"><p>Number of pixels to move the histogram window after each iteration |
|---|
| 1099 | of the Cayula-Cornillon algorithm.</p><p>The original paper used a 32x32 window and a stride of 16, to minimize |
|---|
| 1100 | the CPU time required to execute the algorithm. Cutting the stride in |
|---|
| 1101 | half increases the CPU time by a factor of about four. For example, a |
|---|
| 1102 | stride of 1 requires about 256 times more CPU time than a stride of |
|---|
| 1103 | 16.</p><p>In my experience, smaller stride values identify more fronts, and the |
|---|
| 1104 | resulting fronts are longer and thicker. If you have a powerful |
|---|
| 1105 | computer, want to find more fronts, and are comfortable deviating from |
|---|
| 1106 | the published method, you can use a smaller value. If you do this, you |
|---|
| 1107 | may want to apply a thinning algorithm after running this tool, to |
|---|
| 1108 | reduce the widths of the resulting fronts.</p></td></tr><tr><td class="info">Minimum proportion of non-masked pixels (Optional) </td><td class="info" align="left"><p>Minimum proportion of pixels in a histogram window that must not |
|---|
| 1109 | be masked for the algorithm to proceed with histogram analysis on that |
|---|
| 1110 | window.</p><p>For example, if the value 0.75 is used and the histogram window is |
|---|
| 1111 | 20x20, at least 300 out of the 400 pixels must not be masked for |
|---|
| 1112 | analysis to proceed on that window. If more than 100 pixels are |
|---|
| 1113 | masked, the algorithm discards the current window, advances to next |
|---|
| 1114 | one, and starts over.</p><p>The Fortran code I obtained from Dave Ullman used the value 0.65.</p></td></tr><tr><td class="info">Minimum proportion of smaller population (Optional) </td><td class="info" align="left"><p>Minimum proportional size of the smaller population.</p><p>If the histogram algorithm determines that the values of the |
|---|
| 1115 | non-masked pixels in the window have a bimodal distribution, it then |
|---|
| 1116 | selects the value that optimally separates them into two populations. |
|---|
| 1117 | As described on page 73 of the 1992 paper, if the proportion of |
|---|
| 1118 | non-masked pixels allocated to the smaller population is smaller than |
|---|
| 1119 | 0.25, the subsequent statistical tests will not be accurate. In this |
|---|
| 1120 | case, and the algorithm discards the current window, advances to next |
|---|
| 1121 | one, and starts over.</p><p>I do not recommend selecting a value other than 0.25 unless you |
|---|
| 1122 | understand the statistical analysis presented in the 1992 paper.</p></td></tr><tr><td class="info">Minimum population mean difference (Optional) </td><td class="info" align="left"><p>Minimum difference in population means.</p><p>After the histogram algorithm separates the non-masked pixels into two |
|---|
| 1123 | populations, it computes the means of the two populations. If the |
|---|
| 1124 | means differ by less than this parameter value, the algorithm discards |
|---|
| 1125 | the current window, advances to next one, and starts over.</p><p>The original intent of this parameter is obscure. The Fortran code I |
|---|
| 1126 | obtained from Dave Ullman used the value 3 and contained the |
|---|
| 1127 | explanation "a temperature difference of less than three digital |
|---|
| 1128 | counts between the 2 populations is likely to be a result of the |
|---|
| 1129 | discrete nature of the data."</p><p>You can use this parameter to eliminate weak fronts by selecting a |
|---|
| 1130 | value that corresponds to a desired minimum mean temperature |
|---|
| 1131 | difference. For example, the NOAA NODC 4km AVHRR Pathfinder Project |
|---|
| 1132 | (<a href="http://www.nodc.noaa.gov/SatelliteData/pathfinder4km/">http://www.nodc.noaa.gov/SatelliteData/pathfinder4km/</a>) publishes SST |
|---|
| 1133 | data as 16-bit unsigned integers where each integer represents 0.075 |
|---|
| 1134 | degrees. To eliminate fronts where the mean temperature difference is |
|---|
| 1135 | less than 0.5 degrees, set this parameter to 0.5 / 0.075 = |
|---|
| 1136 | 6.666667.</p></td></tr><tr><td class="info">Minimum value for criterion function (Optional) </td><td class="info" align="left"><p>Minimum criterion function, theta(Topt), as described on pages |
|---|
| 1137 | 71-72 of the 1992 paper.</p><p>The criterion function is used to determine whether the histogram |
|---|
| 1138 | window contains a bimodal distribution. Cayula and Cornillon performed |
|---|
| 1139 | an extensive analysis to determine that the value 0.76 produced |
|---|
| 1140 | optimal results for the SST data they worked with. Selecting a smaller |
|---|
| 1141 | value will allow windows with more homogenous, less bimodal |
|---|
| 1142 | distributions to be considered by the algorithm. If the window yields |
|---|
| 1143 | a value less than this parameter, the algorithm discards the current |
|---|
| 1144 | window, advances to next one, and starts over.</p><p>I do not recommend selecting a value other than 0.76 unless you |
|---|
| 1145 | understand the statistics presented in the original paper.</p></td></tr><tr><td class="info">Minimum single-population cohesion (Optional) </td><td class="info" align="left"><p>Minimum cohesion of a single population.</p><p>If the histogram window is found to have a sufficiently bimodal |
|---|
| 1146 | distribution of values, the cohesion algorithm is executed to check |
|---|
| 1147 | whether the pixels of the two populations are sufficiently spatially |
|---|
| 1148 | separated. High values indicate that they are separated, suggesting |
|---|
| 1149 | that two distinct populations (e.g. water masses) are present in the |
|---|
| 1150 | window. Low values indicate the populations are all mixed up, like a |
|---|
| 1151 | checkerboard, and suggest that the pattern results from clouds, noise |
|---|
| 1152 | or other random processes.</p><p>The first part of the cohesion algorithm checks the cohesion of each |
|---|
| 1153 | population by itself (equations 19 and 20 in the 1992 paper). As |
|---|
| 1154 | described in Appendix B of the 1992 paper, the optimal cohesion |
|---|
| 1155 | coefficients depend on the size of the histogram window. Cayula and |
|---|
| 1156 | Cornillon used the value 0.90 for a 32x32 window, which was |
|---|
| 1157 | calculated:</p><dl><dt></dt><dd><pre>C = 1.0 - 0.02 - 1/winsize - 2*P(error) = 0.98 - 1/32 - 2(0.025) = 0.90</pre></dd></dl><p>For a 16x16 window, the equation evaluates to 0.8675.</p></td></tr><tr><td class="info">Minimum global-population cohesion (Optional) </td><td class="info" align="left"><p>Minimum cohesion of both populations.</p><p>The second part of the cohesion algorithm checks the cohesion of both |
|---|
| 1158 | populations together (equation 21 in the 1992 paper). As described in |
|---|
| 1159 | Appendix B of the 1992 paper, the optimal cohesion coefficients depend |
|---|
| 1160 | on the size of the histogram window. Cayula and Cornillon used the |
|---|
| 1161 | value 0.92 for a 32x32 window, which was calculated:</p><dl><dt></dt><dd><pre>C = 1.0 - 1/winsize - 2*P(error) = 1.0 - 1/32 - 2(0.025) = 0.92</pre></dd></dl><p>For a 16x16 window, the equation evaluates to 0.8875.</p></td></tr><tr><td class="info">Processing threads (Optional) </td><td class="info" align="left"><p>Number of threads to start for parallel processing.</p><p>The histogram and cohesion algorithms are CPU intensive but are |
|---|
| 1162 | designed to run in parallel on machines that have multiple processors. |
|---|
| 1163 | To maximize utilization of your machine's processors and shorten the |
|---|
| 1164 | time required to execute the algorithms, set the number of threads to |
|---|
| 1165 | the number of processors you wish to utilize. Do not set the number of |
|---|
| 1166 | threads to more than the number of processors you have; this will |
|---|
| 1167 | reduce performance.</p><p>For this option to have any effect, your version of Python must |
|---|
| 1168 | include the threading module. Most recent versions of Python include |
|---|
| 1169 | this module.</p></td></tr><tr><td class="info">Project to new coordinate system (Optional) </td><td class="info" align="left"><p>New coordinate system to project the output raster to.</p><p>The raster may only be projected to a new coordinate system if the |
|---|
| 1170 | original projection is defined. An error will be raised if you specify |
|---|
| 1171 | a new coordinate system without defining the original coordinate |
|---|
| 1172 | system.</p><p>The ArcGIS Project Raster tool is used to perform the projection. The |
|---|
| 1173 | documentation for that tool recommends that you also specify a cell |
|---|
| 1174 | size for the new coordinate system.</p><p>I have noticed that for certain coordinate systems the ArcGIS 9.2 |
|---|
| 1175 | Project Raster tool seems to clip the projected raster to an arbitrary |
|---|
| 1176 | extent that is too small. For example, when projecting a global MODIS |
|---|
| 1177 | Aqua 4 km chlorophyll image in geographic coordinates to |
|---|
| 1178 | Lambert_Azimuthal_Equal_Area with central meridian of -60 and latitude |
|---|
| 1179 | of origin of -63, the resulting image is clipped to show only |
|---|
| 1180 | one-quarter of the planet. This problem does not occur when Project |
|---|
| 1181 | Raster is invoked interactively from the ArcGIS user interface; it |
|---|
| 1182 | only occurs when the tool is invoked programmatically (the |
|---|
| 1183 | ProjectRaster_management method of the geoprocessor). Thus you may |
|---|
| 1184 | not see it when you use Project Raster yourself but it may happen when |
|---|
| 1185 | you use MGET tools that invoke Project Raster as part of their |
|---|
| 1186 | geoprocessing operations.</p><p>If you encounter this problem, you can work around it like this:</p><ul><li><p>First, run this tool without specifying a new coordinate system, to |
|---|
| 1187 | obtain the output raster in the original coordinate system.</p></li></ul><ul><li><p>In ArcCatalog, use the Project Raster tool to project the raster to |
|---|
| 1188 | the new coordinate system. Verify that the entire raster is present, |
|---|
| 1189 | that it has not been clipped to an extent that is too small.</p></li></ul><ul><li><p>In ArcCatalog, look up the extent of the projected raster by |
|---|
| 1190 | right-clicking on it in the catalog tree, selecting Properties, and |
|---|
| 1191 | scrolling down to Extent.</p></li></ul><ul><li><p>Now, before running the MGET tool that projects the raster, set the |
|---|
| 1192 | Extent environment setting to the values you looked up. If you are |
|---|
| 1193 | invoking the MGET tool interactively from ArcCatalog or ArcMap, |
|---|
| 1194 | click the Environments button on the tool's dialog box, open General |
|---|
| 1195 | Settings, change the Extent drop-down to "As Specified Below", and |
|---|
| 1196 | type in the values you looked up. If you're invoking it from a |
|---|
| 1197 | geoprocessing model, right-click on the tool in the model, select |
|---|
| 1198 | Make Variable, From Environment, General Settings, Extent. This will |
|---|
| 1199 | place Extent as a variable in your model, attached to the MGET tool. |
|---|
| 1200 | Open the Extent variable, change it to "As Specified Below" and type |
|---|
| 1201 | in the values you looked up. If you're invoking the MGET tool |
|---|
| 1202 | programmatically, you must set the Extent property of the |
|---|
| 1203 | geoprocessor to the values you looked up. Please see the ArcGIS |
|---|
| 1204 | documentation for more information about this and Environment |
|---|
| 1205 | settings in general.</p></li></ul><ul><li><p>Run the MGET tool. The extent of the output raster should now be the |
|---|
| 1206 | proper size.</p></li></ul></td></tr><tr><td class="info">Geographic transformation (Optional) </td><td class="info" align="left"><p>A transformation method used to convert between the original |
|---|
| 1207 | coordinate system and the new coordinate system.</p><p>This parameter is a new option introduced by ArcGIS 9.2. You must have |
|---|
| 1208 | ArcGIS 9.2 to use this parameter.</p><p>This parameter is only needed when you specify that the raster should |
|---|
| 1209 | be projected to a new coordinate system and that new system uses a |
|---|
| 1210 | different datum than the original coordinate system, or there is some |
|---|
| 1211 | other difference between the two coordinate systems that requires a |
|---|
| 1212 | transformation. To determine if a transformation is needed, I |
|---|
| 1213 | recommend the following procedure:</p><ul><li><p>First, run this tool without specifying a new coordinate system, to |
|---|
| 1214 | obtain the output raster in the original coordinate system.</p></li></ul><ul><li><p>Next, use the ArcGIS 9.2 Project Raster tool on the output raster to |
|---|
| 1215 | project it to the desired coordinate system. If a geographic |
|---|
| 1216 | transformation is needed, that tool will prompt you for one. Write |
|---|
| 1217 | down the exact name of the transformation you used.</p></li></ul><ul><li><p>Finally, if a transformation was needed, type in the exact name into |
|---|
| 1218 | this tool, rerun it, and verify that the output raster was projected |
|---|
| 1219 | as you desired.</p></li></ul></td></tr><tr><td class="info">Projection resampling technique (Optional) </td><td class="info" align="left"><p>The resampling algorithm to be used to project the original raster |
|---|
| 1220 | to a new coordinate system. The ArcGIS Project Raster tool is used to |
|---|
| 1221 | perform the projection and accepts the following values:</p><ul><li><p>NEAREST - nearest neighbor interpolation</p></li></ul><ul><li><p>BILINEAR - bilinear interpolation</p></li></ul><ul><li><p>CUBIC - cubic convolution</p></li></ul><p>You must specify one of these algorithms to project to a new |
|---|
| 1222 | coordinate system. An error will be raised if you specify a new |
|---|
| 1223 | coordinate system without selecting an algorithm.</p></td></tr><tr><td class="info">Cell size for projected coordinate system (Optional) </td><td class="info" align="left"><p>The cell size of the projected coordinate system. Although this |
|---|
| 1224 | parameter is optional, to receive the best results, the ArcGIS |
|---|
| 1225 | documentation recommends you always specify it when projecting to a |
|---|
| 1226 | new coordinate system.</p></td></tr><tr><td class="info">Registration point for projected coordinate system (Optional) </td><td class="info" align="left"><p>The x and y coordinates (in the output space) used for pixel |
|---|
| 1227 | alignment.</p><p>This parameter is a new option introduced by ArcGIS 9.2. You must have |
|---|
| 1228 | ArcGIS 9.2 to use this parameter. It is ignored if you do not specify |
|---|
| 1229 | that the raster should be projected to a new coordinate system.</p></td></tr><tr><td class="info">Clip to rectangle (Optional) </td><td class="info" align="left"><p>Rectangle to which the raster should be clipped.</p><p>If a projected coordinate system was specified, the clipping is |
|---|
| 1230 | performed after the projection and the rectangle's coordinates should |
|---|
| 1231 | be specified in the new coordinate system. If no projected coordinate |
|---|
| 1232 | system was specified, the coordinates should be specified in the |
|---|
| 1233 | original coordinate system.</p><p>The ArcGIS Clip tool is used to perfom the clip. The clipping |
|---|
| 1234 | rectangle must be passed to this tool as a string of four numbers |
|---|
| 1235 | separated by spaces. The ArcGIS user interface automatically formats |
|---|
| 1236 | the string properly; when invoking this tool from the ArcGIS UI, |
|---|
| 1237 | you need not worry about the format. But when invoking it |
|---|
| 1238 | programmatically, take care to provide a properly-formatted string. |
|---|
| 1239 | The numbers are ordered LEFT, BOTTOM, RIGHT, TOP. For example, if the |
|---|
| 1240 | raster is in a geographic coordinate system, it may be clipped to 10 |
|---|
| 1241 | W, 15 S, 20 E, and 25 N with the string:</p><dl><dt></dt><dd><p>10 15 20 25</p></dd></dl><p>Integers or decimal numbers may be provided.</p></td></tr><tr><td class="info">Build pyramids (Optional) </td><td class="info" align="left"><p>If True, pyramids will be built for the output raster, which will |
|---|
| 1242 | improve its display speed in the ArcGIS user interface. This is the |
|---|
| 1243 | last step performed in post-conversion processing.</p></td></tr><tr><td class="info">Output fronts raster Python expression (Optional) </td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 1244 | output raster that shows the fronts detected in the input image.</p><p>The raster will have the same dimensions as the input image and |
|---|
| 1245 | contain 8-bit signed integers with three possible values:</p><ul><li><p>NoData - the pixel was never a candidate for containing a front, |
|---|
| 1246 | either because it was masked or because because it did not appear in |
|---|
| 1247 | any histogram windows that had sufficiently large numbers of |
|---|
| 1248 | non-masked pixels to proceed with the histogramming step of the |
|---|
| 1249 | Cayula-Cornillon algorithm.</p></li></ul><ul><li><p>0 - The pixel was a candidate for containing a front -- it was not |
|---|
| 1250 | masked and it appeared in at least one histogram window with a |
|---|
| 1251 | sufficient number of non-masked pixels to proceed with the |
|---|
| 1252 | histogramming step -- but it was never marked as a front pixel in |
|---|
| 1253 | any of the histogram windows it appeared in.</p></li></ul><ul><li><p>1 - The pixel was a candidate for containing a front and it was marked |
|---|
| 1254 | as a front pixel in at least one of the histogram windows it |
|---|
| 1255 | appeared in.</p></li></ul><p>The expression may be any Python statement appropriate for passing to |
|---|
| 1256 | the eval function and must return a Unicode string. The expression may |
|---|
| 1257 | reference the following variables:</p><ul><li><p>directoryToSearch - the value provided for the directory to search |
|---|
| 1258 | parameter</p></li></ul><ul><li><p>outputWorkspace - the value provided for the output |
|---|
| 1259 | workspace parameter</p></li></ul><ul><li><p>inputFile - the absolute path to the input CoastWatch file</p></li></ul><ul><li><p>metadata - a dictionary of CoastWatch metadata about the file and |
|---|
| 1260 | variable (see below)</p></li></ul><p>The default expression:</p><dl><dt></dt><dd><pre>os.path.join(outputWorkspace, metadata['Region code'], metadata['Satellite'], 'fronts', metadata['Image datetime'].strftime('%Y'), metadata['Image datetime'].strftime('fr%Y%j%H%M'))</pre></dd></dl><p>stores the raster in the output workspace in a subdirectory structure |
|---|
| 1261 | based on the CoastWatch region code, satellite and so on. For example, |
|---|
| 1262 | if fronts were detected in the file 2007_066_0459_n17_wn.hdf and the |
|---|
| 1263 | output workspace was C:CoastWatch, the output raster path would be:</p><dl><dt></dt><dd><pre>C:\CoastWatch\wn\noaa-17\fronts\2007\fr20070660459</pre></dd></dl><p>The following keys are available in the metadata dictionary. The |
|---|
| 1264 | Python data type of the value for the key appears in parentheses. |
|---|
| 1265 | Remember that if the value is not a string, you must convert it to one |
|---|
| 1266 | before you can use it in Python's os.path function:</p><ul><li><p>'Variable' (str) - Full name of the CoastWatch variable that was |
|---|
| 1267 | extracted from the file for processing. At the time of this writing, |
|---|
| 1268 | the CoastWatch program was known to have published files with these |
|---|
| 1269 | variables:</p><dl><dt></dt><dd><pre>avhrr_ch1 |
|---|
| 1270 | avhrr_ch2 |
|---|
| 1271 | avhrr_ch3 |
|---|
| 1272 | avhrr_ch3a |
|---|
| 1273 | avhrr_ch4 |
|---|
| 1274 | avhrr_ch5 |
|---|
| 1275 | cloud |
|---|
| 1276 | cloudx |
|---|
| 1277 | graphics |
|---|
| 1278 | sst |
|---|
| 1279 | rel_azimuth |
|---|
| 1280 | sat_zenith |
|---|
| 1281 | sun_zenith</pre></dd></dl></li></ul><ul><li><p>'Abbreviation' (str) - 2 character abbreviation for the CoastWatch |
|---|
| 1282 | variable that was extracted from the file for processing. These |
|---|
| 1283 | abbreviations were invented by the author of this tool, not by the |
|---|
| 1284 | CoastWatch program. For the variables mentioned above, the |
|---|
| 1285 | abbreviations are:</p><dl><dt></dt><dd><pre>c1 |
|---|
| 1286 | c2 |
|---|
| 1287 | c3 |
|---|
| 1288 | ca |
|---|
| 1289 | c4 |
|---|
| 1290 | c5 |
|---|
| 1291 | cl |
|---|
| 1292 | gr |
|---|
| 1293 | st |
|---|
| 1294 | ra |
|---|
| 1295 | sz |
|---|
| 1296 | uz</pre></dd></dl></li></ul><ul><li><p>'Region code' (str) - 2 character CoastWatch region code. The |
|---|
| 1297 | CoastWatch program assigns the region code, but because the file |
|---|
| 1298 | metadata does not include it, the tool must infer it using |
|---|
| 1299 | hard-coded rules that examine other metadata such as the image |
|---|
| 1300 | coordinates. The tool recognizes the following regions, taken from |
|---|
| 1301 | the <a href="http://www2.ncdc.noaa.gov/docs/klm/html/c9/sec9-5.htm">NOAA KLM User's Guide Section 9.5</a> |
|---|
| 1302 | amended November 7, 2005:</p><dl><dt></dt><dd><pre>aa - Alaska Sitka |
|---|
| 1303 | ax - Alaska South |
|---|
| 1304 | gb - Great Barrier Reef |
|---|
| 1305 | ay - Alaska West |
|---|
| 1306 | az - Alaska North |
|---|
| 1307 | ce - Caribbean East |
|---|
| 1308 | cw - Caribbean West |
|---|
| 1309 | er - East Coast North |
|---|
| 1310 | gr - Great Lakes |
|---|
| 1311 | hr - Hawaii |
|---|
| 1312 | mr - Gulf of Mexico |
|---|
| 1313 | sb - East Coast Bermuda |
|---|
| 1314 | sl - Great Salt Lake |
|---|
| 1315 | sr - East Coast South |
|---|
| 1316 | wa - West Coast Acapulco |
|---|
| 1317 | wj - West Coast Baja |
|---|
| 1318 | wn - West Coast North |
|---|
| 1319 | ws - West Coast South |
|---|
| 1320 | uk - the CoastWatch region is unknown (the image coordinates were not recognized by this tool)</pre></dd></dl></li></ul><ul><li><p>'Satellite' (str) - satellite that took the image. At the time of |
|---|
| 1321 | this writing, the CoastWatch program was known to have published |
|---|
| 1322 | data from the following satellites:</p><dl><dt></dt><dd><pre>noaa-12 |
|---|
| 1323 | noaa-14 |
|---|
| 1324 | noaa-15 |
|---|
| 1325 | noaa-16 |
|---|
| 1326 | noaa-17 |
|---|
| 1327 | noaa-18</pre></dd></dl></li></ul><ul><li><p>'Sensor' (str) - sensor that took the image (e.g. "avhrr").</p></li></ul><ul><li><p>'Image datetime' (datetime.datetime) - date and time the image was |
|---|
| 1328 | taken, in UTC.</p></li></ul><ul><li><p>'Image unix time' (int) - date and time the image was taken, in |
|---|
| 1329 | "UNIX time" format. UNIX times are 32-bit signed integers that are |
|---|
| 1330 | the number of seconds since 1970-01-01 00:00:00 UTC. The UNIX time |
|---|
| 1331 | values produced by this tool do not include leap seconds; this tool |
|---|
| 1332 | assumes that a regular year is 31536000 seconds and a leap year is |
|---|
| 1333 | 31622400 seconds.</p></li></ul><ul><li><p>'Scene time' (str) - the CoastWatch "scene" time for image. At the |
|---|
| 1334 | time of this writing, the CoastWatch program was known to have |
|---|
| 1335 | published data with the following scene times:</p><dl><dt></dt><dd><pre>day |
|---|
| 1336 | day/night |
|---|
| 1337 | night</pre></dd></dl></li></ul><ul><li><p>'Projection type' (str) - projection type for the image (e.g. |
|---|
| 1338 | "mapped").</p></li></ul><ul><li><p>'Map projection' (str) - map projection for the image (e.g. |
|---|
| 1339 | "Mercator").</p></li></ul><ul><li><p>'Map affine a' (float) - the a coefficient for the map affine for the |
|---|
| 1340 | file, in meters.</p></li></ul><ul><li><p>'Map affine b' (float) - the b coefficient for the map affine for the |
|---|
| 1341 | file, in meters.</p></li></ul><ul><li><p>'Map affine c' (float) - the c coefficient for the map affine for the |
|---|
| 1342 | file, in meters.</p></li></ul><ul><li><p>'Map affine d' (float) - the d coefficient for the map affine for the |
|---|
| 1343 | file, in meters.</p></li></ul><ul><li><p>'Map affine e' (float) - the e coefficient for the map affine for the |
|---|
| 1344 | file, in meters.</p></li></ul><ul><li><p>Map affine f' (float) - the f coefficient for the map affine for the |
|---|
| 1345 | file, in meters.</p></li></ul><ul><li><p>'Spheroid' (str) - spheroid used for the image (e.g. "WGS 84").</p></li></ul><ul><li><p>'Origin' (str) - organization that produced the file (e.g. |
|---|
| 1346 | "USDOC/NOAA/NESDIS CoastWatch").</p></li></ul><ul><li><p>Format' (str) - format version of the file (e.g. |
|---|
| 1347 | "CoastWatch HDF version 3.4").</p></li></ul><ul><li><p>'Pixel width' (float) - the width of each pixel, in km. This should not |
|---|
| 1348 | be used as the raster cell size. Please see the CoastWatch |
|---|
| 1349 | documentation for more information.</p></li></ul><ul><li><p>'Pixel height' (float) - the height of each pixel, in km. This should not |
|---|
| 1350 | be used as the raster cell size. Please see the CoastWatch |
|---|
| 1351 | documentation for more information.</p></li></ul><ul><li><p>'Total width' (float) - the width of the image, in km. Please see the |
|---|
| 1352 | CoastWatch documentation for more information.</p></li></ul><ul><li><p>'Total height' (float) - the height of the image, in km. Please see the |
|---|
| 1353 | CoastWatch documentation for more information.</p></li></ul><ul><li><p>'Center y' (float) - the latitude, in decimal degrees, of the center of |
|---|
| 1354 | the image.</p></li></ul><ul><li><p>'Center x' (float) - the longitude, in decimal degrees, of the center of |
|---|
| 1355 | the image.</p></li></ul><ul><li><p>'Upper-left y' (float) - the latitude, in decimal degrees, of the upper |
|---|
| 1356 | left corner of the image.</p></li></ul><ul><li><p>'Upper-left x' (float) - the longitude, in decimal degrees, of the |
|---|
| 1357 | upper left corner of the image.</p></li></ul><ul><li><p>'Upper-right y' (float) - the latitude, in decimal degrees, of the upper |
|---|
| 1358 | right corner of the image.</p></li></ul><ul><li><p>'Upper-right x' (float) - the longitude, in decimal degrees, of the |
|---|
| 1359 | upper right corner of the image.</p></li></ul><ul><li><p>'Lower-left y' (float) - the latitude, in decimal degrees, of the lower |
|---|
| 1360 | left corner of the image.</p></li></ul><ul><li><p>'Lower-left x' (float) - the longitude, in decimal degrees, of the |
|---|
| 1361 | lower left corner of the image.</p></li></ul><ul><li><p>'Lower-right y' (float) - the latitude, in decimal degrees, of the lower |
|---|
| 1362 | right corner of the image.</p></li></ul><ul><li><p>'Lower-right x' (float) - the longitude, in decimal degrees, of the |
|---|
| 1363 | lower right corner of the image.</p></li></ul><ul><li><p>'Type' (str) - the Java data type of the variable (e.g. "short").</p></li></ul><ul><li><p>'Rows' (int) - the number of rows in the image of this variable.</p></li></ul><ul><li><p>'Columns' (int) - the number of columns in the image of this |
|---|
| 1364 | variable.</p></li></ul><ul><li><p>'Units' (str) - the units for this variable, or "-" or blank |
|---|
| 1365 | if this variable is unitless.</p></li></ul><ul><li><p>'Scale' (float) - the scale factor for computing the true value of this |
|---|
| 1366 | variable. Please see the CoastWatch documentation for more |
|---|
| 1367 | information.</p></li></ul><ul><li><p>'Offset' (float) - the offset for computing the true value of this |
|---|
| 1368 | variable. Please see the CoastWatch documentation for more |
|---|
| 1369 | information.</p></li></ul><ul><li><p>'Nav offset y' (float) - the shift, in pixels, that has been applied to the |
|---|
| 1370 | variable's image in the north/south direction to georectify it. |
|---|
| 1371 | North is positive.</p></li></ul><ul><li><p>'Nav offset x' (float) - the shift, in pixels, that has been applied to the |
|---|
| 1372 | variable's image in the east/west direction to georectify it. East |
|---|
| 1373 | is positive.</p></li></ul><p>For more information on Python syntax, please see the <a href="http://www.python.org/doc/">Python |
|---|
| 1374 | documentation</a>.</p></td></tr><tr><td class="info">Output mask raster Python expression (Optional) </td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 1375 | output raster that shows the pixels of the input image that were |
|---|
| 1376 | masked prior to executing the Cayula-Cornillon algorithm. If an |
|---|
| 1377 | expression is not provided, this raster will not be created.</p><p>The raster will contain 8-bit integers and have the same dimensions as |
|---|
| 1378 | the input image. The value 1 indicates that the corresponding pixel of |
|---|
| 1379 | the input image was masked; 0 indicates the pixel was not masked.</p><p>Please see the documentation for the Output Fronts Raster Python |
|---|
| 1380 | Expression parameter for more information about writing the Python |
|---|
| 1381 | expression.</p></td></tr><tr><td class="info">Output median filtered image Python expression (Optional) </td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 1382 | output raster that shows the median-filtered input image. If an |
|---|
| 1383 | expression is not provided, this raster will not be created.</p><p>The raster will have the same data type and dimensions as the input |
|---|
| 1384 | image (usually 16-bit signed integers). Only the non-masked cells are |
|---|
| 1385 | filtered and may change from the values in the input image. Masked |
|---|
| 1386 | cells are not filtered and remain unchanged. If median filtering was |
|---|
| 1387 | not performed, the entire filtered image will be identical to the |
|---|
| 1388 | input image.</p><p>Even though masked cells appear in the filtered image, they are not |
|---|
| 1389 | considered in the selection of median values for nearby non-masked |
|---|
| 1390 | cells. Only non-masked cells are considered in the selection of median |
|---|
| 1391 | values.</p><p>Please see the documentation for the Output Fronts Raster Python |
|---|
| 1392 | Expression parameter for more information about writing the Python |
|---|
| 1393 | expression.</p></td></tr><tr><td class="info">Output candidate counts raster Python expression (Optional) </td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 1394 | output raster that indicates how many times the corresponding pixels |
|---|
| 1395 | of the input image were candidates for containing fronts, i.e. the |
|---|
| 1396 | number of times the pixels appeared in histogram windows that had a |
|---|
| 1397 | sufficiently large number of non-masked pixels to proceed with the |
|---|
| 1398 | histogramming step of the Cayula-Cornillon algorithm. If an expression |
|---|
| 1399 | is not provided, this raster will not be created.</p><p>The raster will contain 16-bit signed integers and have the same |
|---|
| 1400 | dimensions as the input image. Because the histogram window stride is |
|---|
| 1401 | typically less than the window size, successive histogram windows |
|---|
| 1402 | typically overlap, causing many non-masked pixels to have candidate |
|---|
| 1403 | counts greater than 1. Masked pixels can never be candidates for |
|---|
| 1404 | containing a front and will be marked as NoData.</p><p>Please see the documentation for the Output Fronts Raster Python |
|---|
| 1405 | Expression parameter for more information about writing the Python |
|---|
| 1406 | expression.</p></td></tr><tr><td class="info">Output front counts raster Python expression (Optional) </td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 1407 | output raster indicates how many times fronts were detected at the |
|---|
| 1408 | corresponding pixels of the input image. If an expression is not |
|---|
| 1409 | provided, this raster will not be created.</p><p>The raster will contain 16-bit signed integers and have the same |
|---|
| 1410 | dimensions as the input image. The value will range from 0 (the input |
|---|
| 1411 | image pixel never contained a front) to the candidate count value for |
|---|
| 1412 | the pixel (it always contained a front in every histogram window that |
|---|
| 1413 | contained it). Masked pixels can never be candidates for containing a |
|---|
| 1414 | front and will be marked as NoData.</p><p>Please see the documentation for the Output Fronts Raster Python |
|---|
| 1415 | Expression parameter for more information about writing the Python |
|---|
| 1416 | expression.</p></td></tr><tr><td class="info">Output window status codes raster Python expression (Optional) </td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 1417 | output raster that indicates the result of the algorithm for the |
|---|
| 1418 | histogram window centered on the pixel. You can use this image to |
|---|
| 1419 | diagnose why the algorithm did not find fronts in a particular region |
|---|
| 1420 | of your image.</p><p>The raster will contain 8-bit signed integers and have the same |
|---|
| 1421 | dimensions as the input image. The pixel values will be one of these |
|---|
| 1422 | code numbers:</p><ul><li><p>Code 0 - The algorithm was not executed for the window because the |
|---|
| 1423 | histogram window stride was greater than 1, causing the algorithm to |
|---|
| 1424 | skip over this window.</p></li></ul><ul><li><p>Code 1 - The proportion of the window's pixels that had data was |
|---|
| 1425 | found to be too small. This typically occurs when the window occurs |
|---|
| 1426 | in a region where many of the pixels are masked due to land, clouds, |
|---|
| 1427 | or insufficient satellite coverage.</p></li></ul><ul><li><p>Code 2 - After the histogram algorithm optimally separated the |
|---|
| 1428 | window's pixels into two populations, the proportion of pixels |
|---|
| 1429 | allocated to the smaller population was found to be too small. This |
|---|
| 1430 | can occur when a front occurs in the window, but the window is not |
|---|
| 1431 | centered on the front, causing it to contain a disproportionate |
|---|
| 1432 | number of pixels from one population. This is usually not a problem. |
|---|
| 1433 | As long as the histogram window stride is sufficiently small, the |
|---|
| 1434 | histogram window will eventually pass over the front and proceed to |
|---|
| 1435 | the next step of the algorithm.</p></li></ul><ul><li><p>Code 3 - After the histogram algorithm optimally separated the |
|---|
| 1436 | window's pixels into two populations, the difference between the |
|---|
| 1437 | mean values of the two populations was found to be too small. This |
|---|
| 1438 | typically happens when the window does not contain a front or when |
|---|
| 1439 | the gradient along the front is small (i.e. it is a weak front).</p></li></ul><ul><li><p>Code 4 - After the histogram algorithm optimally separated the |
|---|
| 1440 | window's pixels into two populations, the criterion function that |
|---|
| 1441 | was calculated was found to be too small (the criterion function is |
|---|
| 1442 | theta(Topt) described on pages 71-72 of the 1992 paper). This means |
|---|
| 1443 | that the two populations are not sufficiently bimodal to indicate |
|---|
| 1444 | that a front exists in the window.</p></li></ul><ul><li><p>Code 5 - The window was found to have two populations that were |
|---|
| 1445 | sufficiently proportional, different in their means, and bimodal, |
|---|
| 1446 | but the cohesion of one or the other population was insufficient (as |
|---|
| 1447 | described by equations 19 and 20 in the 1992 paper). This indicates |
|---|
| 1448 | that the cells of the two populations are spatially intermixed like |
|---|
| 1449 | a checkerboard, rather than being spatially separate, as occurs when |
|---|
| 1450 | a front is present.</p></li></ul><ul><li><p>Code 6 - The window was found to have two populations that were |
|---|
| 1451 | sufficiently proportional, different in their means, and bimodal, |
|---|
| 1452 | and each population was found to be sufficiently cohesive, but the |
|---|
| 1453 | cohesion of the two populations together was insufficient (as |
|---|
| 1454 | described by equation 21 of the 1992 paper). As with code 5, this |
|---|
| 1455 | indicates that the cells of the two populations are spatially |
|---|
| 1456 | intermixed like a checkerboard, rather than being spatially |
|---|
| 1457 | separate, as occurs when a front is present.</p></li></ul><ul><li><p>Code 7 - The window passed all of the algorithm's tests and was |
|---|
| 1458 | classified as containing a front.</p></li></ul><p>When the width and height of histogram window is an even number, the |
|---|
| 1459 | center pixel is the one to the lower right of the exact center of the |
|---|
| 1460 | window, which falls at the intersection of four pixels. For example, |
|---|
| 1461 | in a 6x6 window, the center pixel is the fourth from the left and |
|---|
| 1462 | fourth from the top. |
|---|
| 1463 | Please see the documentation for the Output Fronts Raster Python |
|---|
| 1464 | Expression parameter for more information about writing the Python |
|---|
| 1465 | expression.</p></td></tr><tr><td class="info">Output window status values raster Python expression (Optional) </td><td class="info" align="left"><p>Python expression used to calculate the absolute path of the |
|---|
| 1466 | output raster that you can use in conjunction with the window status |
|---|
| 1467 | codes when diagnosing the results of the algorithm.</p><p>The raster will contain 32-bit floating point numbers and have the |
|---|
| 1468 | same dimensions as the input image. The value of each pixel depends on |
|---|
| 1469 | the window status code for that pixel:</p><ul><li><p>Codes 0, 1, 7 - The pixel value is always 0.0.</p></li></ul><ul><li><p>Code 2 - The pixel value is the proportion of the window's pixels |
|---|
| 1470 | that were allocated to the smaller population.</p></li></ul><ul><li><p>Code 3 - The pixel value is the difference in the mean values of |
|---|
| 1471 | the window's two populations.</p></li></ul><ul><li><p>Code 4 - The pixel value is the criterion function that was |
|---|
| 1472 | calculated for the window.</p></li></ul><ul><li><p>Code 5 - The pixel value is the cohesion of the window's population |
|---|
| 1473 | that was found to be insufficiently cohesive. If both populations |
|---|
| 1474 | were insufficiently cohesive, it is the cohesion of the "cold" |
|---|
| 1475 | population.</p></li></ul><ul><li><p>Code 6 - The pixel value is the cohesion of the window's two |
|---|
| 1476 | populations together.</p></li></ul><p>By examining the pixel values, you can determine how to adjust the |
|---|
| 1477 | algorithm's parameters to cause more or fewer windows to pass the |
|---|
| 1478 | algorithm's tests, increasing or decreasing the number of fronts |
|---|
| 1479 | identified in the image. You should only adjust the parameters if you |
|---|
| 1480 | feel comfortable deviating from their published values. |
|---|
| 1481 | Please see the documentation for the Output Fronts Raster Python |
|---|
| 1482 | Expression parameter for more information about writing the Python |
|---|
| 1483 | expression.</p></td></tr><tr><td class="info">Python modules to import (Optional) </td><td class="info" align="left"><p>Python modules to import prior to evaluating the expression. If |
|---|
| 1484 | you need to access Python functions or classes that are provided by a |
|---|
| 1485 | module rather than being built-in to the interpreter, list the module |
|---|
| 1486 | here. For example, to be able to use the datetime class in your |
|---|
| 1487 | expression, list the datetime module here. In your expression, you |
|---|
| 1488 | must refer to the class using its fully-qualified name, |
|---|
| 1489 | datetime.datetime.</p></td></tr><tr><td class="info">Skip existing outputs (Optional) </td><td class="info" align="left"><p>If True, conversion will be skipped for output rasters that already exist.</p></td></tr></tbody></table></div></body></html> |
|---|
