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

How to handle one to many relationships when working with parcels?

LeahMontoya

Can someone tell me the best way to handle one to many relationships when working with parcels. We have condominiums that we have spatially represented with one polygon feature and one parcel number. They are represented in the Assessors database with multiple Assessor's parcel numbers. Any input as to how to best handle this situation would be very helpful.

Finde mehr Beiträge mit dem Tag

Local

Accepted answers

All comments

ScottOppmann

We have shared a series of best practices for condos in the Local Government Information Model. In your editing model, we would suggest you track the condo units in a related table and as you publish your parcel data you'll stack the condo polygons and associate the tax and assessment attributes with a unique polygon in your TaxParcelPublishing feature class. You can find more information about this topic in the Tax Parcel Editing Map and Data Dictionary for the Local Government Information Model.

LeahMontoya

Thank you Scott for all your help. I found the documentation you are talking about and will research what will work for us.

Leah

JohnHangen

We have shared a series of best practices for condos in the Local Government Information Model. In your editing model, we would suggest you track the condo units in a related table and as you publish your parcel data you'll stack the condo polygons and associate the tax and assessment attributes with a unique polygon in your TaxParcelPublishing feature class. You can find more information about this topic in the Tax Parcel Editing Map and Data Dictionary for the Local Government Information Model.

This sounds very interesting - I've long wanted to restructure our parcel data. Do you have the URL to this document? Thank you!

BillEveringham

Sounds like a lot of extra work to create the extra polygons. I'm not sure I agree with the way that is modeled. One of the reasons I don't use the local government model. We created a .asp page that references the real estate assesment table. No extra work had to be done to the parcel layer.

Check out my example.... 2900 Clarendon Blvd (condo)
http://gis.arlingtonva.us/gallery/map.html?webmap=700cf717476d403bb24699688170d17e

ArcGISTeamLocalGov

Just one more note. There is a sample python script in the Tax Parcel Editing Map that will help you create a publishing process for your organization. The publishing process we documented helps users quickly get access to property information in the information popup and query against these characteristics in a simple web mapping application. The approach or design you take will be defined or impacted greatly by the information products you wish to produce.

clt_cabq_0-1726584422368.png

Bud_0-1726585556108.png

DavidDenham

We have shared a series of best practices for condos in the Local Government Information Model. In your editing model, we would suggest you track the condo units in a related table and as you publish your parcel data you'll stack the condo polygons and associate the tax and assessment attributes with a unique polygon in your TaxParcelPublishing feature class. You can find more information about this topic in the Tax Parcel Editing Map and Data Dictionary for the Local Government Information Model.

Scott, why is ESRI suggesting that we stack polygons to handle condo tax records? It seems to be a lot more complicated and require more effort to maintain all of the duplicate parcels. If you include a tax id field in the parcels layer you could simply use a one to many relate to a tax roll table to achieve the same results. This method would only require you to maintain a single parcels layer and a single parcel for each condo development.

JeffWard

Scott, why is ESRI suggesting that we stack polygons to handle condo tax records? It seems to be a lot more complicated and require more effort to maintain all of the duplicate parcels. If you include a tax id field in the parcels layer you could simply use a one to many relate to a tax roll table to achieve the same results. This method would only require you to maintain a single parcels layer and a single parcel for each condo development.

David,

Scott isn't saying that you run the scripts and then use the exploded parcels as your editing parcel layer from that point forward. The idea is to run the scripts on a regular basis and the public parcel viewing app or any of the other public apps would use the exploded or published version of the parcel layer. It makes it quicker for the app to retrieve the ownership info if the table is flat instead of having to go grab it from a related table, much like a cached imagery service. There are two feature datasets in the local gov IM to handle parcels, ParcelEditing and ParcelPublishing. You run the scripts on the ParcelEditing set and they get moved over to the ParcelPublishing set.

ScottOppmann

David -

Thanks Jeff for hitting most of the key points. Let me just add a few more things. First, interacting with stacked polygons is much easier with the out of the box clients and APIs. A simple mouse click or query will return all the records you're interested in and you don't have to write code to query related records, handle condos uniquely, etc. In addition, you'll probably also want to also merge property attributes from your CAMA and Tax systems when you publish your parcel geometry. Then you can quickly leverage those in information popups and other apps we have in the ArcGIS for Local Government solution (Tax Parcel Viewer, Public Notification, Value Dashboard, etc.). So, typically most local governments extract data from these systems on a regular basis and merge it with their parcel publishing (geometry) process and end up with a set of features much like we have in the Parcel Publishing feature dataset.

Hope this helps.

Scott

BeccaBlackman1

I've found the 'Tax Parcel Publishing' script in the ParcelPublishingTools toolbox from the TaxParcelEditingfor10.1 that I believe is supposed to migrate our data from the Parcel Editing dataset to the Parcel Publishing dataset. I have not been successful in running this tool. Looking at the updatetaxparcels.py in the same Parcel Publishing folder I cannot figure out where to change the python code to make this script work. Is there an updated version of this script or any reason for it to not be working?

christopherfricke2

Your best bet is to use a spatial view if you are using an SDE database. This will allow you to create the stacked polygons w/o requiring you to duplicate data. Also, this allows for a more dynamic process. The most up to date data is returned every time the client makes a request to the spatial view. The python tool example means that there is always a lag time between edits performed on parcels or assessor info and what is visible to the clients.

You need to make sure that you pull a unique OBJECTID from the joined table. Otherwise queries will return really crazy results.

I have also used this method to pull in Assessor info from external databases (like BSA).

SELECT Assessor.OBJECTID, Assessor.OwnerName, Parcel.ParcelID, Parcel.Shape 
FROM dbo.Parcel 
INNER JOIN dbo.Assessor
ON Parcel.ParcelID = Assessor.ParcelID

--------------
Christopher Fricke
GISi

RyanKelso

I've found the 'Tax Parcel Publishing' script in the ParcelPublishingTools toolbox from the TaxParcelEditingfor10.1 that I believe is supposed to migrate our data from the Parcel Editing dataset to the Parcel Publishing dataset. I have not been successful in running this tool. Looking at the updatetaxparcels.py in the same Parcel Publishing folder I cannot figure out where to change the python code to make this script work. Is there an updated version of this script or any reason for it to not be working?

I want to provide an answer to this question since I had the same problem as b.blackman and this thread came up for me in a search.

If you have enabled the Local Government Information Model on your parcel fabric, which you would have if you want to use the Tax Parcel Editing Template, then there is no "Parcels" sub-layer in the fabric. This is why the following line fails:

parcels = r"%s_Layer\Parcels"%(name)

With the LGIM enabled on the parcel fabric, there is a sub-layer called "Tax Parcels", which is what you want to use. So change the line I mentioned before to:

parcels = r"%s_Layer\Tax Parcels"%(name)

Also, the Tax Parcels sub-layer has already queried out historical parcels, so the query in the following line will return 0 parcels so none will be appended to the parcels publishing feature class:

arcpy.management.SelectLayerByAttribute(parcels, "NEW_SELECTION", """Type = 7 AND Historical = 0""")

So remove AND Historical = 0 from the query to get the proper results. I suppose you could even completely remove the Select Layer By Attributes line because the Tax Parcels sub-layer has already been queried to only include Type 7. These are the things I had to do to get the script working, I hope this helps anybody with this problem.

edit: sorry for reviving such an old thread, but it came up on a google search and I only noticed the last two posts were from a month ago!

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.