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
Enterprise Address & Maintenance System - Part 3: Why we released as Open Source
Posted on April 03, 2012 by Dennis Wuthrich
The Enterprise Addressing System is a complete master address repository, address creation & maintenance system, and address query & validation solution. In this three part series I try to describe the solution from both technical and usability perspectives.
- Part 1 of this series describes the context and motivation behind the Enterprise Addressing System (EAS).
- Part 2 discusses address maintenance workflows and the use of open standards.
- Part3 (this post) discusses why we developed the solution as Open Source.
Take it for a Test Drive
We built the Enterprise Address System (EAS) as an Open Source solution. This means you can access it and test it or fully implement it without any licensing costs. Once you've done the test drive and you confirmed that it does the essential things that you need it to do, then you can go ahead and begin customizing it as needed.
The Open Source approach also means that you aren't beholden to a single vendor's timeframe for updating it, augmenting it, customizing it.
A common analogy that I like is to imagine that you're thinking of buying a car. With proprietary software you are buying a car with the hood welded shut. You're forced to go to the car manufacturer for maintenance, parts, and improvements.
With the EAS Open Source solution you are buying a car where you can chose where to have your car serviced and maintained. You can even open the hood yourself and make modifications wherever you want. And since it is based on open standards, you aren't restricted to buying one kind of tire from a particular manufacturer. You can buy tires or any add-ons from any vendor you choose. On top of that, you can take the whole thing out for an extended test drive before you buy.
Low Risk for High Return
Analogies aside, the take away from the Open Source approach is that the EAS is a low risk, high return way of getting an authoritative solution implemented in your organization to manage a headache common to almost every city or county.
Tags:
Enterprise Addressing System,
Master Address Database
Enterprise Address Repository & Maintenance Solution - Part 2: Workflows & Application Integration
Posted on March 26, 2012 by Dennis Wuthrich
In Part 1 of this series, I described the context and motivation behind the development of our Enterprise Addressing System, a complete master address repository, address creation & maintenance system, and address query & validation solution.
To reiterate:
- Addresses are critical data
- Its a challenge to keep address system up to date
- Its almost impossible to keep systems synced across departments
- You can't ask departmental staff to manage addresses using traditional desktop GIS tools because the technology's too challenging and too expensive
- The top priorities for any solution need to be ease-of-use, transparent address entry/validation/maintenance and web-based access
In this second post of the three part series, I want to talk about address maintenance workflows and the use of open standards.
Make Enterprise Address Maintenance and Management Simple
The importance of ease-of-use applies to address maintenance, just as it does for address querying or address entry. For example, if an address isn't in the system, is it because of the spelling or a transposition of numbers? Or is because the address doesn't exit or needs to be updated in some way.
In any of these cases, EAS offers a straightforward, consistent way of requesting an address update through a validated workflow. So anybody who has account privileges to edit addresses can say, "I'd like to make this change to this address," or, "I'd like to add this address," or, "This address doesn't exist anymore and should be replaced with this new address." The EAS processes this as a change request and the information is automatically passed on to someone who has authorization to review and approve that request. If it is approved, great, it goes into the system. If it isn't approved it's sent back to the requester with a message explaining why the address change request wasn't approved and the additional information or changes that need to be made before it can be approved. The workflow is very structured and controlled but highly streamlined and very easy to implement.
The address maintenance workflow represents what I think is fundamentally key about the EAS. It turns a difficult job that happens everyday across many departments into a significantly easier task if you're just an address consumer and an order of magnitude easier to manage if you're an address creator or an address approver.
It is important to note two additional things about EAS: It is Open Standards-based and Open Source.
Open Standards Addressing Solutions Enables Cross Application Integration
The Enterprise is standards based. It is compliant with the recently FGDC approved standard for managing address and ensures that every single address point can be resolved back to a street or a parcel. So this gives you a consistent way, standards-based way of managing addresses that can be integrated with other systems that rely on addresses.
The classic example is dispatching systems. You want your fire department and your police department to go to the right place. So it is essential your dispatching system comes from and integrates with some kind of authoritative address system.
And, as anyone who's worked with E911 systems knows, it's pretty common to get a call that the system can't automatically tie to an address. When this happens, dispatchers often insert a new address into their E911 system.
This means there's always a potential for the dispatch addressing database and the police/fire department addressing database to diverge. But using the EAS and standards-based data, the dispatcher can go ahead and add the address to their system for this mission critical task. A web service from the dispatching system could then communicate with the EAS and automatically submit an address change request that goes to through the same structured review process as any other address update request. This keeps these different mission critical systems in sync.
Permitting is another example of cross application integration using standards. You might not want to issue a permit if the building's address doesn't exist in the EAS or if it's address is out of date or needs to be modified because you're splitting a parcel. So the EAS is built to enable you to integrate with a legal document system such as permitting and match this against an address list. As a side note, the EAS-generated address list remembers lineage. So for example if you had a building that had an address of 610 Mission St back in the 1960s, but then that building was torn down and it was replaced by a building called 612 Mission Street, there's still a way to link those two addresses to the same location.
Part III - Why Open Source Matter for an Enterprise Address Repository and Management System
In the final post in this blog series on the EAS I will talk about the advantages of delivering an addressing solution that is Open Source
Tags:
Enterprise Addressing System,
Master Address Database
Standardize Addressing Across the Enterprise: The Why and How of EAS
Posted on March 20, 2012 by Dennis Wuthrich
Almost everything that a city or county government does or any service they provide is tied to an address.
Whether it is firefighters responding to a 911 call, public works staff responding to work orders, or an individual applying for a street-parking permit, the ability of a city or county to provide services depends on knowing the address of where someone or something is located.
Addressing Across the Enterprise Has Long Challenged Local Governments
To meet this need for address data, individual departments within local governments often develop their own solutions for entering, maintaining and using address data. This can range from a list of addresses in an Excel spreadsheet to a highly vertical application/database. Few systems have been designed to manage and share addresses across departments and applications.
For example, a county's E911 dispatch addressing system and assessor parcel addressing database are typically managed by several people in different departments with greatly differing jurisdictions and priorities. Across departments, the same basic address data might be entered twice using different standards. Consequently, address management systems usually do not sync-up. This duplication is not only a waste of time, it opens the door to errors, inconsistencies, lost revenues and poor customer services.
Why is Standardized Addressing so Challenging?
Standards for address management do exist, and some local governments do use GIS to try and manage addresses in a more formal way. But this approach requires a county or city government to have trained technical staff to key address data into a GIS. Moreover, the underlying GIS typically aren't address-centric so a GIS operator needs to do significant work to make the GIS system understand how to manage an address. Perhaps even more problematic, the GIS operators aren't the people using the addresses. So you're asking someone who isn't going to use the data to be managing the data.
It's tempting to try and give the people who actually rely on addresses GIS tools to help maintain the data. Unfortunately, most people don't have the time to learn GIS, let alone manage it. And their department probably doesn't have the money to allocate to the yearly licenses and on-going training.
The Enterprise Addressing System Solution
That's the context and motivation behind the development of the Enterprise Addressing System (EAS), an Open Source web-based master address repository, maintenance, management, query and validation system that Farallon developed in partnership with the City and County of San Francisco.
Our motivation for developing the EAS was driven by a couple of fundamental facts:
- Addresses are critical data
- Its a challenge to keep address system up to date
- Its almost impossible to keep systems synced across departments
- You can't ask departmental staff to manage addresses using traditional desktop GIS tools because the technology's too challenging and too expensive
Creating an Addressing System Users Want and Know How to Use
Our first priority was to make the EAS easy-to-use. This required the EAS to be web-based in order to ensure that all address users could easily access, maintain and update addresses from a single authoritative database. This also meant that the rules that go into confirming address data are complete and valid, would need to be transparent to the people using the EAS.
An EAS user doesn't have to know anything about how to access addresses data or how to confirm that addresses are valid. If for example, you're working at a help desk or you have to confirm that an address actually exists before you can take the next step in your workflow, such as issuing a permit, you just log in to this web application and type in an address. Its either there and you find it or if it isn't, the system shows you the nearest valid address. With the EAS, getting access to the authoritative data is simpler and you know it's consistent across every department.
Part II - Addressing Maintenance Workflows & Open Standards
In the next post in this blog series on the EAS I will talk about the maintenance workflows as well as the use of standards
Tags:
Enterprise Addressing System,
Master Address Database
