The FGDC Address StandardThe FGDC Address Standard&&

Reading’s Address Database Reading’s Address Database ModelModel

A work in progress…A work in progress…

UNITED STATES THOROUGHFARE, LANDMARK, AND POSTAL UNITED STATES THOROUGHFARE, LANDMARK, AND POSTAL ADDRESS DATA STANDARDADDRESS DATA STANDARD

aka FGDC Address Standard (555 pages)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 PointsFGDC Standard Take Away Points

► Doesn’t require addresses to be parsed to their simplest elementsDoesn’t require addresses to be parsed to their simplest elements

► Doesn’t require inclusion of address elements not used in your Doesn’t require inclusion of address elements not used in your communitycommunity

► Doesn’t specify field names, length or, for the most part, domainsDoesn’t specify field names, length or, for the most part, domains

► Doesn’t state whether field names should be in caps/lower case, but Doesn’t state whether field names should be in caps/lower case, but does rule out abbreviations except for 2-letter state abbreviations does rule out abbreviations except for 2-letter state abbreviations

► DoesDoes advise adopting the parts of the standard relevant to your advise adopting the parts of the standard relevant to your community and your purposecommunity and your purpose

This:

Or this: “At this time, the MetroGIS specifications focus on the ability to encode address point data into a fairly simple, flat database file format (e.g. shapefile).”

MetroGIS Address Points Database Specifications (MN) 06/10/2010, p. 1

CT:CT: MN:MN:

http://www.ct.gov/gis/cwp/view.asp?=3034&q=410292 http://www.metrogis.org/data/standards/address_guidelines.shtml

CT and MN examples are both simple, flat databases.CT and MN examples are both simple, flat databases.(Both are address point GIS databases without related MAT.)(Both are address point GIS databases without related MAT.)

So, what is my purpose?So, what is my purpose?

1.1. Maintaining a master address table for Maintaining a master address table for database applications, e.g. permittingdatabase applications, e.g. permitting

2.2. Public safetyPublic safety

3.3. GeocodingGeocoding

Reading’s data model (a work in progress):Reading’s data model (a work in progress): ► An address point GIS layerAn address point GIS layer► A related master address table (MAT)A related master address table (MAT)► A street name lookup tableA street name lookup table► Represent every unique street address as a point, but Represent every unique street address as a point, but

not every unitnot every unit

Rationale:Rationale:► Keep the geography and the addresses separateKeep the geography and the addresses separate

GIS maintains address pointsGIS maintains address points Engineering maintains addressesEngineering maintains addresses Other database applications use MAT for address validationOther database applications use MAT for address validation

► Works well for geocodingWorks well for geocoding► Reduces number of stacked pointsReduces number of stacked points► Position of points can be improved to show building Position of points can be improved to show building

entryentry► Keeps the attributes of the point separate from the Keeps the attributes of the point separate from the

attributes of the addressattributes of the address

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.

MASTER_ADDRESS.ADDR_NUM + MASTER_ADDRESS.STREET_NAME

An example:An example:

Unresolved Issues:Unresolved Issues:► What tool(s) to use to automate address creation, lookup, What tool(s) to use to automate address creation, lookup,

and problem resolution?and problem resolution?► What’s the workflow?What’s the workflow?► How to interface with MassGIS?How to interface with MassGIS?

Contact info:

Kim Honetschlager, GISPGIS CoordinatorTown of Reading16 Lowell StReading, MA  01867781-942-6631www.readingma.gov

URISA Connect Webinar:

Addressing: Return on GIS Investment is Key to Local Government - Part 1Presenter: Martha McCart Wells, GISP 

When: Wednesday, June 29, 2011Time:  1:00 PM EDT - 2 PM EDT

Cost: Free for URISA members ($25 for nonmembers)Participation is limited.  

http://www.urisa.org/education_addressing_part1