Parcels Blog Posts

The Pitfalls of Assessor Address Data for Cross-Department Address Sharing

Posted on April 10, 2012 by Adam Lodge

The most common source for address lists in City and County governments is the Assessor's database. On the surface, this makes sense given that addresses fall on parcels, and the Assessor does a pretty good job keeping its data up to date. But anybody who has scratched the surface of Assessor data will quickly see that there are some serious limitations to site addresses sourced from an Assessor database.

To understand why this is the case, first look at the mission of a County Assessor. The Assessor's mission is simply to identify tax parcels - or more accurately, tax accounts -, track their assessed valuation (in California, consitstent with the rules laid out in Prop 13), and track each parcel's owner name and mailining address so the tax collector can send a yearly property tax bill. Nowhere in this mission is there a requirement or mandate to track the address (or addresses) that fall on the tax parcel. Hence, the County Assessor only maintain situs address data for the convience of appraiser staff or for the benefit of other departments who use their data. In short, the Assessor has no significant business need to maintain situs address information.

When one looks closely at an Assessor tax role table, this reality is reflected in the situs address data. In every single tax role file that I have ever seen (with the exception of Solano County), each APN is related to one and only one situs address. This is a significant problem in apartment buildings, for instance, where you may have hundreds of site addresses on a given parcel, or in tenancies in common where you can have one address that links to many tax bills (hence APN's).

So what's a well-meaning Planning or Public Works Department to do? I think the future of municipal address management is stand alone, Spatially-enabled Enterprise Addressing Systems. A good Enterprise Address System should maintain the complex relationships between streets, parcels, and addresses, and provide an editing interface accessible to people who do not have a master's degree in GIS.

You can learn about the Enterprise Addressing System that we built in partnership with the City and County of San Francisco, and you should check out the Enterprise Address Repository & Maintenance Solution blog post series written by Farallon's CEO, Dennis Wuthrich.

Tags:   Enterprise Addressing System,   Parcels

Remodeling GIS Parcel Data for Ease of Use

Posted on March 15, 2012 by Adam Lodge

In GIS parcel layers, I find that users tend to assume that APN (assessor parcel number) represents a unique key for each parcel geometry in a County. Nine times out of ten, this assumption is wrong, and results in an inaccurate analysis. Here is why...

APN's represent property tax accounts (a bit like your local gas and electric utility account number), and parcel geometries represent a piece of geography that is taxed by the County. These are two slightly different things. It is possible, for example, to have a single tax account for two discontinuous (non-touching) pieces of geography. In a GIS parcel database, that will usually mean two separate geometry records that link to a single tax account record in the Assessor system.

This matters because users of GIS data often want to query and/or join data to parcel geometry based on APN. What if you want to know the total assessed value for all parcels within user-defined polygon? If two of those parcel geometries link to the same APN, then the assessed value for that one APN will be counted twice. Not good.

The best solution is to create a parcel layer in which APN is a unique key. This can be accomplished by combining GIS parcel records into multipolygons where there is a shared APN. It is ideal if you are running a spatial DBMS that is capable of constructing a view that does this on the fly (such as Oracle Spatial, PostGIS, or SQL Server Spatial.)

I recently wrote some SQL in PostGIS that did exactly this for the City of Walnut Creek in support of their Enterprise Addressing System. Below is the code:

SELECT
  apn,
  assessed_Value,
  owner_name,
  owner_address,
  ST_Multi(ST_Collect(geom))
 FROM(
  select 
  apn,
  assessed_Value,
  owner_name,
  owner_address,
  (ST_Dump(a.geometry)).geom
  FROM parcels_apn 
  ) foo 
 GROUP BY   
  apn,
  assessed_Value,
  owner_name,
  owner_address;

This is a nice way to transform parcel data so it's a little bit more friendly for end-users.

If anybody is interested I will gladly post how to accomplish the same data transformation using Oracle Spatial, SQL Server Spatial, FME, or ArcGIS.

Tags:   Database,   Parcels