The TaxParcels feature dataset contains the feature classes maintained by tax parcel editors and published for tax parcel consumers. Those who are familiar with the ArcGIS Parcel Data Model will notice we used this data model as a starting point for the content in this feature dataset. We did make some significant design changes that are important to note and understand as you organize your data and begin to load data into the template data model.

The data loading process is a bit different than the Basemap and Cadastral Reference because you have a target geodatabase design to load into. You can certainly use a different design or a design you already have, but as we mentioned previously that will mean more work on the MXDs and/or Applications provided with the templates. You might also want to use this latest design if you have existing data in the ArcGIS Parcel Data Model because it improves on previous examples.

Generally speaking you will need to do more than copy and paste your tax parcel features into a target geodatabase. You will likely need to construct new features, calculate values, and combine or split feature classes into new feature classes. And when you make changes like this to your geodatabase you should also have a plan for doing QA/QC on the results of the data loading process. Depending on the size of your organization’s data, this can be a time consuming exercise and even for simple examples many weeks of work can be involved in getting existing data loaded and validated. For those reasons, it might be more practical to contract this work out to an organization that specializes in data conversion or automation.

There are several approaches you can use to construct the features in the TaxParcels feature dataset. The final approach you take will probably depend greatly on the current state of your data. As you think through your approach, there are a couple of key design elements we should emphasize. At the same time, there are several tools in ArcGIS that will make the construction of this data easier.

Let’s start with the ParcelBoundary feature class and the construction of the TaxParcel feature class. The TaxParcel feature class represents a seamless inventory of lands in your community and is the feature class editors use on a day-to-day basis to maintain tax parcel information. Later, we’ll talk about how the TaxParcel feature class can be merged with information from your local assessment and tax system to create a TaxParcelPublishing feature class for consumers of parcel information.

If you currently have CAD data or an ArcInfo Coverage; you’ll probably want to start by loading this information into the ParcelBoundary feature class. Even those who have their data in a geodatabase already may want to start here because many times the only way to complete an inventory of taxable land is to go back to the boundary information that was assembled from source documents and construct subsequent polygons.

Loading your parcel boundary data should be pretty straightforward and unless you have to calculate fields during the import, the Simple Data Loader will probably suffice for this work. After you’ve completed loading your boundary information into the ParcelBoundary feature class, the next step is to construct TaxParcel polygons from the boundaries.

You can use ArcCatalog to construct polygon features from lines. To do so, right-click on the feature dataset that contains your ParcelBoundary feature class and select New>Polygon feature class from Lines. Select your ParcelBoundary feature class and the name of the polygon feature class you’d like to create. If you have a point feature class that contains parcel identification numbers, you could use these features at the same time to populate the ParcelID field in the TaxParcel feature class. One more note, you may not want to load the data directly into the TaxParcel feature class. Instead, you may want to create a temporary feature class you can review. At the same time, you can use this temporary feature class to identify tax parcel polygons and set the attribute flags in the TaxParcel feature class. Once you’re comfortable with the result, you can use the Simple Data Loader Tool again to load the data into your final TaxParcel feature class. Finally, you’ll notice that multi-unit polygons are managed in a related table (TaxParcelCondo) and a Relationship Class is created with the TaxParcel feature class. This is a common approach that makes it easier for parcel editors to track additional units on a single tax parcel polygon.

Once you’ve created the fundamental TaxParcel feature class, you can use this feature class to construct others in the TaxParcel feature dataset. You could construct the additional feature classes manually using several ArcMap tools, but it probably will be more efficient, and easier for you to repeat, if you construct a geoprocessing model to automate some of this work.

ArcGIS geoprocessing (GP) tools and scripts can be assembled into models and used for data manipulation and loading tasks. At a high level, the process involves using GP to massage the source data until it matches the data model of the target geodatabase, and then using commands like Append to get the features into your target geodatabase. This works well for most data loading situations, especially if you using Python or other scripting tools for automation.

Here is a simple example of a geoprocessing model that creates the RoadROW feature class from coded polygons in the TaxParcel feature class to get you started. It selects polygons where the ROWIndicator = ‘Yes’; removes unnecessary fields, and Appends the records to the RoadROW feature class.

For more complex data loading situations, you can use the ArcGIS Data Interoperability Extension. This extension provides a visual workbench to connect source and target datasets, and has a useful set of tools called "transformers" that can be used to perform calculations between source and target. This work can then be incorporated into the Spatial ETL Tools which can be run many times during your project. And while this approach does require you to learn an additional toolset, you’ll find that it is preferred by many specialists who are familiar with relational databases and data loading projects.

Here is an example of a Spatial ETL Tool that was developed with the Data Interoperability Extension. Conceptually, this tool uses the geometry from the TaxParcel feature class and a Geodatabase Table that contains related parcel characteristics to create the TaxParcelPublishing feature class.

In cases where multi-unit polygons are present, the tool replicates the tax parcel geometry for each unit and the result is a series of stacked polygons for each multi-unit development.

Combining tax parcel geometry with related parcel characteristics and publishing the combination as a separate feature class makes it easier to use this data in ArcGIS Desktop and simple web applications.

The Assessment Information feature dataset contains feature classes that influence property value within a community. This feature dataset contains several point feature classes that will be new to many users. These feature classes allow users to visualize land transactions and illustrate where geographic clusters are occurring. In most cases, this data will be sourced from other IT systems at a frequency that makes sense in your community.

This feature dataset also contains assessment neighborhoods and taxing districts that influence value and tax rates. The reason for putting these features in their own feature dataset is that they are edited on a different cycle than the tax parcel data and they may have different permissions/editors.

The taxing districts also are a set of reporting layers that allow us to summarize the number of land transactions and value/tax revenue change at a summary level. This information supports annual assessment reports prepared by local assessors for elected and administrative officials.

In addition, these reporting layers support web applications that require data be prepared in advance so users don’t have to run queries and wait for result sets. They can just click a few times on the map and get the information they are looking for. As a general principle, we want to "cook" the answers to common questions users ask. This will improve the user experience and reduce the load on web servers.

We created these feature classes by spatially joining the land transactions to sets of polygons like the LocalTaxDistrict shown below. We then performed further calculations to determine summary-level value changes. Ultimately you’ll need to also do some back-end work to get this data from one or more IT systems and into the feature classes contained in this dataset.

In each of the Templates, we’ve included a set of .html documents in the Documentation Folder that provide reports for the geodatabase and map documents. These documents will help you to understand the details of the geodatabases and maps. They will also help you plan out how to load data into your Geodatabase and make changes to map documents to work with your data.

Most projects will start with a source-target matrix spreadsheet that describes the available data and the target datasets for their new Geodatabase. This is a good place to start and it will help you to assess the suitability of the template design as well as the level of effort required to build your Geodatabase.

Again, this can be a large part of your project, so keep in mind that ESRI and Business Partners are here to help you if you need us. Network with your peers and get their recommendations on whom to work with. You can also email us at ArcGISTeamLandRecords@esri.com and we can get you in touch with someone local to help you to get started.