How to use the Measures in a Quality Control Program

The measures assume a certain body of knowledge about local addresses. Preparation for a local quality control program largely consists of assembling that information. These include:

• Tabular domains of values for street name components
• Spatial domains: jurisdiction boundaries, address reference scheme boundaries and components
• Address reference schemes: geometry and rules.

Tabular domains are frequently difficult to complete, as no organized list of street names may be available. In the latter case all available sources of street names should be compiled and checked against source documents such as plats and ordinances where possible. Official Status attributes may be helpful in assembling and maintaining domains of values. It will be normal to find a variety of street name abbreviations in use: Doctor Martin Luther King Junior Boulevard, MLK Boulevard, etc. Official Status attributes can help describe variations on street names that may appear in addresses assigned to the same location, or along the same street. As noted throughout the standard, the official name should be completely spelled out: Doctor Martin Luther King Junior Boulevard.

Address reference systems or other local conventions may govern much more than street number assignment. There may be street classification requirements for specific Street Name Post Type names. For instance, some jurisdictions may require "Courts" to be deadends, and forbid "Boulevards" on the same deadends. Street names may conform to themes in particular areas: numbers, birds, trees and presidents are some examples. The latter rule may be satisfied by applying the Spatial Domain Measure, but the former will require locally formulated tests. In any case, local conditions will require attention in drawing up a complete list of standard and local quality measures.

Once all of the domains and rules have been assembled, use the guidance in Address Data Content and Address Data Classification to assemble a list of measures for each aspect of your data. Informative Appendices D through G can be helpful in maintaining an overview of the process. Order the measures, beginning with the most basic: check simple elements and attributes first, then complex elements, then classifications. In cases where a quality check is beyond the scope of the standard create, name and document your own test, taking care to chose a name that does not duplicate one in the standard. It will be important to have the method completely documented both for maintenance, and in order to convey complete quality information to address users.

The table below shows how specific needs in a quality program for an E911 center match to measures.

-- Example QC program courtesy of Adam Iten

Construct SQL statements specific to your system from the code or pseudocode given in the standard, and test them. Run all the measures on a test data set to make sure they produce believable results. Where known address problems are not discovered by the measures, review how the measures are applied and double check the SQL. Check to make sure that all the characteristics of quality are thoroughly tested: attribute (thematic) accuracy, logical consistency, temporal accuracy, completeness, positional accuracy and lineage. Where there is insufficient information to check a given aspect of quality the address process may need review.

The measures are written to produce sets of identifiers. In practice it's important to see data in context. In a normalized relational database it is most often easiest to construct a view to display the data you want to see. The AddressPtCollection and StCenterlineCollection views can provide the ancillary information to describe query results.

Once a suite of measures has been constructed and tested, implementation consists of deciding when it will be run, and how to handle the results. For example, where a number of datasets from separate organizations are assembled to create a master address repository, a complete suite of tests may be run on each individual dataset before acceptance. The data may only be incorporated into the repository when the anomalies are either attributed and accepted as part of the data set, or resolved. Once the data are incorporated, it is risky to believe the combined data will test identically to each individual data set. While the street name components may be identical, other aspects may be affected by the inherent interdependence of addresses. The results of Address Number Fishbones Measure, for example, may be very different when new data are added. Quality control implementation, therefore, may require developing several suites of quality measures to support each part of the address process.

User confidence in a data set depends on an effective program. Test thoroughly, and document the process as well as the results. Recording dates and times is often an important part of that documentation. Users will question aspects of the data. Knowing the condition of the data over time simplifies response, and increases both the reality and perception of the value of the data.

Addressing is a dynamic process. Just as the construction of testing suites is based on the process, testing suites need to be reexamined each time an addressing process changes.