The Enterprise Addressing System (EAS) is the collection of:
This article describes major EAS concepts, and defines terms that are commonly used when discussing the EAS. |
This article is intended for:
It's worth reviewing the following definitions, many of which came from the Enterprise (Citywide) Address System___Master Address Database (MAD) and Address Maintenance Application Functional Requirements, Business Processes, and Logical System Architecture (366 KB) document. These are indicated by an asterisk (***) following the term.
The concepts are discussed in two parts, starting with information that is available in the Enterprise (Citywide) Address System___Master Address Database (MAD) and Address Maintenance Application Functional Requirements, Business Processes, and Logical System Architecture (366 KB) document, followed by information that is not as well developed.
This description is taken directly from page 6 of the Enterprise (Citywide) Address System: Master Address Database (MAD) and Address Maintenance Application Functional Requirements, Business Processes, and Logical System Architecture document:
The enterprise address system will consist of the following primary entities:• A single, authoritative database of situs addresses within CCSF (this database is termed the “Master Address Database” or MAD)
• A web-based address data maintenance application that will allow users with appropriate authentication credentials to insert, edit, and delete situs address information within the MAD.
• A suite of web services that will provide consistent address validation, geocoding, and address/assessor parcel number (APN) lookup capabilities for departmental Information Technology (IT) systems that may need addressing services to use.Together, the MAD, Address Maintenance Application (AMA), and the suite of addressing web services make up the CCSF’s enterprise address system (EAS).
The following comments are intended to clarify certain aspects of the System Overview.
This description is taken directly from pages 6 and 7 of the Enterprise (Citywide) Address System: Master Address Database (MAD) and Address Maintenance Application Functional Requirements, Business Processes, and Logical System Architecture document:
The EAS will support several classes of users, including:• CCSF departmental staff. These users may wish to manually confirm the existence and location of a situs address within the CCSF. Departmental staff may use the web-based address maintenance application to query the MAD and display the location of selected addresses on a map.
• CCSF Geographic Information Systems (GIS) staff. This user group may integrate situs address data with other geospatial datasets using desktop GIS applications. GIS staff will have read-only access to address data stored in the MAD.
• CCSF Address Maintenance staff. This user group will use the web-based address maintenance tool to insert, edit, and delete address information managed within the MAD.
• CCSF Business Systems. This user group consists of computer systems (for example a Permit Tracking System) that may request specific services from the EAS. For example, a software application that wishes to confirm whether an address provided by a user actually exists could invoke the EAS “Address Validation” web service.
The following comments are intended to clarify certain aspects of the System Users.
An address is created by using the Address Maintenance Application (AMA) to create a change request. Part of the information that must be provided on the change request is the existing street segment with which the proposed address will associated. The geographic location of the proposed address is indicated by specifying a point on a map. That point must fall within a parcel before the change request can be submitted. This means that every address in the Master Address Database (MAD), irrespective of its status (see Address Status below) enjoys this minimum level of "validity". In other words, an address can never be created on a non-existent street, nor can it be created on an area that is not a parcel, for example, in the middle of a street intersection.
New addresses are, by definition, also unretired. Only a limited number of changes can be made to an unretired address. These include the following:
If a change that is not listed above is required, then the address must be retired and a new address created. An unretired address can be retired by using the AMA to create a change request. A retired address can never be unretired. Addresses can be retired for a number of reasons including:
The MAD (the database) is designed to support the maintenance of an address' genealogy, though this is not currently enforced in the MAD or the AMA. A best practice for maintaining an address' genealogy is to create a change request that retires an address and creates a new one, rather than create a change request to retire an address and then create a second change request to create a new address.
An address must have a status but can only have one status value at a time. The status value can be any one of the following:
The transitions between status values are generally well-defined, as illustrated by the following figure. |
A change request is required to change an address' status. Note that it is not clear that the transition from "tentative" to "unofficial" is meaningful. |
Assuming these exist in DPW/EAS
If your street segment (or optional parcel) does not exist in EAS, EAS does not allow you to create an address for those features.
Use map to specify address location
At this point we have a “base address” which can be “submitted” and “approved”.
You can optionally do the following.
Once an address is approved in EAS, if it links to parcels, the data is messaged to AVS.