Binary inclusions results

[mjgleason]

Bug Description
setbacks module will sometimes produce binary results (i.e., exclusions) for counties with ordinances when inclusions should be returned (i.e., weights_calculation_upscale_factor is greater than 1).

Screen shot 1 shows an example of this occurring for roads setbacks in North Carolina. County boundaries are shown in black and the setbacks raster is displayed with a red/yellow/blue color ramp where red=0 (full exclusion) and blue=1 (full inclusion). Several counties show up with colors only of red and blue, indicating binary results. This was confirmed by inspecting the actual pixel values.

This same error occurs when there are no default setbacks used for counties without ordinances (see Screen shot 2). Interestingly, in this latter case, the resulting raster is actually of dtype Byte (i.e., UInt8) when it should be float32.

Full Traceback
There is no traceback since this is a semantic error.

Code Sample
NA

To Reproduce
To reproduce this problem, you can run setbacks from-config -c this_config.json where this_config.json is

{
  "execution_control": {
    "allocation": "setosa",
    "option": "eagle",
    "walltime": 1,
    "max_workers": 1,
    "memory": 180.0
  },
  "log_directory": "./logs",
  "log_level": "DEBUG",
  "excl_fpath": "/projects/rev/data/exclusions/ATB_Exclusions.h5",
  "regs_fpath": "/shared-projects/rev/projects/seto/data/solar_regulations_fix_2022-12-21.csv",
  "weights_calculation_upscale_factor": 5,
  "feature_type": "road",
  "features_path": "/projects/rev/data/conus/here_streets/Streets_USA_WY.gdb",
  "base_setback_dist": 0
}

Expected behavior
The expected result should be a raster is returned with inclusion values ranging from 0 to 1 instead of exclusion values of only 0 and 1 for these counties.

Screenshots
Screen shot 1:

Screen shot 2:

Screen shot 3:

Screen shot 4:

System (please complete the following information):

• OS: Linux
• Compute hardware: Eagle
• Version: 0.3.48

Additional context
Interestingly, this problem does not occur for all counties with ordinances, but occurs on a state-by-state basis. If a state is affected, all the counties with ordinances will be affected. If not, no counties are affected.

I believe I've traced this problem back to a couple mechanisms. The first is https://github.com/NREL/reVX/blob/main/reVX/setbacks/base.py#L417, which filters the vector features for each county down to those that have a centroid within the county boundary. In some cases, features will be returned as an empty list, resulting in a constant array with all values of 1 returned by this function. Notably, this raster is of an uint data type.

This raster is then combined with the existing exclusions array (https://github.com/NREL/reVX/blob/main/reVX/utilities/exclusions.py#L365). In many cases, this is fine, because the existing raster is already populated (by a previous county) and has an existing data type of float32. But if this issue occurs with the first county being processed, the existing array is None and the dtype is established based on the dtype of the local exclusions array:

reVX/reVX/utilities/exclusions.py

Lines 484 to 485 in d247465

	if existing is None:
	existing = self.no_exclusions_array.astype(additional.dtype)

. If that dtype is uint (see previous paragraph), then we end up with an existing raster that is now initialized to a data type of uint. This will then convert the inclusions results for all subsequent counties in the state to uint, resulting in a uint layer for all counties with ordinances.

I've worked out one solution to this and will post it to a new branch. I have tested enough to confirm it fixes the issue (see Screen shots 3 and 4 for before and after results in Wyoming), but have not tested it thoroughly enough to know that it is robust and doesn't have any unintended side effects. Also, it may not be the cleanest solution, but hopefully will provide additional insight into the problem.

Charge code
If you are at NREL and fixing this bug is urgent, please provide a charge code for our time.

[mjgleason]

Branch with a possible solution is https://github.com/NREL/reVX/tree/issue_170

[ppinchuk]

Addressed in #173