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

Topology rules and Parcel connection line subtypes

DrewDowling

I am having an issue with Topology rules when there are sub types on my fabric connection lines and points. In my model I have 2 connection line subtypes, tie line and road centerlines. But only one sub type is being added to the topology attribute rules when I enable fabric topology. No rule is create for the other sub type and I cannot add others

Further more I have 3 fabric point subtypes. I would like to also create custom rules for these type but they do not appear in the the standard topology rules.

When I try to manually create or modify rules they are disabled. The attached screen grab shows the default rules that are created. Only the parcel line road subtype is added. The Remove rule button is grayed out and the Add rule button doesn't do anything. No new windows appears for adding rules.

So my questions are

1. Are subtypes supported in Parcel Fabric lines and points

2. Is the parcel fabric topology modifiable?

I am using ArcGIS Pro 3.0 version of the fabric and I have tried this in both FGDB and EGDB copies of my data.

subtypes.png

Najděte více příspěvků označených jako

Parcel Editing

Accepted answers

TimHodson

Hi @DrewDowling - I've been working through your goal to add subtypes to connection lines and to fabric points. Thank you for your post. First, to answer your specific questions.

Are subtypes supported in Parcel Fabric lines and points? Yes.

Is the parcel fabric topology modifiable? Yes, but with some known limits, as described more fully below.

Here are some key points:

What you are attempting is possible with the parcel fabric. However, there may be a problem that you’re experiencing that I’ve not identified. Please respond here if this post does not solve any elements of your scenario, and we’ll continue work on figuring it out.
Two software user interface defects were found, and they have workarounds. These are both described under a logged support item (Reference: BUG-000152163). These defects and workarounds are described below.
There are some behaviors and user experiences that you may have encountered that are by design; some of these behaviors and user experiences are different from similar functionality in ArcMap.

Software user interface defect 1:

When a subtype code has a value of 0, it is not presented properly in the user interface when viewed in the topology properties. The topology rule is incorrectly shown to indicate that it applies to a subtype although it actually applies to the entire class.

Workaround:

Instead of using a 0 code, use subtype codes starting at 1.

Software user interface defect 2:

When a class level rule exists, and there is a subtype field on the class, if there is any row that contains a null in the subtype field, it should cause the topology validation to present an error message (this is by design.) The user interface defect is that when running validate, the validation does not show the expected error message dialog. The Validate does not run, and the dirty areas are not removed, but there is no information presented about why nothing happened.

Workaround:

Use the GP tool Validate instead to get this error message. For the specific error message that’s returned, you can solve it by making sure that your feature class with a subtype has valid and non-null subtype codes in their subtype field for all features.

Related to the specifics of the fabric generated topology:

- The Remove button is disabled for fabric generated topology rules. This is by design. We are considering allowing the removal of these rules in future releases.

- You are not able to alter the fabric generated topology rules.

In terms of adding new topology rules, when you click the Add button you do not get a new dialog; instead a new row is added to the grid on that page, and you can double click on the first cell for “Feature Class 1” in the first column to select the first feature class, and then do the same for the other columns. You can also click in the last row in the grid that says “Click here to add a new rule.”

-Tim

All comments

AmirBar-Maor

@Kathleen_Crombez

We discourage using subtypes unless they are absolutely needed (see above)

A historic parcel is a parcel where 'RetiredByRecord IS NOT NULL'. This is not a 'long' field type and therefore cannot be used to control subtypes.

Using an attribute rule to change another long field is also not allowed.

Furthermore, geodatabase topology only works on 'feature classes' and not on layers, so you cannot run a rule on a table that contains both historic and current parcels. However, validating a subset of the data might be achieved using attribute rules validation (arcade has spatial analysis methods, filtering and more).

KathleenCrombez1

The parcel fabric features should be subtyped for active and historic. This should be implemented as part of the Parcel Fabric Data Model, as these are very distinctly different types of data.

We are finding dangles on the active lines that do not show up in the topology because there is a historical line connected to it.

I suspect as we start digging deeper there are going to be other topology issue we are missing due to the historical parcels being part of the validation.

One example were this could be a big issue is if you are trying to check all active lots are covered by an active subdivision and the active lot is only covered by a retired subdivision. This will not get caught in the topology as it is.

