1. The FGDC Address Standard & Readings Address Database Model A work in progress…

2. 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/addressstandardhttp://www.urisa.org/about/initiatives/addressstandard

3. 1.4.11A 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

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

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

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

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

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

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

10. An example:

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

12. URISA Connect Webinar: Addressing: Return on GIS Investment is Key to Local Government - Part 1 Presenter: Martha McCart 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_part1