Eliminate tool doesn't split non-contiguous HRU's

[lbross]

From Geoffrey:
Eliminate tool doesn't split non-contiguous HRU when the tool is applied on a non-contiguous HRU layer with the "allow non-contiguous HRU" option unchecked. The tool needs to convert mulitpart HRU polygons into singlepart polygons before performing eliminate.

[lbross]

The eliminate form estimates the number of polygons to be removed when the user enters the pct or area. This is a quick calculation against grid_v performed on the onChange event. If we split the multipart polygons before eliminating, these estimates may not be correct. Options are to create a "split" layer the first time a pct or area is input. This could take some extra time that the user is not expecting.

Or we just assume that the estimate is "close enough" and wait to split the multipart polygons until the eliminate is actually performed. Thoughts?

Shape_Length and Shape_area will need to be recalculated following the eliminate since they may have changed.

[jdduh]

The number is just for users reference, not the final count. We probably should make that clear on the UI. NWCC folks use the eliminate tool to remove small sliver polygons (HRUs) and don't use the tool to reduce the HRU number to a targeted amount. So, the estimated final HRU number doesn't need to be precise.

Shape_Length and Shape_Area are maintained (i.e., recalculated) automatically when the feature class is saved to a Geodatabase. Is it not the case in BAGIS-H?

[lbross]

Should I add a line underneath the No. of zones removed textbox? "The no. of zones removed is only an estimate. The final no. may be different."

BAGIS-H maintains the polygon areas in sq km and acres. These are the fields that will need to be recalculated.

[jdduh]

Yes, please add the warning message. So, yes, please recalculate the length and area. BAGIS-P's HRU area model reads directly from the area field. We need to make sure the data are correct.

[lbross]

The AREA_SqKm and AREA_Acre fields are recalculated using the BA_AddShapeAreaToAttrib method which is called by the BA_CreateHru method. The latter method is already being called as one of the last steps of the eliminate tool so we don't need to call it again.

[lbross]

Fixed in v 1.6.0. New version of add-in posted on releases page. This code is still on issue_15 branch until fix is verified

[jdduh]

Background:
The resampling of HRU layers in BAGIS-P's export function could alter the number of HRUs and create a mismatch of HRUs in eWSF. Users need a way to minimize the risk of the bug created by resampling.

Solutions:

1. Keep users well-informed of the minimum polygon size of an HRU layer so that they can pick a resample size that's appropriate.
2. Retool the eliminate tool in BAGIS-H to limit the minimum polygon size of any give HRU layer.

Software modifications:
BAGIS-P

1. Report the minimum polygon size (note: not HRU size) in BAGIS-P export dialog window.
2. Check the number of HRUs in the HRU layer and the resampled HRU layer. If the values don't match, then prevent the HRU/parameters being exported.

BAGIS-H

1. Report the minimum polygon size (note: not HRU size) in BAGIS-H eliminate dialog window.
2. Provide two eliminate options. One is based on HRU size and the other is based on individual polygon size (if the HRU is non-contiguous).

[lbross]

What is the minimum polygon size? The size of the smallest polygon in grid_v?

[jdduh]

That's correct. All polygons should be treated as single-part polygons. Multi-part polygons need to be converted to single-part polygons.

[jdduh]

Does the current eliminate tool eliminate HRUs based on multi-part or single-part polygon (HRU) size? Obviously, this discussion applies only to non-contiguous HRU layers. Contiguous HRU layers have only single-part polygons.

[lbross]

The current eliminate tool uses the SelectLayerByAttribute tool to select polygons of less than the minimum area for removal. It's my assumption that this tool would use the entire area of the multi-part polygon for this calculation but we would need to check with ESRI to be sure.

[lbross]

How to provide two eliminate options: Add another radio button under Eliminate Threshold called "Minimum polygon size". Should this show only if the parent HRU is non-contiguous? If the Allow non-contiguous checkbox is checked on the eliminate form?

[jdduh]

I believe that if the features are multi-part features, then the selectlayerbyattribute tool will select all the parts. That means the current eliminate tool uses the HRU areas (i.e., multipart polygons) to perform the eliminate function.

I checked the vector layers of a non-contiguous HRU. The grid_v and grid_zones_v are multipart. The polygrid_v is single-part.

Yes, please add a new radio button (or a checkbox that says "eliminate based on areas of individual polygon parts") and only show this control when the "Allow non-contiguous HRU" option is checked.

[lbross]

See screenshot for addition of new radio button on eliminate form. Okay?

How should we handle the 'Get Area from Map' button? Current functionality when using 'Area of Zone' option is to load grid_v (which may be multipart) into ArcMap. We could use the GP tool to convert the multi-part polygons if this button is used but it is not speedy. We could also not enable this button if the new option is chosen.

[jdduh]

The GUI looks good. It's fine to keep the Get Area From Map button available to the Area of Individual Polygon Parts. Please add a Min Polygon Size to the dialog window, above or below the Min Zone Size text field.

Is there a way to show whether the HRU was created as contiguous or non-contiguous on the eliminate dialog window? It seems that users can use this tool to force a non-contiguous HRU layer into a contiguous HRU (by unchecking the Allow non-contiguous HRU).

The forecasters are not sure about which type of eliminate they should use. Once they have a consensus, we might need to hide one of the options to prevent confusion.

[jdduh]

Hide the "Get Area from Map" button when the "Area of Individual Polygon Parts" option is selected. If the parent is non-contiguous, then show all options. Otherwise, show only the original two options.

[lbross]

Updated screenshot of eliminate tool with new fields. Just to confirm, the "Area of Individual Polygon Parts" option is an option only if the parent allows non-contiguous HRU's. Does it matter if the desired output allows non-contiguous HRU's?

[jdduh]

The GUI looks good. Yes, the Area of Individual Polygon Parts option is available only when the parent is non-contiguous. If the parent is contiguous, then the "allow non-contiguous HRU" option won't have any effect. How about if the parent is contiguous, then disable (and uncheck) the "allow non-contiguous HRU" option?

[lbross]

Can you review these scenarios and let me know if I have them right? Assumption: percentile option is always available.

1. Contiguous to contiguous: Area of zone. No pre-processing required. Eliminate on grid_v.
2. Contiguous to non-contig: Not permitted although it isn't difficult to implement. Just need to dissolve on hru_id to create the final layer.
3. Non-contig to contiguous: Area of zone: No pre-processing required. Eliminate on grid_v; Area of individual polygon parts: Convert multi-part polygons to single-part before eliminating. Eliminate on converted data layer. No need to dissolve on hru_id for final layer
4. Non-contig to non-contiguous: Same as option 3 except we dissolve on hru_id to create the final layer

[jdduh]

Scenario #2 is not possible to perform because all HRUs have unique IDs, even for the hru_id field.
Correction for Scenario #4 title: non-contig to non-contig.
The descriptions are correct.

Verification: the percentile option is based on the number of HRUs, not on the number of polygons. The # of HRUs is the same as the # of polygons for contig HRU layers.

[lbross]

Fixed in BAGIS-H v1.6.1