Dirty Area Status meaning

[VishApte]

Hi,

I am having an issue with Electric Distribution Utility Network. I am fixing some data errors but some dirty areas dont go away. I had error with two ElectricLines of different subtypes joining without a junction. I added a junction that has connectivity to both asset types and ran the validate subnetwork. The command was successful with message "Validate successful" message in notifications. However, dirty area doesn't go away. I tried to move the vertex away from the junctions on both ends of the line, and revalidated. The command was successful with message "Validate successful" message but Dirty area is still there. And dirty area's geometry is still covering old line geometry and not the new shortened geometry on both ends.  

Does anyone know what Status 9 means for Dirty Area? It seems to be a bit-wise integer and Arcade expression in the symbology says 

var Status = $feature.status; if (Status == 0) return 0; if ((Status & 0x7) > 0) if ((Status & 0x38) == 0) return 1; else return 3; if ((Status & 0x20) > 0) return 4; return 2;
 

Any idea how I can fix this? I cannot run Update Subnetwork with dirty areas.

[MelissaJarman · Accepted solution]

The Dirty Areas are symbolized using the status field - 

The Status attribute field uses bitwise encoding to represent the operation that created the dirty area. For example, a deleted feature is represented by bit 1 and is displayed with a status of 2 (2^1 = 2). These values are summated if multiple operations led to the creation of the dirty area. A Status Description field is displayed in the pop-up expression to provide additional information about the operation that created the dirty area.

You can review the following pages to see if they provide you with help on how to use Errors. 

Errors 

Error management

[VishApte]

Thanks @MelissaJarman 

I can now see what Status Descriptions mean.

However, I am still not sure why my Dirty Areas with status 9 (1 + 😎 doesn't go away after I shortened the geometry and Validate UN Topology was successful. I had to Disable Topology and Re-enable to see those dirty areas go away.  This is with ArcGIS Pro 2.6.3, UN v4, ArcGIS Enterprise 10.8.1 plus UN SP1. 

[MelissaJarman]

Are you able to consistently reproduce the validate not taking away the dirty areas when the error situations are resolved? If so, I would be interested in the repro steps as you should not be forced to disable and reenable the networks topology to clear these.

[Anonymous User]

We've seen the same issues  as well with multiple clients.  Validate returns successfully but the dirty areas still remain.  This can obviously cause problems when updating subnetwork etc. as the validate returns successfully, but the dirty areas are still hanging out there.  The only work around we've found is to disable/enable topology.  We've also seen the UN get hung up validating with the message: Edit Operation Failed or if running the gp tool, the dreaded 99999 error.  This has happened with Pro 2.6x and 10.7.1 as well as 2.7 and 10.8.1.  We also tried using the Repair Network Topology tool at Pro 2.7 but it didn't seem to alleviate the error.  I can work on getting the repo steps, but they often arise after what would be a pretty standard edit.

[SFortnam]

My customers are seeing this issue as well.  A simple edit will validate successfully, with no status errors, yet the dirty areas remain.  Then when the Trace tool is run, the updates are not made to the network.  No other errors are present.

[AllysonReynolds]

Have you been able to resolve this?

[EC1]

I am also consistently having this issue.  I haven't found any easy fixes. 

my issue is the UNM ERROR areas occur, fixes are made via FME, then validate runs fine, a popup tell me "there are no dirty areas", but the ERROR dirty areas remain.
The only way to fix in my case is to edit the line the ERROR dirty area is flagging, moving and replacing it where it was, then re-validating it. Very time consuming and annoying.

[PhilLarkin1]

I've also experienced this issue; Dirty Areas not being removed after a successful validation. This was seen in Pro 3.0.1 with a standard topology. Data is stored in MSSQL, traditional versioning, 10.8.1.