Current logic uses the geographic centroid of the input shape specified to lookup the pixel value in the CONUS raster map for the centroid location. No checks are made to verify that the resulting pixel value is not the "No Data" value because the current implementation uses a command shell to gdallocationinfo, which does not have that capability.

1) Remove the use of a command shell to gdallocationinfo and use embedded Java and GeoTools Raster libraries to read the raster file instead and to look-up the pixel value.

2) If a cfactor pixel value is the default "No Data" value found in the raster file then:

a) Search the entire interior of the shape, specified in the input payload, and find the mean value of all valid pixel values contained therein. If no valid pixel values are found, then proceed to 2b.

b) Search the entire exterior of the shape, specified in the input payload, and find the very first valid pixel value contained within a search pattern described by a spiral pattern around the exterior of the shape, not to exceed 3 pixels past the exterior boundaries. If no valid pixel values are found, then proceed to 2c.

c) Set the returned pixel value to a default of 0.0 and subsequently use that value in all subsequent calculations that use the cfactor value.

3) Report a key/value pair back to the calling entity, which describes what methodology was used to find the resulting cfactor value, "Mean", "Centroid", "Spiral Search", or "Default Zero", so that the consumer of the result data can make an informed choice about the resulting calculations and the cfactor value presented.

The above logic precludes the finding of cfactor pixel values for outside of CONUS locations. These are currently handled by a database lookup for Alaska only. Consequently:

4) Add a default 0.0 value as the cfactor value if the Alaska lookup does not find the location in the database.