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

Managing Data Outside of Parcel Fabric?

ClayNorris

I'm wondering what the best method is for determining which data layers should be part of the Parcel Fabric. We have some layers that we don't necessarily care about tracking lineage, but we want to take advantage of topology. An example of this could be school districts or council districts. We want this to line up topologically with other layers in parcel fabric, but does it necessarily need to be included? What is best practice for deciding which layers to build into it? Lean and mean, or all encompassing? Thanks!

Finde mehr Beiträge mit dem Tag

General

Parcel Editing

Spatial Accuracy

Accepted answers

AmirBar-Maor

The parcel fabric was designed to support Administrative Parcels (like the districts mentioned above).
When creating a new parcel type you have the option to make it Administrative.

This makes sense when the 'parcels' (admin boundaries) coincide with the parcel layer. For performance reasons, it would be good to try and consolidate the number of 'parcel types'. This approach assumes that the datasets align to each other to start with. If they don't you have to start with a conflation project.

Another option, which is more labor-intensive and requires good 'bookkeeping', is available for those using ArcGIS Enterprise: use the geoprocessing Generate Parcel Fabric Links between 2 moments in time, and then apply the generated links and anchor points using the Rubbersheet Features tool to related data.

All comments

AndrewWallick

I'm also very interested in this. We have tons of layers that need to align to parcels, but so far it's mostly been a manual effort.

AmirBar-Maor

The parcel fabric was designed to support Administrative Parcels (like the districts mentioned above).
When creating a new parcel type you have the option to make it Administrative.

NateArnold

Is there a way to have administrative parcels be separated out by ownership/edit permissions from the core parcel types? One department edits the tax map, but there are other departments who have their own purview over polygons that need to align with the tax parcels etc.

AmirBar-Maor

The reason you would want the administrative parcels in the same parcel fabric is to keep the datasets coincide with each other.

When a point moves, you want it to update all the parcel features it is shared with, which means one group will effectively update parcels of another group. And that is something we want.

So how do we prevent people from one group create or update parcels of another group?

The answer depends on the level of trust between the groups. Here are a few solutions to consider based on the trust level:

Trustworthy - prevent accidental edits: each group works with a map that does not contain the feature templates of the features that are maintained by the other group. So they cannnot create parcel types they are not supposed to create.
Less Trust - you can create groups on your portal and associate users to each group. Arcade allows you to find which group a user belongs to:

// find which groups a portal user belongs to. Returns an array.
var myPortal = Portal("https://galileo.esri.com/portal/");
var currentUser = getuser(myPortal);
return currentUser.groups

You can use Arcade to create a validation rule that checks if a parcel from a given type was created by a user from the wrong group. This can also be a constraint rule. Make sure to use the triggering fields and allow parcels from the wrong type to have their geometry updated by the other group (e.g. - when a point is moved it should update all parcel types). If you want to get fancy you can also consider user the Arcade method $OriginalFeature to allow geometry updates to pass and prevent attribute updates.

3. No Trust - with this method you can create 2 parcel fabrics, one for each group and use the geoprocessing Import Parcel Fabric Points to TRY and keep them in sync. It will never be perfect, but if you start from the same parcel fabric, then delete the parcel type that is not needed for each group, you should have all the common points between the parcel types. This approach is likely to be used between 2 organizations that have 2 different networks that cannot be shared.

I hope this helps

Amir

jhonePebewir

Managing data outside of a parcel fabric involves handling spatial and tabular information without relying on the integrated parcel management system that a fabric provides. This approach allows organizations to work with cadastral or land records in standalone feature classes, tables, or external databases, giving flexibility for custom workflows Bookkeeping, historical data management, or integration with other GIS systems.

AmirBar-Maor

@jhonePebewir

Assuming you are not trying to advertise an app called Bookkeeing, this table might help you and others make an educated decision, and set the facts straight:

	Parcel Fabric	Stand Alone Feature Classes
Simple Feature Class	Yes	Yes
Manage Historic parcels	Yes - automatic	No - requires customization
Associate data to the legal record	Yes - automatic	No - requires customization
Maintain and View Parcel Lineage	Yes - automatic	No - requires customization
Integrate to business Systems	Custom	Custom
Support Database Views	Yes	Yes
Can extend Feature Class Schema?	Yes	Yes
Can Add relationship classes?	Yes	Yes
Can Add to geodatabase topology?	Yes	Yes
Can filter data to active record?	Yes	No - requires customization
Can use COGO Reader	Yes	No
Can use Merge Points	Yes	No
Can use Highlight Gaps and Overlaps?	Yes	No
Many more capabilities...	Yes	No
Efficient	Yes	No
Custom	No	Yes ($)

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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