Migrating to Parcel Fabric using LGIM

[MarkWilloughby]

I'm working on migrating my organizations parcel data in to the parcel fabric at 10.2 using the local government information model.

In my jurisdiction (which is not located in the US), individual parcels are identified and registered at the land title registry using an identifier called the PID. Every parcel stored in the registry has a unique PID. Using the PID, interested parties can search the registry to find the parcel owner(s) together with any charges, liens, restrictive covenants or other encumberances that attach to the parcel title. As far as I can tell, this is analagous to the Owner Parcel in the parcel fabric. Is that correct?

For taxation purposes, an identifier called the Folio ID is assigned by the taxation assessment authority. As with the PID, each Folio ID is unique. Folio IDs are never the same as parcel PID's. I'm assuming that the Folio ID is analgous to the Tax Parcel in the parcel fabric. Is that correct as well?

In most cases, the relationship between Folio ID and the PID is one to one. In other cases, several owner parcels (PID's) are grouped together and assigned a single Folio ID for taxation purposes.

I need some assistance understanding how to populate the spatial and attribute data in the parcel fabric to ensure that I can retain the linework for each unique owner parcel and at the same time, have the ability to query and identify tax parcels in cases where several owner parcels have been grouped together.

When using the LGIM staging file geodatabase that is supplied with the Tax Parcel Editing Template:

- which attribute field do I populate in the tax parcel layer with the Folio ID?
- which attribute field do I populate with the PID?
- do I have to duplicate the linework from the owner parcels to the tax parcel layer and dissolve on Folio ID for cases where multiple owner parcels form a single tax Folio ID?

Thanks in advance.

[ChrisBuscaglia]

Sounds like you may be in Canada, I think that your assumptions would be correct.

If you were to look at the Parcel Feature class as part of the Parcel Fabric, you'll notice that the
'Name' field is used for multiple identifiers.  For example, the 'Name' Field is aliased to
"Lot or Unit Number" for platted lots, "Parcel Identification Number" for Tax Assessment numbers,
"Encumbrance Name" for easements and encumbrances, etc.  We also recommend that you alias the
parcel layer names for your particular business rules/needs.  Just keep in mind that the parcel types
"mean" something if you are going to take advantage for the automated parcel workflows.  For example, with the automated workflows, "Tax Parcels" cut into "Tax Parcels"for new metes and bounds descriptions. 

In addition to the PID, does your jurisdiction also maintain lots as part of platted subdivisions?  You
can think of lots as the legal framework for tax parcels, meaning you can have multiple lots making up one tax parcel.  If two lots are merged for tax purposes, there will be a single new tax parcel
overlaying the original lots (not disturbing the original geometries and related records).

You will also want to take a look at the 'Plans' table in the Parcel Fabric, this is used to store the original recorded information.  In your case, you'll want to take advantage of this table for storing the
registry information about the transaction.

Chris

[MarkWilloughby]

Sounds like you may be in Canada, I think that your assumptions would be correct.

If you were to look at the Parcel Feature class as part of the Parcel Fabric, you'll notice that the
'Name' field is used for multiple identifiers.  For example, the 'Name' Field is aliased to
"Lot or Unit Number" for platted lots, "Parcel Identification Number" for Tax Assessment numbers,
"Encumbrance Name" for easements and encumbrances, etc.  We also recommend that you alias the
parcel layer names for your particular business rules/needs.  Just keep in mind that the parcel types
"mean" something if you are going to take advantage for the automated parcel workflows.  For example, with the automated workflows, "Tax Parcels" cut into "Tax Parcels"for new metes and bounds descriptions. 

In addition to the PID, does your jurisdiction also maintain lots as part of platted subdivisions?  You
can think of lots as the legal framework for tax parcels, meaning you can have multiple lots making up one tax parcel.  If two lots are merged for tax purposes, there will be a single new tax parcel
overlaying the original lots (not disturbing the original geometries and related records).

You will also want to take a look at the 'Plans' table in the Parcel Fabric, this is used to store the original recorded information.  In your case, you'll want to take advantage of this table for storing the
registry information about the transaction.

Chris

Yes, I'm located in Canada and in the Province of British Columbia more specifically. We have one land title registry that is managed by the Province and we have one taxation assessment authority which is also managed by the Province. Among many other things including absolute certainty of title for prospective purchasors and lenders, this ensures that every titled parcel receives a unique ID (the PID) and that the taxation Folio ID's are also unique as well.

The original geometry of surveyed (platted?) lots is always maintained until such time that they become the subject of an additional subdivision or consolidation with a neighbouring parcel.

In most cases the geometry of a single PID and accompanying Folio ID is coincident. However, there are some cases where a single Folio ID is made up from the original geometry of multiple PIDs which are usually spatially adjacent.

What steps do I need to take to migrate tax parcels that are made up from multiple owner parcels and at the same time, preserve the geometry of the original owner parcels?

[ChrisBuscaglia]

Yes, I'm located in Canada and in the Province of British Columbia more specifically. We have one land title registry that is managed by the Province and we have one taxation assessment authority which is also managed by the Province. Among many other things including absolute certainty of title for prospective purchasors and lenders, this ensures that every titled parcel receives a unique ID (the PID) and that the taxation Folio ID's are also unique as well.

The original geometry of surveyed (platted?) lots is always maintained until such time that they become the subject of an additional subdivision or consolidation with a neighbouring parcel.

In most cases the geometry of a single PID and accompanying Folio ID is coincident. However, there are some cases where a single Folio ID is made up from the original geometry of multiple PIDs which are usually spatially adjacent.

What steps do I need to take to migrate tax parcels that are made up from multiple owner parcels and at the same time, preserve
the geometry of the original owner parcels?

Every type of parcel is a individual load into the Parcel Fabric.  If you take a look at the staging GeoDatabase as part of the Tax Parcel Editing template (http://www.arcgis.com/home/item.html?id=666f22f143e6454c8ecb6334dc8b5b43) you'll see that each parcel type is broken into explicit loading sources.

[ATTACH=CONFIG]30220[/ATTACH]

In the previous post I was attempting to draw a parallel between the Lot and Tax Parcel, the same pattern would be used for Ownership and Tax...

Hopefully this clears things up, let me know.

Chris

[MarkWilloughby]

Thanks for pointing me in the right direction Chris. You suggested earlier in the thread that the alias names of some of the layers could be altered to suit local business practices. Given that there are significant differences in cadastral terminology and nomenclature between my jurisdication and the US, what additional opportunities if any exist to customize/localize the LGIM to better suit my needs and still retain the OOB workflows and functionality?

[ChrisBuscaglia]

Thanks for pointing me in the right direction Chris. You suggested earlier in the thread that the alias names of some of the layers could be altered to suit local business practices. Given that there are significant differences in cadastral terminology and nomenclature between my jurisdication and the US, what additional opportunities if any exist to customize/localize the LGIM to better suit my needs and still retain the OOB workflows and functionality?

If you were to drag-and-drop the Parcel Fabric from ArcCatalog into ArcMap (included in the download, or simply create an empty Local Gov't Info Model Fabric), you'll see that there is a default "theme"
applied to the Fabric.  You can expose items that are included in the information model already
(like ownership) and modify symbols and alias if needed. 

[ATTACH=CONFIG]30222[/ATTACH]

I would also take a deep dive (if you haven't already) to see what commercial-off-the-shelf workflows
are supported and which of those make sense to your particular business.

http://resources.arcgis.com/en/help/main/10.2/index.html#/Parcel_editing_workflows/00wp0000006300000...

We also understand that these workflows have been designed and configured to streamline the editing process and may require subtle modifications to existing workflows, but also understand that they fit
the majority of maintenance workflows (even internationally). 

Moreover, if you feel that a workflow simply isn't supported, there are manual workflows with the parcel maintenance tools to get you through the work.  This is a good forum to bring those to the table so that we can take a look and make recommendations. If you have any concerns, please send them our way
and we can direct you to the right help and resource.

If you have feedback and need something that you're not seeing, please feel free to let us know.  Please sign up for the Land Records Meetup, this is a great resource as well!

http://www.meetup.com/Esri-Land-Records-Meet-Up/



Chris

[ChrisBuscaglia]

One thing that I didn't mention, but is a very important item.

The domains and set of values can be modified and extended.

[ATTACH=CONFIG]30286[/ATTACH]

For example, I'm looking at the simultaneous conveyance type here - you can see the available (not exposed stock) values that represent different subdivision types.  You can modify the descriptions, and even add your own.   This would be the first thing that I would evaluate before changing the layers in the map. 

Just keep in mind,  if you remove required values (Tax, Lots, Subdivision) you will disturb the automated workflows.

Let me know if this is enough information to get you started.

Chris

[MarkWilloughby]

Knowing that most of the domain values can be removed, modified, or added to is very useful in order to localize the parcel fabric to fit our particular needs.

Is there an available list of which values can't or shouldn't be modified because there is core system or automated workflow functionality that depends on them?

It would be useful to have such a list included in the next release of the documentation.

[ChrisBuscaglia]

Bottom line, without getting into too much detail, you'll want to make sure not to remove anything from the database that came stock with the Local Government Parcel Fabric (some standard Parcel Fabric fields cannot be deleted) , instead modify domain descriptions, extend domain values, and change layer names to represent local nomenclature.

Chris