When migrating joint use data into the UN schema, which option is recommended? * Use a relationship class between Structure Junction feature class and the Joint Use table? * Migrate the joint use data into StructureJunctionObject table and configure rules? Example: From Asset Group Pole To Table StructureJunctionObject To Asset Group (new) Joint Use To Asset Type (new) Joint Use Type (with new Domain values for types of attachments [Fiber, Coax, 5G, etc])

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; } } }

Joint Use - model as related table or use Structural Attachment Rule with StructureJunctionObject?

GISP00

When migrating joint use data into the UN schema, which option is recommended?

Use a relationship class between Structure Junction feature class and the Joint Use table?
Migrate the joint use data into StructureJunctionObject table and configure rules?

Example: From Asset Group Pole To Table StructureJunctionObject To Asset Group (new) Joint Use To Asset Type (new) Joint Use Type (with new Domain values for types of attachments [Fiber, Coax, 5G, etc])

Trouver plus de publications taguées avec

Accepted answers

JohnAlsup

You have three options, each with pros and cons.

The StructureJunctionObject will increase the size of the associations table which will impact the time of enable topology and disable topology. There are other potential impacts to things like validate, export subnetwork to name a few.

The geodatabase related table method avoids those issues, but introduces new issues. The relationship can lead to false or confusing conflicts and the user interface for geodatabase relationships leaves a bit to be desired.

The third option is to make the jointuse table a related table only in the map, not using a geodatabase releationship class. This avoids the conflict issue and actually provides a better UI experience for the user. The draw back is you must manually create the record in the joint use table and copy and paste the GLOBALID from the pole to the joinuse record. This could be done with an addin.

All comments

JohnAlsup

An attribute rule would be tough to get to work as an attribute rule runs on the service, not the client, so it would have no knowledge of what rows you have selected.

GISP00

Thank you for the detailed answer. Regarding option 3, would an Attribute Rule close the gap instead of an AddIn? Would that Rule be supported across the ArcGIS platform?

AJ_GeoPro

Perfect - thanks! That clarifies the type of conflicts that can popup.

JohnAlsup

Let's take an example. I have a pole, that pole has no related joint use records. I create my version and create a joint use record for this pole, and I also update the pole-class. Before I can post my version, some updates the pole, say height. Now, when I reconcile, I get a conflict on the pole and the new related record. When it's just one update like this, it's pretty easy to fix. However, when many things are updated and in the conflict list, it gets very complicated very quickly.

AJ_GeoPro

Thank you for describing the 3 options. Could you briefly provide further details about the 'confusing conflicts'?

JohnAlsup

You have three options, each with pros and cons.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

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