All of the fabric generated rules should be made for both types of data (active types and historic types)

AmirBar-Maor

@DrewDowling Thanks for the explanation.

Please log a bug if the attribute rules fail to fire when using a subtype. I am sure you are aware of the workaround to use attribute rules without subtypes: use a single attribute rule with the appropriate condition logic for each of your 'types/categories.

We will consider relaxing the system topology rules, just like Attribute rules

DrewDowling

Thanks for the suggestions @AmirBar-Maor . The sub types in the fabric points are necessary, if I can get them working. Our roads are part of the connection lines and the emergency service agencies have very strict requirements on what they can load to their emergency dispatch CAD systems. Road center-lines need to be covered by an end point, or intersection point in our terminology. And the endpoint and it's road centerline need to be linked by unique IDs.

I have a couple of attribute rules that help enforce this relationship on the fabric points that is set to the intersection point subtype.

A topology rule has previously helped enforce this. But this is no longer an option as the default Fabric topology rules applied at the class level prevent custom rules at the subtype level.

On a related note I think the attribute rules at the subtype level are bugged. They don't fire for me when applied at the subtype level but work fine when applied to the whole feature class. Has anyone reported anything like this? I'm about to file a bug report.

AmirBar-Maor

@DrewDowling

Beyond the bugs Tim listed above and their workarounds I recommend avoiding using subtypes for any feature class, including the parcel fabric feature classes unless they are used for their intended intention:

When you have to apply different rules (topology & attribute rules) within the same feature class
When you want to apply different domains, default values... within the same feature class.

Do not use subtypes just because:

A subtype layer allows you to turn on and off the visibility of subtypes
It seems logical

Downsides of using subtypes:

It adds complexity to managing your schema: applying rules, domains, and default values...
It adds complexity to managing your map: layers, feature templates
It adds complexity to configuring other things like Tasks, ETL automation ...
Some operations might not know which subtype needs to be applied and you might get unexpected results (e.g. build a parcel from a polygon - which subtype line to use?)

DrewDowling

@TimHodsonThank you so much for your detailed reply. Sorry for the late response, covid, but I've finally had a change to test using your suggestions and the software interface bug #1 that you mention is the problem that I was having. I changed the subtype code to 2 instead of 0 and everything showed up in the topology properties window.

However this lead me to another issue. I can't tailor topology rules using subtypes since the default fabric topology rules create a feature class level rules. Adding a subtype level topology rule for the same feature class results in:

ERROR 160172: Topology rules cannot be specified at both the class and subtype level for a given class and rule type.

Basically I have a connection line subtype, "Road", that needs to be covered by a fabric point subtype, "Intersection". The default parcel fabric topology rule is preventing this. So I sincerely hope that you allow these rules to be edited in a future release.

Finally I think I have found another bug that results when using fabric point subtypes. If I don't set a default point subtype then build parcels tool fails. ArcGIS Server records many topology error messages in it's logs. The workaround was to create a new point subtype for parcel corners and set it as default subtype. After this the buiuld parcels tool worked correctly.

TimHodson

Hi @DrewDowling - I've been working through your goal to add subtypes to connection lines and to fabric points. Thank you for your post. First, to answer your specific questions.

Are subtypes supported in Parcel Fabric lines and points? Yes.

Is the parcel fabric topology modifiable? Yes, but with some known limits, as described more fully below.

Here are some key points:

What you are attempting is possible with the parcel fabric. However, there may be a problem that you’re experiencing that I’ve not identified. Please respond here if this post does not solve any elements of your scenario, and we’ll continue work on figuring it out.
Two software user interface defects were found, and they have workarounds. These are both described under a logged support item (Reference: BUG-000152163). These defects and workarounds are described below.
There are some behaviors and user experiences that you may have encountered that are by design; some of these behaviors and user experiences are different from similar functionality in ArcMap.

Software user interface defect 1:

Workaround:

Instead of using a 0 code, use subtype codes starting at 1.

Software user interface defect 2:

Workaround:

Related to the specifics of the fabric generated topology:

- The Remove button is disabled for fabric generated topology rules. This is by design. We are considering allowing the removal of these rules in future releases.

- You are not able to alter the fabric generated topology rules.

-Tim

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

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