Make the dissolve tool smarter when specifying not to create multi-part features.

[DerekSwingley]

Currently, when using the dissolve tool, and the create multi-part features option is unchecked, features in the resulting feature class that had the same dissolve field attribute all get the same value for each statistic field. Ideally, the tool should respect spatial relationships and, when you specify to not to create multi-part features, the attributes of the output features should accurately reflect what was actually dissolved and not the aggregate of all features with a common attribute. This is probably better explained as an example.

Let's say I have a feature class has three features. All have the same value in the dissolve field but only two of the features are adjacent. Each feature has another attribute called foo and this field is used as a statistic field. The statistic type for foo is SUM. The values for foo are 1, 2 and 3. The two adjacent features have values of 2 and 3 for foo. When I run dissolve with create multi-part features unchecked, the two resulting features both have values of 6 for foo but the values should be 5 (for the two adjacent features that were dissolved) and 1 for the feature that is not adjacent to the other features. 

Two NIMs related to this request are:  NIM013409 and NIM035670.

[DanielCRS]

At the very least, please update the documentation to clarify that this is how the tool operates.

[mthompson]

Bumping this. Would love there to be an option for the aggregation of fields to only be for the dissolved polygons and not the whole table depending on if the "create multipart" box is checked.

[Yannick-Atos]

Currently, when running Dissolve or Pairwise Dissolve with the single part option, statistics field's attribute values from all features that share the same dissolve field values are calculated or concatenated—even if those features remain separate geometries because of the single part constraint.

Before dissolve:

Before dissolveYou would expect that for single part features, only OID 2 and 4 (LINK_ID 1305630123 and 1305630124) are dissolved, and therefore only these two should have their LINK_IDs concatenated.

After the dissolve, however, the statistics fields are calculated independently of the spatial entity:

After dissolve

The dissolve leads to unexpected and sometimes incorrect attribute tables:

• Features that remain spatially distinct (single part enforced) end up with concatenated attributes from other features that were not dissolved with them.

• As a result, attribute values can be misleading and do not reflect the actual geometry or logical unit of the feature.

Expected/Proposed behavior:

• Attribute concatenation should only apply to features that are actually dissolved into a new geometry.

• Features that remain single-part should keep their original attribute values, rather than concatenating values from unrelated geometries.

Why this matters:

• Maintaining data integrity: users expect attributes of non-dissolved features to remain unchanged.

• Preventing unnecessary post-processing: currently, extra steps are required to clean up attributes that were concatenated although geometries were not merged.

• Improving consistency with user expectations: many users assume “single part” means attributes are preserved unless geometries are explicitly dissolved.

This change would make the Pairwise Dissolve tool more intuitive, reduce errors, and align the attribute output with the spatial result.

[LindsayRaabe_FPCWA]

How have I only just discovered this problem after over a decade of using this software! Obviously I've always used statistic fields with multipart dissolves (or just never noticed the errors!). Clearly, this has had no traction seeming as how it's a 15 year old post! I have submitted direct feedback from the ArcGIS Documentation page requesting more detail in the documentation and the tool tips in ArcGIS Pro around how Statistics don't honour the "Create multipart features" checkbox. 

Time to submit a new feature request I think!

[KenHartling]

We are actively working on a solution for this using the PairwiseDissolve tool.  Our goal is to have it available in ArcGIS Pro 3.7. 

Ken