Prevent multi-part features

[Bud]

Scenario:
Multipart features get created by accident. The person who created the features merged two lines together, but didn't realize that a multipart feature was created.

Or, in some cases, multi-part features get created on purpose. We don't want that either.

There ought to be an optional setting in a feature class's properties for preventing multi-parts from being created. Currently, I don't think that functionality exists.

I imagine it would be possible to disallow multiparts using an attribute rule. But at this point, we've got so many attribute rules in the works that we're terrified that we're creating a monster. We'd much rather there be OOTB functionality for this stuff. (Similarly, we want to prevent true curves via a FC property too.)

Thanks.

[DanLee]

Did you use Dissolve tool to merge lines? If so, there is a "Create multipart features" option on the tool which you can uncheck.  I am not aware of any other tools that create multipart features, unless you did it manually.

You can use Multipart To Singlepart tool to turn the multipart features into singlepart.

https://pro.arcgis.com/en/pro-app/2.9/tool-reference/data-management/multipart-to-singlepart.htm

[Bud]

@DanLee 

The multiparts were created manually in an existing FC. 

Here's an explanation from a related post:

Multipart features were created manually...by accident. The person who digitized the roads merged two lines together, but didn't realize that a multipart feature was created. 

We want to prevent our users from manually creating multipart features.

[JayCary]

The Evaluate Part Count check (configured as a constraint attribute rule) will prevent the creation of multi-part features during editing.

[DanLee]

Thanks  Bud for the request.  I have notified our Editing team about this.

As a post-editing option, you can use Calculate Geometry Attributes to calculate "Part Count" to a field. Any feature getting a value greater than 1 would be a multipart feature.

[Bud]

@DanLee Thanks Dan. I suspect many organizations face this same problem where multi-part features get accidently created (via manual editing/merging).

And it's occurred to me that some organizations might not realize the problem exists. I imagine there are scenarios where you wouldn't notice the multiparts, unless you had a reason to look for them. Until one day, an issue pops up.

So it's great to hear that the Editing team will be taking a look. Cheers.

[DanLee]

You are welcome  Bud. Unintended multiparts can cause problems in analysis. Calculate Geometry Attributes (part count option) may be the easiest to detect them; and Multipart To Singlepart tool returns singleparts.  I hope people will vote this request up.  🙂

[Bud]

Multiparts also cause lots of problems in SQL analysis too (ST_GEOMETRY, SDO_GEOMETRY, or whatever the spatial type is).

[LouisViallet]

In ArcGIS Pro or in Portal, it’s happen often that users draw a polygon and do a miss click when they do a double click to terminate the polygon. In this case, we have polygon like a butterfly and it’s create multipart. After that, we need to delete the wrong part by script but we don’t know in all case if it’s a mistake or not.

We need to remove multiparts because we do export of our data to external partner which can’t read multipart.

The idea is to limit multipart directly at the creation rather than do a fix script.

To do that, we can imagine a checkbox to unauthorized multi part in feature class properties.

[LouisViallet]

The methods explains by @JayCary works for me.

I have created a constraint rule with :

var rings = Geometry($feature).rings;
return(Count(rings)==1);

There is just a strange behavior on web editing. The polygon is not created, it dissapear without comprehension because there is no message.

[Bud]

Multi-part lines will be the end of me. They cause problems every time I try to do something. 

Yes, eventually we'll undertake several large projects to get rid of multipart features in all of our FCs. And deal with the fallout in all of our dependent/related FCs and tables. But that will take a lot of time. 
And then afterwards, once our organization has fully switched to a modern version of Pro, we'll prevent multiparts going forward using attribute rules. But as mentioned, we'd prefer it if preventing multiparts were an OOTB FC property, not a customization.

In the meantime, multiparts make analysis unnecessarily difficult.