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
Efficient processing of source address data into a Master Address Database (MAD) data model
Posted on April 29, 2011 by Adam Lodge
I’m kinda jazzed because I just proved out a script that ingests a series of raw address files and loads them to the Master Address Database (MAD) data model that we built for San Francisco last year as part of their Enterprise Addressing System. (We are also in the process of implementing the same MAD data model for Walnut Creek and San Mateo County.) The data processing required is significant. I have to sniff out and remove duplicates, identify appropriate x/y locations for each unique address record, and associate the addresses to a street segment, parcel(s), and zones. Drop a comment if you are interested in learning more of the processing details, but the bottom line is that we can now process source address data into a proven MAD data model very quickly and efficiently. I’m looking forward to employing this script to help more clients in the future make their MAD implementation easy and cost-efficient.
Tags:
Master Address Database
