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

Add ability to associate cartographic feature classes to record types in the fabric.

DeanAnderson2

Problem: Many users have cartographic feature classes (lines and annotation) that are managed in support of the parcel feature classes/types in the record. These feature classes are used to clarify and assist record editors and the public in understanding the parcel record features (polygons and lines). They are currently not viewable as being part of the record and are not retained the way historical polygons and line parcel fabric feature classes are.

Request: Develop a means where cartographic features classes (lines and annotation) can be associated/tied to the record types in the parcel fabric. By having this association when a parcel is marked as historic, the annotation and cartographic lines can also be marked as historic (not deleted but still available.) Conversely, as a parcel is created, all annotation and cartographic elements created are also associated with the record and would be visible, edited and managed as part of the record.

Current WorkAround: I have added the "created by record", and a field called "current" to my cartographic feature classes. (In hindsight I probably should have included the "retired by record" field instead of the "current" field). I have prototyped tasks with embedded scripts to manage how cartographic feature classes are added, retired and viewed as part of a record. This works but is not a great solution and does not provide the user with much flexibility.

Find more posts tagged with

Status: Open

Comments

AmirBar-Maor

@DeanAnderson2

Very well articulated and it's great to know you actually prototyped it and you know it can work.

Question:

Records do not get 'retired' but retire parent parcels when creating new parcels.

If the 'cartographic features' are associated to a record, they are defendable and could be potentially filtered using the 'Show Only Active Record' functionality.

Should the cartographic features be associated to a parcel instead? This can also can complicated as a single annotation on a shared boundary line can belong to 2 parcels. I guess it should get retired only when both parcels are retired and the RetireByRecord field should be populated with the last record (in case one is retired by record A and the second later by record .

For your current workaround Attribute Rules could be used to populate the fields in the cartographic features when a parcel (polygon / line) is updated.

Order of operations might also play a role - do the cartographic features always get created after the parcel is created?

It also seems this can also cover 'cadastral reference features' that often appear on cadastral maps like: walls, structures, trees, wells, ...

DeanAnderson2

Amir - here are response...

Should the cartographic features be associated to a parcel instead? No - My thought is that they should be associated with the record. As you stated if with the parcel it can get confusing. In addition, some cartographic features that may be put on the map (some reference lines) may not be directly associated with a single parcel. In our business process the cartographic features are associated with the record.

For your current workaround Attribute Rules could be used to populate the fields in the cartographic features when a parcel (polygon / line) is updated. I did not use attribute rules for this. As attribute rules are always on or off (with enterprise) and there are business cases where the cartographic features may be updated without a record. So I use tasks (user selects record to get the record id and then does work, as part of the task the feature is update with the record id). Sorry this explanation may not be overly clear.

Order of operations might also play a role - do the cartographic features always get created after the parcel is created? In our business process it seems so, but there may be exceptions that I have not thought of.

It also seems this can also cover 'cadastral reference features' that often appear on cadastral maps like: walls, structures, trees, wells, ... Yes these are also types of features that are part of the record.

I have also be discussing this with Frank Conkling (He has been helping me clarify my request).

AmirBar-Maor

@DeanAnderson2 @FrankConkling

Any feature class can be associated to the Records tables using a relationship class.

Such a feature can have the CreatedByRecord field (GUID). The field can get updated when using attribute rules when the cartographic feature is created or modified (Find all records that intersect if more than 1 choose the one with the latest 'Recorded Date')

But records do not retire... for example you could have a subdivision and a few merge and splits on top. So would the map technician set an extended attribute on the record to force all the related features as historic?

Other ideas?

FrankConkling

Amir,

I believe that is an acceptable interim workaround. I believe (and I apologize for assuming that I know what Dean is seeking) much of this can be accomplished using these types of workarounds on both cartographic features and annotation, but Dean may be asking that it become part of the Parcel Fabric core functionality and not a workaround.

Frank Conkling - Panda Consulting

AmirBar-Maor

@DeanAnderson2 @FrankConkling

We ship system attribute rules as part of the parcel fabric... they are not workarounds. Their advantage is that they can be further configured or even disabled if someone thinks they are not a good fit for the business requirements.

Since records are never retired, I am still struggling to understand what would trigger those features to retire.

FrankConkling

Amir,

Sorry if I implied that the shipped attribute rules are workarounds - they are not. I was referring to any additional rules that may need to be created to satisfy Dean's request, specifically dealing with cartographic lines and annotation.

If I understand Dean's request, he is seeking a way to track the annotation and cartographic elements that are associated with parcel configurations and ensuring that once the parcels are retired, the cartographic elements and annotation are not deleted, but marked as retired.

Frank Conkling - Panda Consulting

DeanAnderson2

Sorry for my absence. Took a short vacation and then was slammed with some non-gis deadlines. Very much appreciate the comments Amir and Frank.

1. The relationship classes and filters do work. But it requires me to set this all up and manage. (Yes I know I am lazy.) From a gis support persons perspective it would be great to have a tool/command that did this and then honored it through some basic operations as folllows:

-- When an record is active these features would automatically be assigned to the active record (the same way a line that participates in the parceltype would be.

-- When features are selected for the active record these features would be selected

-- When Show only Active record is clicked you would see these feature as well.

At this time all of these capabilities need to be managed within the task environment and with scripts.

2. Retire Records - Sorry about terminology - when a number of functions impact a record and the features associated with record are assigned "Retired By Record" I want this to also be done to the related feature classes.

To Be Clear - I am referring to a point, line and annotation feature classes that are used for cartographic purposes to assist in replicating a record. The following diagram illustrates some of these features (highlighted in red). I our redesign to Pro/Fabric and review of business practices these features remain as annotation and lines (I hope this helps describe what I am talking about).

DeanAnderson2

Tried to use the attribute rules. Users will need to be able to assigned related feature with a plan but this does not happen All the time and unfortunately, with enterprise attribute rules can not be turned off an on (unless this recently changed).

My current work around is to get the globalid from the current activerecord and use the arcpy.AssignDefaultToField_management tool to set the default value for each feature that is participating. Once it is turned on all features added after that time will have the global id updated. Once it is turned off this will not happen.