Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

 

The Enterprise Addressing System (EAS) is the collection of:

  1. A spatially enabled database of situs (street-facing, structure entrance) addresses.
  2. A Web-based address data maintenance application.
  3. A suite of Web services that expose address validation, geocoding, and address look-up capabilities.

This article describes major EAS concepts, and defines terms that are commonly used when discussing the EAS.

Target Audience

This article is intended for:

  • City staff who are evaluating the suitability of the EAS, or its data, to support departmental address and addressing requirements. Note that the EAS has not been designed to solve every address problem in the enterprise (the City).
  • Anyone who is interested in becoming more familiar with, and possibly conversant with, the EAS.

Definitions

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.

  • address
    In this article, this is synonymous with "base address" and "unit address", unless otherwise noted.
  • AMA
    Address Maintenance Application. A primary component of the Enterprise Addressing System (EAS) consisting of 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.
  • APN *
    Assessor Parcel Number.
  • base address
    The preferred term for "Situs Address".
  • change request
    This is the mechanism by which an address gets created, retired, or changes status (see Address Status below). A completed change request gets reviewed, and is either accepted or rejected by the reviewer.
  • DBI
    Department of Building Inspection
  • DPW BSM
    Department of Public Works Bureau of Street-Use and Mapping
  • legal address
    This describes an address that the DBI has determined satisfies all of its business rules that allow the issuance of certain permits against that address.
    In the MAD (the database), a legal address will have the status value of "official".
  • MAD *
    Master Address Database. A primary component of the Enterprise Addressing System (EAS) consisting of a relational database management system (RDBMS) capable of spatially representing address data. The MAD also includes the situs data stored within the RDBMS.
    Before the EAS was a project, the term "MAD" was used to describe what would later become "EAS". For that reason, the term "MAD" is often used to mean what today might be more correctly called "EAS".
  • SFGIS
    San Francisco Enterprise GIS Program
  • Situs Address *
    A structure’s street-facing entrance. This will hold true irregardless (sic) of any information stored within the Assessor’s database.
    This term is effectively deprecated and has been replaced in common use by the term "base address".
  • SubAddress *
    An addressable element within a structure that does not face the street.
    This term is effectively deprecated and has been replaced in common use by the term "unit address".
  • unit address
    The preferred term for "SubAddress".
  • Web-based Address Data Maintenance Application
    An application that allows users with appropriate credentials to insert, edit, and delete situs address information stored within the MAD.

Concepts

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.

System Overview

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).

Additional Comments

The following comments are intended to clarify certain aspects of the System Overview.

  • EAS
    This is a simplified illustration of the EAS components:

  • MAD
    • The MAD was originally populated with addresses from the following sources:
      1. DBI Address Verification System (AVS)
      2. DPW BSM "bsmcoredata" database
      3. SFGIS "sfaddresses" shapefile
      4. DPW BSM Autocad basemap annotation points
      5. Planning Department address layer
  • Web Services
    • Because these are not specified in any detail yet, there is considerable opportunity for EAS stakeholders to contribute to the development of detailed Web service specifications.

System Users

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.

Additional Comments

The following comments are intended to clarify certain aspects of the System Users.

  • CCSF departmental staff
    • The intent is to make a URL to the AMA available for internal use by the entire enterprise (the City) staff.
  • CCSF Geographic Information Systems (GIS) staff
    • There is no class of users, including CCSF GIS staff, that will have direct access to the MAD, for example to execute SQL commands directly against the database.

Address Life-cycle

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:

  • The geographic location can be moved to a new location within the current parcel.
  • The "Mailing?" flag can be toggled.
  • The status can change (see Address Status below).

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 associated parcel is retired.
  • The street name of the associated street segment changes.
  • The address number is wrong or somebody wants to change it.

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.

Address Status

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:

  • official
    The reviewer has determined that the address is a legal address. This is a terminal status, so this address can never assume one of the other three status values once it has been determined to be "official".
  • provisional
    This is an address that has not been reviewed for legality.
  • tentative
    This is an address that has been created for the purposes of supporting the new-building construction permit process. The structure typically does not exist when an address with this status is created, and therefore is not a legal address (official).
  • unofficial
    The reviewer has determined that the address is not a legal address. This is a terminal status, so this address can never assume one of the other three status values once it has been determined to be "unofficial".

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.

 

Creating an Address

Assuming these exist in DPW/EAS

  • street segment
  • parcel

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

  • specify street (from 10 nearest official streets)
  • specify street number (from 0 to 999999)

At this point we have a “base address” which can be “submitted” and “approved”.

You can optionally do the following.

  • link parcels to the base address
  • add units to the base address
  • link parcels to the units

Once an address is approved in EAS, if it links to parcels, the data is messaged to AVS.

 

  • No labels