The FGDC Address Standard Readings Address Database Model

The FGDC Address Standard & Reading’s Address Database Model A work in progress…

UNITED STATES THOROUGHFARE, LANDMARK, AND POSTAL ADDRESS DATA STANDARD aka FGDC Address Standard (555 pages) 1. 4. 10 A Data Model, but Not a Database Model The [standard] defines an address data model. It states the rules for combining simple elements into complex elements, for composing addresses from simple and complex elements, and for using attributes to describe addresses and their elements… However, the standard does not provide a database model with table structures or relationships. FGDC Final Draft, November 2010, pp. 7 -8 Full text of document: http: //www. urisa. org/about/initiatives/addressstandard

1. 4. 11 A Few Basic Statements on Implementing this Standard An implementation guide is well beyond the scope of this standard, but a few things can be stated here: 1. The standard does not require parsing every address into its simplest elements, nor does it require creation of a complex, highly-normalized address data base. The standard recognizes and supports different levels of complexity, from the two-line format prescribed in USPS Publication 28 to a highly-parsed, fully-normalized database. 2. By the same principle, the standard does not require incorporation of every element and attribute. Only the Address ID is required for every address record. From among the others, select only those needed for the purpose at hand, and omit the rest. For example, if none of the addresses in a given area has any Address Number Prefixes, that element may be omitted from the address records for that area. In another example, the two-line USPS Publication 28 address format can be represented, if desired, by only two complex elements - or it can be composed from a more complex array of simple and complex elements. 3. The standard does not require use of most of the address attributes. However, the Address ID is required, and several other attributes are essential for most purposes. These choices, and others, will be dictated by the specific purpose for which the standard is applied, and the specific data to which it is applied. FGDC Final Draft, November 2010, p. 8

FGDC Standard Take Away Points ► Doesn’t require addresses to be parsed to their simplest elements ► Doesn’t require inclusion of address elements not used in your community ► Doesn’t specify field names, length or, for the most part, domains ► Doesn’t state whether field names should be in caps/lower case, but does rule out abbreviations except for 2 -letter state abbreviations ► Does advise adopting the parts of the standard relevant to your community and your purpose

This: Or this: “At this time, the Metro. GIS specifications focus on the ability to encode address point data into a fairly simple, flat database file format (e. g. shapefile). ” Metro. GIS Address Points Database Specifications (MN) 06/10/2010, p. 1

CT and MN examples are both simple, flat databases. (Both are address point GIS databases without related MAT. ) CT: http: //www. ct. gov/gis/cwp/view. asp? =3034&q=410292 MN: http: //www. metrogis. org/data/standards/address_guidelines. shtml

So, what is my purpose? 1. Maintaining a master address table for database applications, e. g. permitting 2. Public safety 3. Geocoding

Reading’s data model (a work in progress): ► ► An address point GIS layer A related master address table (MAT) A street name lookup table Represent every unique street address as a point, but not every unit Rationale: ► Keep the geography and the addresses separate § § § ► ► GIS maintains address points Engineering maintains addresses Other database applications use MAT for address validation Works well for geocoding Reduces number of stacked points Position of points can be improved to show building entry Keeps the attributes of the point separate from the attributes of the address

MASTER_ADDRESS. ADDR_NUM + MASTER_ADDRESS. STREET_NAME One to many Goals: 1. Keep # of fields low 2. Make tables useful on their own = tolerate redundancy 3. Avoid mashing of attributes, e. g. a “quality” field that combines positional accuracy & confidence in address itself.

An example:

Unresolved Issues: What tool(s) to use to automate address creation, lookup, and problem resolution? ► What’s the workflow? ► How to interface with Mass. GIS? ► Contact info: Kim Honetschlager, GISP GIS Coordinator Town of Reading 16 Lowell St Reading, MA 01867 781 -942 -6631 www. readingma. gov

URISA Connect Webinar: Addressing: Return on GIS Investment is Key to Local Government - Part 1 Presenter: Martha Mc. Cart Wells, GISP When: Wednesday, June 29, 2011 Time: 1: 00 PM EDT - 2 PM EDT Cost: Free for URISA members ($25 for nonmembers) Participation is limited. http: //www. urisa. org/education_addressing_part 1