Select to view content in your preferred language

Owner Parcel vs Tax Parcel Import

4131
3
05-10-2012 07:30 AM
Labels (1)
TomNeer
Regular Contributor
I am delving into the Parcel Fabric for the first time. I understand the difference between the two but a little confused how the fabric handles these features

Both owner and tax parcels have been stored together in a shapefile. The shapefile contains two key fields. The APN field is a standard 12-digit PIN system (Twp-SecQtr-Block-Lot) and a Schedule number (assigned by the assessor). As I am preparing the parcels to import into the fabric, I am a little confused how to separate/code these?

My first thought was to assign a type of 7 (Tax Parcel) to all features with a schedule number and a type of 8 (Ownership) to features with only a APN number in the same dataset. Or should I duplicate the parcels into two datasets and assign all parcels with an APN type 8 and on the second set delete all the features without a schedule number and assign the remainder type 7? The later seems to be a bit redundant but what is intended.

Hope that makes sense. I look forward to your input.
Tags (2)
0 Kudos
3 Replies
ChrisBuscaglia
Esri Contributor
I am delving into the Parcel Fabric for the first time. I understand the difference between the two but a little confused how the fabric handles these features

Both owner and tax parcels have been stored together in a shapefile. The shapefile contains two key fields. The APN field is a standard 12-digit PIN system (Twp-SecQtr-Block-Lot) and a Schedule number (assigned by the assessor). As I am preparing the parcels to import into the fabric, I am a little confused how to separate/code these?

My first thought was to assign a type of 7 (Tax Parcel) to all features with a schedule number and a type of 8 (Ownership) to features with only a APN number in the same dataset. Or should I duplicate the parcels into two datasets and assign all parcels with an APN type 8 and on the second set delete all the features without a schedule number and assign the remainder type 7? The later seems to be a bit redundant but what is intended.


Hope that makes sense. I look forward to your input.


Tom,

Thanks for the post, I have a few comments and questions.

Is the schedule number the "recorders number"?

If so,

Option 1 (Recommended best practice):

This number should really be tied into the parcel as the "Plan" for the tax parcel.  The plan table can be populated with this schedule number an then tied to the parcel via the "PlanID" field.  The catch...the plan ID is only editable when you upgrade to 10.1.  If you don't move forward with 10.1, you could adopt a "day-forward" approach to this and tag all incoming tax parcels to their respective schedule (recorders) number as a plan.  You can also group all platted lands (lots, subs) within a plan...for example, "green acres" subdivison would have all the lots included within (PlanID on each lot matches the plan of record).

**Plans can be loaded to the Parcel Fabric (10.0, 10.1) by adding a field called "Plan" to the Parcels that you are loading.  You'll have to calculate the schedule number into this field, the loader does the grouping and plan table population for you!


Option 2

Carry the schedule number on every parcel.

On a related note, are you in Colorado? 

Chris
0 Kudos
TomNeer
Regular Contributor
Tom,

Thanks for the post, I have a few comments and questions.

Is the schedule number the "recorders number"?

If so,

Option 1 (Recommended best practice):

This number should really be tied into the parcel as the "Plan" for the tax parcel.  The plan table can be populated with this schedule number an then tied to the parcel via the "PlanID" field.  The catch...the plan ID is only editable when you upgrade to 10.1.  If you don't move forward with 10.1, you could adopt a "day-forward" approach to this and tag all incoming tax parcels to their respective schedule (recorders) number as a plan.  You can also group all platted lands (lots, subs) within a plan...for example, "green acres" subdivison would have all the lots included within (PlanID on each lot matches the plan of record).

**Plans can be loaded to the Parcel Fabric (10.0, 10.1) by adding a field called "Plan" to the Parcels that you are loading.  You'll have to calculate the schedule number into this field, the loader does the grouping and plan table population for you!


Option 2

Carry the schedule number on every parcel.

On a related note, are you in Colorado? 

Chris


Yes, the schedule number is the assessor's tax account number. The parcel id will identify the parcel, the schedule number will identify the associated tax record (if applicable). Not all parcels are tax parcels, but all parcels will have a parcel id.

I am a bit concerned with Option 1 as it does not seem logically consistent with the fabric model. Plans and parcels are in a 1:M relationship according to the model, not a M:M relationship according to the documentation. So how would you handle a subdivision or a survey containing multiple tax lots? Can you have a parcel associated both with the Green Acres Subdivision Plan and with the Schedule R100128 Plan? How would you assign the parcel to the second plan?

Theoretically, I should only need to maintain the parcel id (1088-231-00-001) and then link back to the assessor. Unfortunately, the current parcel data sometimes only has a schedule number but no parcel id, vice versa, or none at all. I'm still cleaning up that. I may need to go with option 2 during the transition but always open to other suggestions.

To get back to my first question, when importing, should I import all parcels as Owner Parcels and then duplicate the import for the Tax Parcels or not?

Yes, I'm in Colorado. Thanks for the input.
0 Kudos
ChrisBuscaglia
Esri Contributor
Yes, the schedule number is the assessor's tax account number. The parcel id will identify the parcel, the schedule number will identify the associated tax record (if applicable). Not all parcels are tax parcels, but all parcels will have a parcel id.

I am a bit concerned with Option 1 as it does not seem logically consistent with the fabric model. Plans and parcels are in a 1:M relationship according to the model, not a M:M relationship according to the documentation. So how would you handle a subdivision or a survey containing multiple tax lots? Can you have a parcel associated both with the Green Acres Subdivision Plan and with the Schedule R100128 Plan? How would you assign the parcel to the second plan?

Theoretically, I should only need to maintain the parcel id (1088-231-00-001) and then link back to the assessor. Unfortunately, the current parcel data sometimes only has a schedule number but no parcel id, vice versa, or none at all. I'm still cleaning up that. I may need to go with option 2 during the transition but always open to other suggestions.

To get back to my first question, when importing, should I import all parcels as Owner Parcels and then duplicate the import for the Tax Parcels or not?

Yes, I'm in Colorado. Thanks for the input.


Thanks for the response.

I figured that you were in Colorado since you use the same terminology as the City and County of Denver, who has implemented the Parcel Fabric.
The schedule number is not a depiction of ownership, correct?  It's just the last document of record that caused the land transaction (deed, sub, etc.).

You are correct, for every "parcel" there is an associated plan (1 plan for 1 or more parcels).

There are many types of parcels stored within a Parcel Fabric.  Let's look at parcels constructed with a new Subdivision:

Subdivision: 1 Parcel, related to a single plan called "Green Acres Subdivison"
Lots: 20 lots contained within the bounds of the above subdivison related to the above plan called "Green Acres Subdivision"
Tax Parcels: 19 tax parcels (Public ROW excluded) contained within the bounds of the above subdivison related to the above plan called "Green Acres Subdivision"

For lands not included within a platted subdivision (unplatted lands) each new tax description (deed) would be associated to a single plan (Schedule number).

Sorry if I wasn't clear, does this make sense?
0 Kudos