nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Inconsistency between Subnetline et Subnetwork status

PierreloupDucroix

Hello,

We have found that there is sometimes a difference between the isdirty value of a subnet line and the isdirty value of the subnet.

Ex: Here you can see that the same subnet has a status of False in the FC subnetline row (left) and True in the subnetwork table (right). And the Update Subnetwork toolbox allows us to update the subnet, unlike the "Find Subnetworks" panel (because I assume the tbx applies to the subnet table and the panel applies to the FC subnet row)

Also the Export Subnetwork does not propose this subnet (obviously because it is dirty) :

Looking at REST endpoints, I can see the same inconsistency:

SubnetLine :

Subnetwork :

The problem is that we are checking the FC subnet line to find the updated subnets, validate them if necessary and export them into an ADMS. We will now have to rebase the tool on the subnetwork table (500002) instead of the FC.

UN V6 / AGS 11.3 / Pro 3.3.6

Before I log a case to the support, does anyone else have a similar behavior ?

Encuentra más publicaciones etiquetadas con

Accepted answers

RobertKrisher

@PierreloupDucroix you are correct in that the behavior is slightly different when posting edits from a version. If the subnetwork or subnetwork line is modified in the version we will mark it as dirty when it gets posted because we know that there are changes that happened to it in the version that mean it needs to be processed in default.

As an example, if you create new features in your version and run update subnetwork, they will have their subnetwork name populated and the subnetwork line will be updated to reflect the new features in your version. After you reconcile and post your version to default, there is no guarantee that those same features will be connected, so we make you rerun update subnetwork to ensure everything is clean and connected.

All comments

RobertKrisher

Yes, but only the subnetworks that have been edited and validated. And even then, this is only if the subnetworks are configured to use the status field. Most water and gas customers choose to not use the status field, while electric customers do.

GISUser1619_Nguyen

Hi Robert

May I ask a question?

As I know in this link

https://doc.esri.com/en/arcgis-pro/latest/help/data/utility-network/subnetline-feature-class.html

"When a named version is reconciled with the default version, the SubnetLine class is considered; however, when a version is posted to the default, the SubnetLine class is not included. This is because the SubnetLine class is only valid in the version in which the subnetwork was updated. After a version has been reconciled, dirty areas may need to be validated and any modified subnetworks may need to be updated again. When a version is posted to the default, dirty areas are created. After validating any dirty areas, the update subnetwork operation in the default version updates the SubnetLine class."

Is that mean need to be run again in Default version? And this process only run with subnetwork or subnetwork line mark as dirty in Default version when we checked on "All Subnetwork in tier", I really consider if customer have a lot subnetwork need to be update in Default version.

Thank you!

PierreloupDucroix

Hello, we are currently modifying our export tool so that it checks the subnet status in the subnet table rather than in the subnetline feature class. We believe this will also allow us to detect new subnets created in named versions but not present in the default version. Currently, users must manually update them at least once in the default version before we can detect a subnet row.

RobertKrisher

PierreloupDucroix

Of course, we manage the "isDirty" state for each tier.

The problem isn't that updating the subnetwork doesn't update the subnetLine FC ; it does if I manually update the subnetwork in Default.

The problem is more related, I think, to how a subnet update in a version applies to the subnetLine feature once posted to Default. I think that in some cases, posting a subnet updated from a version to Default will set the state to 1 in the subnet, but leave it at 0 in the subnetLine…

GIS_kiwi4

Hi @PierreloupDucroix,

That was my understanding too.
I looked our data and I couldn't find any records that showed the same inconsistency as the one you have highlighted. The update subnetwork operation should set the Subnet line FC status = 0

https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/subnetworks.htm#:~:text=When%20this%20option%20is%20enabled%2C%20the%20IsDirty%20attribute%20is%20managed%20by%20the%20update%20subnetwork%20operation%20and%20updated%20in%20the%20Subnetworks%20table%20and%20SubnetLine%20feature%20class.

Just wondering if you have Manage IsDirty parameter set correctly. This may not be the issue because you mention that this only happens for some instances.

PierreloupDucroix

Isn't the status supposed to be consistent between the subnetwork line and the subnetwork ?

RobertKrisher

The subnetworks table is the more reliable way of determining status, especially in networks with multiple subnetwork controllers.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.