fgdc document number€¦ · web viewaddress feature type (the type of feature located by the...

FGDC Document Number

FGDC Document Number XX

United States Thoroughfare, Landmark, and Postal Address Data Standard (Draft)

Standards Working Group

Federal Geographic Data Committee

January 2010

Federal Geographic Data Committee

Established by Office of Management and Budget Circular A-16, the Federal Geographic Data Committee (FGDC) promotes the coordinated development, use, sharing, and dissemination of geographic data.

The FGDC is composed of representatives from the Departments of Agriculture, Commerce, Defense, Energy, Housing and Urban Development, the Interior, State, and Transportation; the Environmental Protection Agency; the Federal Emergency Management Agency; the Library of Congress; the National Aeronautics and Space Administration; the National Archives and Records Administration; and the Tennessee Valley Authority. Additional Federal agencies participate on FGDC subcommittees and working groups. The Department of the Interior chairs the committee.

FGDC subcommittees work on issues related to data categories coordinated under the circular. Subcommittees establish and implement standards for data content, quality, and transfer; encourage the exchange of information and the transfer of data; and organize the collection of geographic data to reduce duplication of effort. Working groups are established for issues that transcend data categories.

For more information about the committee, or to be added to the committee's newsletter mailing list, please contact:

Federal Geographic Data Committee Secretariat

c/o U.S. Geological Survey

590 National Center

Reston, Virginia 22092

Telephone: (703) 648-5514

Facsimile: (703) 648-5755

Internet (electronic mail): [email protected]

Anonymous FTP: ftp://fgdc.er.usgs.gov/pub/gdc/

World Wide Web: http://fgdc.er.usgs.gov/fgdc.html

CONTENTS

Page

11. Introduction

31.1 Objective

51.2 Scope

1.3 Applicability17

171.4 Related Standards

1.5 Standards development procedures20

1.6 Maintenance authority23

1.7 Acronyms Used in the Standard24

1.8 Trademark Acknowledgements27

2. Address Data Content27

2.1 Purpose27

2.2 Organization27

2.3 Simple elements, Complex Elements, and Attributes28

2.4 Element and Attribute Definitions and Descriptions29

2.5 Element and Attribute Data Types30

2.6 Notation for Constructing Complex Elements32

2.7 XML and GML Standard32

2.8 Address Elements33

2.9 Address Reference Systems99

2.10 Address Attributes143

3. Address Data Classification216

3.1 Introduction216

3.2 Address Classes220

3.3 Abstract Address Feature Class and Address Collection279

4. Address Data Quality280

4.1 Introduction280

4.2 Anomalies: Uncertainty and Addresses283

4.3 Measuring Address Quality284

4.4 Applying Measures to Domains of Values286

4.5 How to Use the Measures in a Quality Control Program287

4.6 About Nodes for Quality Control291

4.7 Quality Measures296

5. Address Data Exchange412

5.1 Introduction412

5.2 Structure and Transfer Package414

6. References458

6.1 Standards and Specifications Cited458

6.2 Other Works Consulted470

4747. APPENDICES

4747.1 Appendix A (Normative) XSD

7.2 Appendix B (Informative) Address XML Examples525

7.3 Appendix C (Informative) Table of Element Relationships532

7.4 Appendix D (Informative) Relationship of Address to Transportation 534

7.5 Appendix E (Informative) Element Measure Index543

7.6 Appendix F (Informative) Attribute Measure Index547

7.7 Appendix G (Informative) Classification Measure Index550

7.8 Appendix H (Informative) Quality Measures by Data Quality Report552

7.9 Appendix I (Informative) Compatibility of the Address Standard with the FGDC

Geographic Information Framework Data Contents Standard556

1. Introduction

The Need for a Comprehensive Address Data Standard

Addresses are the location identifiers most widely used by the public and by state and local government. Addresses are critical information for administrative, emergency response, research, marketing, mapping, GIS, routing and navigation, and many other purposes. Because they have evolved over many decades, under the control of thousands of local jurisdictions, in many different record and database formats, and to serve many purposes, different address formats and types pose a number of complex geoprocessing and modeling issues. As a consequence, government agencies struggle with these issues as they seek to integrate large, mission-critical files into master address repositories.

Local governments must record and locate every address within and around their jurisdictions. Local governments must ascertain the location of every address that appears anywhere in their administrative records--every residence, business, public structure, building permit, emergency response site, voter, school child, and public service client, including addresses where no one resides and no mail is received. In many places addresses are also used to identify infrastructure facilities, including bus stops, fire hydrants, utility poles and meters, cell phone towers, manholes, and signs.

To organize, maintain, and provide address records, local address authorities must create master address repositories that replace the numerous isolated, incomplete departmental address data files with one authoritative, integrated geographic address database. The construction of master address repositories is of paramount importance at the local level, because it permits departments to integrate address-related records, and ultimately operations, across department lines. The repository must include, not just the address itself, but its coordinate location, and documentation of where the address record originated and whether it is (or ever was) valid. To check validity and facilitate data maintenance, the repository must record the business rules by which addresses are assigned.

Emergency dispatchers in particular require accurate address locations. Emergency dispatchers must be able to route an emergency vehicle to any address in their response area, under circumstances when minutes matter. For emergency dispatchers, having well documented, standardized address data can mean the difference between life and death.

Many 911 callers use cellphones, which report the callers’ coordinates, but not their addresses. Emergency dispatchers must then infer the address from the coordinates. Translation from the coordinates to addresses is thus of increasing importance for dispatchers and first responders.

The USPS, commercial delivery services, and direct mail firms, before sending anything or attempting delivery, must verify the delivery address by standardizing it and matching it against a standardized master address list. Together they have, over several decades, worked out specifications for standardizing addresses and formatting mailing labels. The specifications are published in USPS Publication 28, “Postal Addressing Standards.” The USPS maintains the nationwide master list of mailing addresses. Maintenance is complicated by the general lack of any local authority for address updates.

Government agencies require unambiguous ways to exchange address data among different units of government, both at the local level, e.g., city to city, or city to county, and between different levels of government, e.g., from city or county to regional, state and federal agencies. The need is critical in times of emergency.

Finally, regional, state, and federal agencies (as well as private-sector firms) must aggregate local address files into state and national address lists. These include, most prominently, the USPS ZIP+4 and City State files, and Census Bureau MAF/TIGER files.

A comprehensive address data standard must serve the full range of these needs: postal delivery and census enumeration, local government administration and intergovernmental cooperation, emergency dispatch, the creation and administration of master address repositories by local address authorities, and the aggregation of local records into larger regional, state, and national address databases.

In sponsoring the creation of the United States Thoroughfare, Landmark, and Postal Address Data Standard, the Federal Geographic Data Committee (FGDC) has sought to convene, under the auspices of its Subcommittee on Cultural and Demographic Data, interested parties from among the local, state, Federal, and non-government sectors to resolve address data modeling and geoprocessing and to create a comprehensive address data standard, thereby helping to make our national spatial data infrastructure truly national.

1.1 Objective

The United States Thoroughfare, Landmark, and Postal Address Data Standard has been created to:

· Provide one standard that meets the diverse address data management requirements for local address administration, postal and package delivery, emergency response (and navigation generally), administrative recordkeeping, and address data aggregation.

· Support the use of best practices in address data management.

· Provide a systematic, consistent basis for recording all addresses in the United States.

· Define the elements needed to compose addresses and store them within relational databases and geographic information systems.

· Define the attributes needed for address documentation, mapping, and quality testing, including address ID’s, coordinates, and linear reference locations.

· Provide a complete taxonomy (systematic classification) of US addresses that is useful to address data managers.

· Introduce the idea of the address reference system—the formal description of the local address assignment rules, both spatial and non-spatial—and define its elements and attributes, as a basis for address assignment and quality testing.

· Define tests and procedures for address data quality testing, error-trapping, and anomaly identification.

· Support seamless exchange of address information, and foster consistent implementation of this standard, by defining XML models for every address element, attribute, and class, integrated into a single XML Schema Document.

· Offer a migration path from legacy formats to standards-compliant ones.

· Recognize, as a practical matter, that different business purposes and different data sources will require different levels of complexity in address data records, files and repositories.

· Build on USPS Publication 28, the Census Bureau TIGER files, the FGDC Content Standard for Digital Geospatial Metadata, the FGDC's National Spatial Data Infrastructure (NSDI) Framework Data Content Standard, and previous FGDC address standard efforts.

1.2 Scope

1.2.1 Subject and Area

The United States Thoroughfare, Landmark, and Postal Address Data Standard covers thoroughfare, landmark, and postal addresses within the United States, including its outlying territories and possessions.

1.2.2 Structure: One Standard, Four Parts

This standard has been developed in conformance with the FGDC Standards Reference Model for data standards. It provides, in four separate parts, a data content, classification, quality, and exchange standard for thoroughfare, landmark, and postal addresses, and for address reference systems:

· Data Content standards provide semantic definitions of a set of objects. In this standard, the content part specifies and defines the data elements that may appear in or describe street, landmark, and postal addresses, and address reference systems.

· Data Classification standards provide groups or categories of data that serve an application. In this standard, the classification part defines classes of addresses according to their syntax, that is, their data elements and the order in which the elements are arranged.

· Data Quality standards describe how to express the applicability or essence of a data set or data element and include data quality, assessment, accuracy, and reporting or documentation standards. In this standard, the Data Quality part specifies tests and measures of address data quality.

· Data Exchange standards describe how to produce or consume packages of data, independent of technology and applications, to facilitate moving data between agencies and systems. In this standard, the Data Exchange part provides a complete XML schema description for exchange of address data.

The United States Thoroughfare, Landmark, and Postal Address Data Standard is thus one standard, comprised of four parts: Address Data Content, Address Data Classification, Address Data Quality, and Address Data Exchange.

1.2.3 Definition of “Address.”

This standard proposes a new definition of "address":

An address specifies a location by reference to a thoroughfare or a landmark; or it specifies a point of postal delivery.

This definition differentiates addressing from the two other types of spatial referencing systems, coordinate reference systems and linear reference systems. The difference rests, not on what the systems locate, but on what they refer to in order to specify a location. Coordinate reference systems specify location by reference to a grid, spheroid, or geoid (and a datum). Linear reference systems specify location by reference to a route (and a beginning point). Within the context of this standard, coordinates and linear reference locations are treated as attributes of addresses, or, in the cases of certain postal delivery addresses, as inapplicable. This definition also excludes email and other computer system addresses.

This definition places address occupants and mail recipients (addressees) outside the scope of the standard. Many postal addressing standards include specifications for personal names, business names, and internal distribution points such as mailstops, particularly in the context of specifying formats for mailing labels. However, an addressee may have multiple addresses, and an address may have many occupants. For address data management, address and addressee should be treated as separate entities, and defined by separate standards.

1.2.4 Address Data Classification: A Syntactical Approach

The standard classifies addresses according to their syntax, that is, their address elements and the order in which the elements are arranged. Syntax determines the record structure needed to hold and exchange an address, and often it is all that is known about the addresses in a given file.

Classifying addresses by syntax rather than semantics (i.e., meaning) allows the users of the standard to focus on record structures, and to avoid the need for any assumptions about what kind of feature the address might identify. Classifying addresses by feature can be frustrating or impossible because:

1. Reliable information about an address may be unavailable.

2. Often, one address is used to identify several types of features (e.g., parcel, building, building entrance, utility meter, utility pole, incident location, etc.) at the same location.

3. A set of feature categories may be found to be ambiguous or incomplete when applied to a given address.

The Address Data Classification part of the standard classifies all US addresses into a simple, complete taxonomy of ten US address classes. Consistent with the principles of the General Information Model defined in the FGDC Framework Data Content Standard Base Part, each particular address class is a subclass of an abstract Address Class. The ten address classes are organized into three groups, plus a catch-all general class.

1.2.4.1 Thoroughfare Address Classes.

Thoroughfare addresses specify a location by reference to a thoroughfare. A thoroughfare is defined as a "road or part of a road or other access route along which a delivery point can be accessed"(UPU Publication S42-4 (sec. 5.2.9)). A thoroughfare is typically but not always a road — it may be, for example, a walkway, a railroad, or a river. The thoroughfare address classes are:

1. Numbered Thoroughfare Address ("123 Main Street") 2. Intersection Address ("Fifth Avenue and Main Street") 3. Two Number Address Range ("405-411 West Green Street") 4. Four Number Address Range ("900-962, 901-963 Milton Street") 5. Unnumbered Thoroughfare Address ("Forest Service Road 698")

1.2.4.2 Landmark Address Classes.

Landmark addresses specify a location by reference to a named landmark. A landmark is a relatively permanent feature of the manmade landscape that has recognizable identity within a particular cultural context" (definition adapted from U.S. Board on Geographic Names, 2003, p. 48).

6. Landmark Address ("Statue of Liberty") 7. Community Address ("123 Urbanizacion Los Olmos")

1.2.4.3 Postal Delivery Address Classes.

Postal delivery addresses specify points of postal delivery that have no definite relation to the location of the recipient, such as a post office box, rural route box, overseas military address, or general delivery office. The USPS specifies each class in detail in USPS Publication 28.

8. USPS Postal Delivery Box ("PO Box 16953") 9. USPS Postal Delivery Route ("RR 1, Box 100") 10. USPS General Delivery Office ("General Delivery")

1.2.4.4 General Address Class. The General Address Class is for files that hold addresses from various classes, and for addresses (such as foreign addresses) that might not fit in any of the thoroughfare, landmark, or postal delivery classes.

1.2.5 Address Data Content: Elements

The Address Data Content part of the standard names and defines the simple and complex data elements needed to construct addresses, and for each one provides, among other information, its name, definition, data type, existing standards (if any), domain of values (if any), examples, and explanatory notes; XML tag, XML model, example, and notes; and data quality measures and notes. The elements are too numerous to list here, but they cover:

· Address numbers and their components

· Street names and their components

· Subaddresses (apartments, offices, suites, etc.) and their components

· Landmark names

· Larger areas (place names, states, ZIP Codes and ZIP+4, and country names)

· USPS postal address elements (PO Boxes, rural routes, overseas military addresses, general delivery, etc.)

· USPS address lines (Delivery Line and Last Line, as specified in USPS Publication 28)

1.2.6 Address Data Content: Attributes for Documentation, Mapping and Quality Control

The Address Data Content part of the standard also defines a number of attributes needed for address documentation, mapping, and quality control. For each attribute, the standard provides the same information that is provided for the address elements. Collectively the attributes constitute record-level metadata for each address. The attributes are too numerous to list here completely, but key attributes include:

· A unique identifier for each different address, to serve as a primary key in an address database.

· Geographic coordinates and linear referencing locations.

· Lifecycle status (potential, proposed, active, retired).

· Address Class (in terms of the taxonomy described above).

· Address feature type (the type of feature located by the address, e.g., parcel, building, entrance, subaddress, infrastructure component, etc.).

· Official status (official, alias, unofficial, etc.).

· Related address identifier and type of relation (to relate, say, an alias address to its official address, or a landmark address to its equivalent thoroughfare address, or a parcel address to the tax billing address).

· The address authority that assigned the address, the dataset where it is found, and the dates the address was created and retired.

· Various attributes that describe specific elements, such as address number parity, address range type, and place name type.

1.2.7 Address Reference System: The Local Framework for Address Assignment

The Address Data Content part of the standard introduces the concept of an address reference system and defines the elements needed to compose, describe and document it. An address reference system is the framework of local rules, both spatial and non-spatial, by which new addresses are assigned and old ones checked within a specific area. It may include rules for naming streets and for assigning address numbers along them, as well as a boundary defining the area within which the rules apply. The address reference system, in turn, is important to data quality testing.

1.2.8 Address Data Quality: A Complete Suite of Data Quality Tests

The Address Data Quality part of the standard provides a complete suite of data quality tests for all address elements, attributes, and classes. These tests measure how well a given set of address records conforms to this standard and the local address reference system. The tests are developed in terms consistent with the FGDC's "Content Standard for Digital Geospatial Metadata" (FGDC 1998) and subsequent SDTS and ISO standards of spatial data quality. Each test specification includes the scope, measure, and procedure of the test; an SQL pseudocode script; and parameters for calculating anomalies as a percentage of the data set.

1.2.9 Address Data Exchange: XML Schema Document (XSD), XML, and UML

The Address Data Exchange part of the standard includes an XSD that describes the XML elements, attributes, and classes, and the rules for assembling them. It also includes a UML metamodel. The XSD provides complete, open, standard XML data exchange templates for both monolithic and transactional data exchanges. XML is well-suited for this purpose (and required by FGDC exchange standards), because it supports seamless exchange between different users, while allowing for local variations on either end.

The XSD conforms to the W3C XML Core Working Group "Extensible Markup Language (XML) 1.0" (Third Edition, W3C Recommendation 4 February 2004). Geometry elements are defined and implemented following OGC's. "OpenGIS(R) Geography Markup Language (GML)" (Version: 3.1.1). These versions were chosen to provide consistency with the FGDC's Geographic Information Framework Data Content Standard. (See Appendix A for complete references.)

1.2.10 A Data Model, but Not a Database Model

The XSD 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. The standard does not prescribe one specific design for constructing complex elements from simple elements, or addresses from their complex and simple elements. It does not specify, for example, how to relate address numbers to street names, or compose a master street name list, or geocode addresses, even though these and other tasks are crucial to the creation and maintenance of an address database.

There are many ways to accomplish these tasks. The standard accommodates a range of different design choices in composing, relating, and describing elements and addresses. The best way depends on local circumstances, rules, customs, and anomalies—and therefore cannot be prescribed in a standard. Instead, these choices are left as implementation matters to be decided locally.

1.2.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:

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

· 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 have 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.

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

1.2.12 Abbreviations in Addresses

Abbreviations are frequently used in addresses, and in particular the USPS abbreviations for street name directionals and types are widely used. However, this standard recognizes only two specific groups of abbreviations, both of which are unambiguous and used without variation:

· The two-letter abbreviations for the fifty states; the District of Columbia, US territories, possessions, and minor outlying islands; and USPS-designated overseas military and diplomatic "state" equivalents (AA, AE, AP)(see State Name element).

· Nine USPS abbreviations defined for postal delivery purposes and having no direct relation to any location (PO Box, PMB; RR, HC; PSC, CMR; APO, FPO, and DPO)(see USPS Postal Delivery Box and USPS Postal Delivery Route address classes).

No other abbreviations are recognized within the standard, for three reasons:

· The standard must serve a broad range of purposes, and no set of abbreviations is used for all those purposes. USPS abbreviations, for example, differ from emergency dispatch abbreviations and from other abbreviations in use.

· Abbreviations can create ambiguity. As an example, consider “N W Jones Tr.” Is it “Northwest Jones Tr,” “Noble Wimberly Jones Tr,” or “North William Jones Tr”? Does Tr stand for Terrace, Trail, or Trace? Abbreviations lose information about the full address, and thereby hamper data quality testing and data exchange. Time saved in data entry is lost in checking ambiguous addresses.

· Any list of standard abbreviations is bound to be incomplete. A few examples of street types missing from the most recent (2006) USPS list include: Alcove, Close, Connector, Downs, Exchange, and Promenade. In addition many applications such as 911 dispatch require specialized local abbreviations (e.g., “NCap” for North Capitol Street). Local abbreviations will not be clear to outsiders unless the complete form can be recovered from the master address record.

Therefore addresses should be stored unabbreviated in the master address record, and views or export routines should be used to meet the needs of E-911, mailing addresses, etc. If a link is preserved between the primary record and its recognized alternatives, abbreviations are unambiguously expandable when necessary -- as for instance when address information must be shared between two agencies that use different abbreviation rules.

This standard recognizes all USPS abbreviations and abbreviation rules within the Postal Addressing Profile. Additional profiles can be created if other needs warrant.

1.2.13 No Address Data Presentation Standard is Included

This standard does not specify how address data should be symbolized graphically or geographically. The appropriate representation depends on the purpose of the map creator, so no standard is warranted.

1.2.14 Language and Character Set

For English-language addresses, this standard can be implemented with the standard ASCII character set. To facilitate reproduction in the widest variety of media, the standard has been composed with the standard ASCII character set, even at the cost of simplifying the representation of certain non-English words. Other character sets, such as Unicode, are required to correctly represent addresses that use other languages. The character set should be specified in the file-level metadata for any address file.

1.3 Applicability

This standard is intended for use within and among federal, state, regional, local government agencies, nongovernmental sectors, and the general public.

1.4 Related Standards

This standard incorporates references to over 40 other standards and specifications. Appendix A (Informative) gives complete references to the standards and specifications cited, as well as to other standards and guidelines consulted in writing the standard.

This standard was written to conform to the FGDC Standards Reference Model (FGDC 1996). In the terms defined by that model, this standard is a data standard. Specifically, this standard has four parts: a data content standard (Part One), a data classification standard (Part Two), a data usability (Part Three), and a data transfer standard (Part Four). This standard does not include a data symbology or presentation standard.

This standard incorporates by reference, for address data files, the FGDC"s Content Standard for Digital Geospatial Metadata (CSDGM)(FGDC 1998). This standard extends the CSDGM by providing attributes for record-level address metadata. These attributes overlap to some extent with the CSDGM. If the values of these attributes are the same for all records in an address data file, the information can be omitted from the individual records and provided in the file-level metadata. If the values vary from record to record (e.g., in a file aggregated from multiple sources), the attributes can be included in the record-level metadata.

This standard is consistent with all parts of the FGDC's Framework Data Content Standard of the National Spatial Data Infrastructure. In particular, it conforms to all provisions of the Base part of the Framework Standard, which defines the abstract model that underlies and unifies the seven data themes. Appendix J shows this in detail. The address standard can therefore be used in conjunction with all of the National Spatal Data Infrastructure data themes. Temporary Note to Reviewers: Consistency has not been verified by all framework maintenance committees. Certain inconstencies remain between this standard and the Transportation Part (Roads and Transit). These are listed in Appendix J.2.8

USPS Publication 28, Postal Addressing Standards, is a foundational work for the Content and Classification Parts of this standard. USPS Publication 28 is the basis for the United States profile of the template and rendition instructions in the Universal Postal Union International postal address components and templates (UPU 2008). The Postal Addressing Profile establishes the relationship between the FGDC standard and USPS Publication 28. The profile restricts this standard in some ways, and extends it in other ways, to incorporate the specific rules, abbreviations, and scope limitations of USPS Publication 28. Any address record that is standardized as defined within the terms of USPS Publication 28 is also compliant with the Postal Addressing Profile and, if altered according specific procedures described therein, will conform to this standard. Temporary Note to Reviewers: As of 14 January 2010, the Postal Addressing Profile is under review by the USPS.

This standard explicitly incorporates, as the Four Number Address Range class, the TIGER/Line file structure established by the U.S. Census Bureau for street segment address ranges (U.S. Census Bureau 2008).

During the time this standard has been developed, the National Emergency Number Association (NENA) has developed the Next Generation 9-1-1 (NG9-1-1) Civic Location Data Exchange Format (CLDXF) Standard to support the exchange of United States civic location address information about 9-1-1 calls. The CLDXF is the United States profile of the Internet Engineering Task Force (IETF) Presence Information Data Format – Location Object (PIDF-LO) civicAddress type. The FGDC and NENA working groups have aligned the two standards as closely as possible within the constraints of their respective purposes. To clarify the relation between the two standards, and to facilitate and standardize the conversion of address records between FGDC conformance and CLDXF conformance, the two committees have written the Profile Reconciling the FGDC United States Thoroughfare, Landmark, and Postal Address Data Standard and the NENA Next Generation 9-1-1 (NG9-1-1) Civic Location Data Exchange Format (CLDXF) Standard. Temporary Note to Reviewers: As of 14 January 2010, the profile is under review by NENA.

The pseudocode for the data quality tests was written (with a few exceptions, all noted) using standard ISO/IEC 9075-1:2008 SQL. Spatial predicates used in the pseudocode are described in OGC's "OpenGIS Simple Features Specification for SQL" (Rev 1.1).

The XSD conforms to the W3C XML Core Working Group "Extensible Markup Language (XML) 1.0" (Third Edition, W3C Recommendation 4 February 2004). Geometry elements are defined and implemented following OGC's. "OpenGIS(R) Geography Markup Language (GML)" (Version: 3.1.1).

1.5 Standards development procedures

1.5.1 Antecedents

This standard builds on the Address Data Content Standard previously proposed by the FGDC (Public Review Draft, April 17, 2003).

1.5.2 The Address Standard Working Group (ASWG)

The FGDC efforts led the Urban and Regional Information Systems Association (URISA) to propose, with the support of the National Emergency Number Association (NENA) and the U.S. Census Bureau, the convening of an Address Standard Working Group (ASWG) to include representatives from a range of interested federal, state, regional, and local government agencies, the private sector, and professional associations. The proposal was accepted by the FGDC Standards Working Group on April 13, 2005. The ASWG has worked under the authority of the Census Bureau, which chairs the FGDC Subcommittee on Cultural and Demographic Data (SCDD).

The ASWG prepared a draft standard, which was posted for public comment in August-September of 2005. A second draft was posted for public comment in December 2005 and January 2006. Since then, the ASWG has developed the standard further, by responding to additional comments and conference discussions, drafting additional material, integrating related standards, and preparing the final version for submittal to the FGDC.

1.5.3 Standard Development Process

Because addresses are created by such decentralized processes, and because the standard must satisfy such a wide range of requirements, the ASWG has sought by a variety of means to make the development process as open and broad-based as possible. This has involved:

1.5.3.1 Fostering Broad Awareness and Participation.

The ASWG has sought by various means to make the geospatial and addressing communities aware of the development of the standard and to involve as many as possible in the effort. The ASWG invited participation from and via professional associations representing geospatial professionals, local government officials, and emergency responders, including the National Association of Counties (NACO), GITA (Geospatial Information Technology Association), the American Association of Geographers (AAG), URISA, NSGIC (National States Geographic Information Council), and NENA (National Emergency Number Association). The draft standards, when posted, were widely announced in the geospatial and standards online media. ASWG members have made numerous presentations on the standard at conferences and meetings. In addition, the ASWG has regularly briefed various federal groups, especially the FGDC and Census, about progress on the standard.

1.5.3.2 Using a Wiki Collaborative Website.

To encourage wide participation, the ASWG set up an interactive wiki web-site using free and open-source software (TWiki, from http://twiki.org/ ). Wiki software posts a draft document (in this case, the working draft of the standard) on a server and enables anyone to edit or comment on it via internet. Comments and changes, once saved, are immediately visible to all. Anyone can add comments and ideas, or join in discussions (and sometimes arguments) over various aspects of the standard.

The ASWG wiki site is open to anyone providing a name and a valid email to which to send a password. (The site is password protected only to keep out spam.) Over 400 individuals have signed up to view the site, provide comments, enter discussions and participate in the development of the standard. The wiki site has fostered discussion among widely scattered individuals, and proven useful in obtaining information and debating points of concept, practice, and actual address conditions.

1.5.3.3 Posting Drafts for Public Comment via Webform.

The ASWG posted a first draft on the standard two months after starting work, in the summer of 2005. It was posted on the URISA website, with copies available for download, and all comments were submitted via webform so that as many people as possible had access. Over 125 comments were received on this draft. A second draft was posted in December 2005, which received over 180 comments. The Committee has since made significant revisions to incorporate these comments, and to respond to issues that they raised. This is an unprecedented level of review for a standard that has not been officially submitted as a draft to FGDC. Wide early review has greatly improved the quality of the draft that will be formally submitted to FGDC, and, we hope, increased interest in reviewing the final draft.

1.5.3.4 Focusing on Practical Needs and Usefulness.

The ASWG’s purpose has been to create a standard that will be useful and used. To be useful, the standard must reflect and build on the processes of address creation, management, and use. The standard must be developed by people who understand the local business work flows that utilize addresses in a real-time environment. Therefore the ASWG has sought advice and comment from a wide range of practitioners, including among others local government GIS managers, planners, assessors, emergency responders, school district officials, election officials, software developers, data aggregators, postal officials, census geographers, and a newspaper delivery manager, to name a few.

1.6 Maintenance authority

The Census Bureau will maintain the standard under the auspices of its duties as theme lead for the FGDC Subcommittee on Cultural and Demographic Data (SCDD), ensuring that the standard is revisited on the 5-year schedule as stipulated, or updating and revising as necessary. Direct any questions to Chief, Geography Division, U.S. Bureau of the Census.

1.7 Acronyms Used in the Standard

· AIS - Address Information System (USPS)

· ALI - Automatic Location Information

· ANSI - American National Standards Institute

· APO - Army Post Office

· ASWG - Address Standard Working Group

· CASS - Coding Accuracy Support System (USPS)

· CLDXF - Civic Location Data Exchange Format (NENA NG9-1-1 CLDXF)

· CMR - Common Mail Room

· CMRA - Commercial Mail Receiving Agency

· CRS - Coordinate Reference System

· CSDGM - Content Standard for Digital Geospatial Metadata (FGDC)

· DMM - Domestic Mail Manual (USPS)

· DPO - Diplomatic Post Office

· EPSG Dataset - European Petroleum Survey Group Geodetic Parameter Dataset (OGP)

· EPA - Environmental Protection Agency

· ERD - Entity Relationship Diagram

· FGDC - Federal Geographic Data Committee

· FIPS - Federal Information Processing Standard

· FPO - Field Post Office, or Fleet Post Office

· GIS - Geographic Information System

· GML - Geography Markup Language (OGC)

· GNIS - Geographic Names Information System

· GPS - Global Positioning System

· GZD - Grid Zone Designation

· HC - Contract Delivery Service Route (formerly Highway Contract Route, and still abbreviated as HC)(USPS)

· ID - Identifier

· IETF - Internet Engineering Task Force

· INCITS L1- InterNational Committee for Information Technology Standards Technical Committee L1 (Geographic Information Systems) (accredited by ANSI)

· ISO - International Standards Organization

· ITU-T - International Telecommunications Union Telecommunication Standardization Sector

· LRM - Linear Reference Method

· LRS - Linear Reference System

· MAF - Master Address File (Census Bureau)

· MSAG - Master Street Address Guide

· MGRS - Military Grid Reference System

· NAD83 - North American Datum of 1983

· NCITS - National Committee for Information Technology Standards

· NENA - National Emergency Number Association

· NG9-1-1 - Next-Generation 9-1-1

· NSDI - National Spatial Data Infrastructure

· PIDF-LO - Presence Information Data Format - Location Object (IETF)

· OGC - Open Geospatial Consortium

· OGP - International Association of Oil and Gas Producers (the OGP Geodesy Subcommittee maintains and publishes EPSG Dataset)

· PMB - Private Mail Box

· PO Box - Post Office Box

· PSC - Postal Service Center

· RFC - Request for Comments (IETF)

· RR - Rural Route (USPS)

· SCDD - FGDC Subcommittee on Cultural and Demographic Data

· SDTS - Spatial Data Transfer Standard (FGDC and USGS)

· SWG - FGDC Standards Working Group

· TIGER - Topologically Integrated Geographic Encoding and Referencing System (Census Bureau)

· UML - Unified Modeling Language

· UPU - Universal Postal Union

· URISA - Urban and Regional Information Systems Association

· USGS - United States Geological Survey

· USNG - United States National Grid

· USPS - United States Postal Service

· UTM - Universal Transverse Mercator

· UUID - Universally Unique Identifier

· XML - Extensible Markup Language

· XSD - XML Schema Document

· ZIP Code - Zoning Improvement Plan Code (USPS)

1.8 Trademark Acknowledgements

The following trademarks are owned by the United States Postal Service: CASS™, PO Box™, U.S. Postal Service®, United States Post Office®, United States Postal Service®, USPS®, ZIP + 4®, ZIP Code™, ZIP™

The following trademark is owned by the Open Geospatial Consortium: OpenGIS®

2. Address Data Content

2.1 Purpose

The content part defines address elements, address reference system elements, and their attributes.

2.2 Organization

The address elements are presented first, grouped according to the major components of an address, followed by the address reference system elements, and lastly the attributes, which are grouped by subject.

Address Elements

· Address Number Elements

· Street Name Elements

· Subaddress Elements

· Landmark Name Elements

· Place, State, and Country Name Elements

· USPS Postal Address Elements

· USPS Address Lines

Address Reference System Elements

Attributes

· Address ID

· Address Coordinates

· Address Parcel IDs

· Address Transportation Feature IDs

· Address Range Attributes

· Address Attributes

· Element Attributes

· Address Lineage Attributes

2.3 Simple Elements, Complex Elements, and Attributes

The content part defines simple elements, complex elements, and attributes.

· Simple elements are address components or address reference system components that are defined independently of all other elements

· Complex elements are formed from two or more simple or other complex elements

· Attributes provide descriptive information, including geospatial information, about an address, an address reference system, or a specific element thereof..

Appendix B: Table of Element Relationships provides a list of all the elements, and their relations to each other.

2.4 Element and Attribute Definitions and Descriptions

Each data element is defined and described by giving its:

· Element name: The name of the element.

· Other common names for this element: Common words or phrases having the same or similar meaning as the element name. Note: * "(USPS)" indicates terms used in USPS Publication 28. * "(Census TIGER)" indicates terms found in Census TIGER\Line Shapefile documentation. * Appendix A gives complete citations for both documents.

· Definition: The meaning of the element.

· Syntax: (For complex elements only) What component elements are required or permitted to construct the element, and the order in which they must appear. (For syntax notation, see below, "Notation for Constructing Complex Elements.")

· Definition Source: The source of the definition ("New" indicates that the definition is original.)

· Data Type: Whether the element is a characterString, date, dateTime, integer, real, or geometric (point, MultiCurve, or MultiSurface) (see "Element and Attribute Data Types" below for definitions)

· Existing Standards for this Element: Other standards that govern this element (if any).

· Domain of Values for this Element: The range or set of values (if any) to which the element is restricted.

· Source of Values: The source (if any) for the domain of values.

· How Defined: How the domain of values is defined.

· Example: Illustrative examples of the element.

· Notes/Comments: Notes and comments giving further explanation about the element.

· XML Tag: The XML tag for the element.

· XML Model: XML model of the element.

· XML Example: The XML model applied to a specific example of the element.

· XML Notes: Explanatory notes about the XML model.

· Quality Measures: Quality tests applied to the class.

· Quality Notes: Explanatory notes about the quality measures applied to this element.

2.5 Element and Attribute Data Types

Elements and attributes are either non--geometric, geometric, or abstract. Non-geometric data types include characterString, date, dateTime, integer, and real. Geometric data types include point, MultiCurve, and MultiSurface. The abstract data type, as used in this standard, aggregates multiple elements of different data types, geometric and non-geometric.

The non-geometric data types are defined in the FGDC's "Framework Data Content Standard Part 0: Base Document" (section 7.8.2.2 (Table 4 - CodeList for DataType)) as follows:

1. characterString: "A CharacterString is an arbitrary-length sequence of characters including accents and special characters from repertoire of one of the adopted character sets"

2. date: "Values for year, month, and day"

3. dateTime: "A combination of year, month, and day and hour, minute, and second"

4. integer: "Any member of the set of positive whole numbers, negative whole numbers and zero"

5. real: "Real numbers are all numbers that can be written as a possibly never repeating decimal fraction"

The geometric data types are defined in the Open Geospatial Consortium's "OpenGIS(R) Geography Markup Language (GML)" version 3.1.1 (see Appendix A for a complete citation):

· Point: "...a single coordinate tuple." (Sec. 10.3.1)

· MultiCurve: "...a list of curves. The order of the elements is significant and shall be preserved..." (Sec. 11.3.3.1). (The MultiCurve replaced the MultiLinestring datatype defined in GML version 3.0)

· MultiSurface: "...a list of surfaces. The order of the elements is significant and shall be preserved..." (Sec 11.3.4.1). (The MultiSurface replaced the MultiPolygon datatype defined in GML version 3.0)

The abstract data type is defined in the FGDC's "Framework Data Content Standard Part 0: Base Document" (Annex B.2.2) as a "class, or other classifier, that cannot be directly instantiated." The abstract data type (used in this standard for the complex element Address Reference System) may aggregate multiple elements of different data types, geometric and non-geometric.

2.6 Notation for Constructing Complex Elements

The following notation is used to show how complex elements are constructed from simple or other complex elements:

{} enclose the name of an element.

* indicates that the element is required to create the complex element. Otherwise the element may be omitted when desired.

+ indicates "and" (concatenation), with a space implied between each component unless stated otherwise.

2.7 XML and GML Standard

XML models and examples conform to the W3C XML Core Working Group's "Extensible Markup Language (XML) 1.0" (see Appendix A for a complete citation). Geometry elements are defined and implemented following OGC's. "OpenGIS(R) Geography Markup Language (GML)" (Version: 3.1.1).

2.8 Address Elements

2.8.1 Address Number Elements

2.8.1.1 Address Number Prefix

Element Name

Address Number Prefix

Other common names for this element

Street Number Prefix, Building Number Prefix, House Number Prefix, Site Number Prefix, Structure Number Prefix

Definition

The portion of the Complete Address Number which precedes the Address Number itself.

Definition Source

New

Data Type

characterString

Existing Standards for this Element

None

Domain of Values for this Element

Can be created locally from existing values

Source of Values

Local

How Defined

Locally

Example

N6W2 3001 Bluemound RoadA 19 Calle 117194- 03 Fiftieth Avenue Milepost 1303 Alaska Highway

Notes/Comments

1. This element is not found in most Complete Address Numbers. When found, it should be separated from the Address Number so that the Address Number can be maintained as an integer for sorting and quality control tests. 2. Informally an Address Number and Address Number Prefix may be written with or without a space between them. Within this standard, the default assumption is that an empty space separates elements unless stated otherwise. The Attached Element can be used to indicate where the assumed space between the Address Number and Address Number Prefix has been omitted within an address file (see Attached Element for additional notes). 3. An Address Number Prefix is often separated from the Address Number by a hyphen. The hyphen may be included in the Address Number Prefix, or, alternatively, a Separator Element may be used to separate the Address Number from the Address Number Prefix in constructing the Complete Address Number (see Separator Element for additional notes). 4. Milepost numbers are often used to specify locations on limited-access roads such as interstate highways, and along highways and country roads where addressable features are too sparse to assign address numbers. Where it is useful to treat these as addresses, treat "Milepost" (or "Kilometer", in Puerto Rico) as an Address Number Prefix, and the milepost number as the Address Number.

XML Tag

XML Model

XML Example

N6W23001

A19

Quality Measures

Tabular Domain Measure Range Domain Measure Spatial Domain Measure Address Number Fishbones Measure

Quality Notes

Address number prefixes can include map-based information as grid coordinates, references to survey systems or references to sections of a subdivision or housing complex. Where a tabular domain of values are available the prefix can be tested against it. The measure chosen will depend on the type of domain involved. See the introduction to this section for a information on which measures to use.

2.8.1.2 Address Number

Element Name

AddressNumber


Street Number, Building Number, House Number, Site Number, Structure Number

Definition

The numeric identifier for a land parcel, house, building or other location along a thoroughfare or within a community.

Definition Source

New

Data Type

Integer


None


Can be created locally.

Source of Values

Local jurisdiction

Attributes Associated with this Element

Address Number Parity

How Defined

Based on local address ranges associated with individual streets and blocks.

Example

123 Main Street

Notes/Comments

1. The Address Number is defined as an integer to support address sorting, parity (even/odd) definition, and in/out of address range tests.2. The Address Number must be converted to a characterString when it is combined with the prefix and suffix into a Complete Address Number. 3. Some addresses may contain letters, fractions, hyphens, decimals and other non-integer content within the Complete Address Number. Those non-integer elements should be placed in the Address Number Prefix if they appear before the Address Number, or in the Address Number Suffix if they follow the Address Number.If necessary, the Separator Element can be used to separate the Address Number from the Address Number Prefix or Address Number Suffix elements in constructing the Complete Address Number. For example, if the New York City hyphenated address 194-03 ½ 50th Avenue, New York, NY 11365 were to be parsed rather than represented as a Complete Address Number:---the Address Number Prefix would be "194", ---the Separator Element would be "-", ---the Address Number would be 3 (converted to "03" (text) in constructing the Complete Address Number), ---and the Address Number Suffix would be "1/2". 4. Special care should be taken with records where the Address Number is 0 (zero). Occasionally zero is issued as a valid address number (e.g. Zero Prince Street, Alexandria, VA 22314) or it can be imputed (1/2 Fifth Avenue, New York, NY 10003 (for which the Address Number would be 0 and the Address Number Suffix would be "1/2")). More often, though, zero is shown because the Address Number is either missing or non-existent, and null value has been converted to zero.

XML Tag

XML Model

XML Example

1234

Quality Measures

Data Type Measure

Quality Notes

The Address Number element is specified as an integer. Data Type Measure is helpful when testing data held in staging tables with variable character fields. Additional tests for the address number require association with a street name.

2.8.1.3 Address Number Suffix

Element Name

AddressNumberSuffix


Street Number Suffix, Building Number Suffix, House Number Suffix, Fractional Street Number (USPS), Structure Number Suffix

Definition

The portion of the Complete Address Number which follows the Address Number itself.

Definition Source

New

Data Type

characterString


None



Source of Values

Local

How Defined

Locally

Example

123 1/2 Main Street121 E E StreetB317 A Calle 117 Milepost 34.4 (Address Number Suffix = decimal portion only)

Notes/Comments

1. This element is not found in most Complete Address Numbers. When found, it should be separated from the Address Number so that the Address Number can be maintained as an integer for sorting and quality control tests. 2. Informally an Address Number and Address Number Suffix may be written with or without a space between them. Within this standard, the default assumption is that an empty space separates elements unless stated otherwise. The Attached Element can be used to indicate where the assumed space between the Address Number and Address Number Suffix has been omitted within an address file (see Attached Element for additional notes). 3. An Address Number Suffix is often separated from the Address Number by a hyphen. The hyphen may be included in the Address Number Suffix, or, alternatively, a Separator Element may be used to separate the Address Number from the Address Number Suffix in constructing the Complete Address Number (see Separator Element for additional notes). 4. When milepost Complete Address Numbers include decimal fractions, the integer portion of the milepost number is treated as the Address Number, and the fraction (including the decimal point) is treated as an Address Number Suffix. (See Complete Address Number for additional notes on milepost address numbers.

XML Tag

XML Model

XML Example

1231/2

456B

317A

Quality Measures

Tabular Domain Measure Spatial Domain Measure Address Number Fishbones Measure

Quality Notes

1. Address number suffixes can include references to sections of a subdivision or housing complex. Where a tabular domain of values are available the prefix can be tested against it. 2. When geometry for both the address point and an areal Address Number Suffix are available the Spatial Domain Measure can be used to measure tests whether the addressed location is within a polygon describing a map-based Address Number Suffix. 3. Use Address Number Fishbones Measure when geometry for both the address point and a linear spatial domain for Address Number Suffix are available. This measure tests whether the addressed location is along a line describing a map-based Address Number Suffix.

2.8.1.4 Separator Element

Element Name

Separator Element


Definition

A symbol, word, or phrase used as a separator between components of a complex element or class. The separator is required for Intersection Addresses and for Two Number Address Ranges, and it may be used in constructing a Complete Street Name or a Complete Address Number.

Definition Source

New

Data Type

characterString


None


Typical values may include: 1. For Intersection Addresses: "and", "at", "@", "&", and "&&" "+","-", and "y" or "con" (Spanish) each having a space before and after. 2. For Two Number Address Ranges: - (hyphen)(spaces optional before or after) 3. If a Complete Street Name includes a prepositional phrase between the between a Street Name Pre Type and a Street Name, the prepositional phrase is treated as a separator: "of the", "de la", "des", etc. 4. Complete Address Numbers: - (hyphen)(spaces optional before or after)

Source of Values

New

How Defined (e.g., locally, from standard, other)

Locally.

Example

1. Intersection Address ("and"): Eighth Street and Pine Street. 2. Two Number Address Range (hyphen): 206-210 Fourth Street 3. Prepositional phrase between the Street Name Pre Type and the Street Name:("of the", "de las" and "des") Avenue of the Americas, Alameda de las Pulgas; Rue des Fleurs. 4. Complete Address Number (hyphen): 61-43 Springfield Boulevard

Notes/Comments

1. The default separator, an empty space, is implicit and is not shown in the syntaxes of complex elements and classes. 2. An explicit separator is required for Two Number Address Ranges and Intersection Addresses. It is sometimes required in constructing Complete Street Names. 3. For Complete Address Numbers, the separator is rarely needed and its use should be minimized. As an alternative, the separator symbol usually can be included with the Address Number Prefix or Address Number Suffix. 4. The Separator Element is not needed in creating fractions (1/2, etc.) for Address Number Suffixes. 5. Within a given dataset, one value should be used consistently within a given complex element.6. Some address parsing software permits the use of ampersands ("&" or "&&") to signify intersection addresses. Be wary, though--in many programming languages, ampersands are reserved for other uses, which could complicate data exchange.

XML Tag

Separator

XML Model:

XML Example:

EIGHTHSTREETPINESTREETELLICOT CITYMD21043

206210

AVENUEAMERICAS

ALAMEDAPULGAS

6143

XML Notes:

This entity must be expressed as an empty string to indicate an empty string. Omitting the entity entirely indicates that a space is acceptable.

Quality Measures

Tabular Domain Measure

Quality Notes

If Separator Element entries are maintained within a database, rather than generated as part of a query, they may be tested with Tabular Domain Measure. Their use depends on other elements, and is tested at the classification level.

2.8.1.5 Complex Element: Complete Address Number

Element Name

Complete Address Number


Complete street number, full street number, Primary Address Number (USPS), Street Number (USPS), House Number (USPS, Census TIGER))

Definition

An Address Number, alone or with an Address Number Prefix and/or Address Number Suffix, that identifies a location along a thoroughfare or within a community.

Syntax

{ Address Number Prefix } + { Separator Element } + { Address Number *} + { Separator Element } + { Address Number Suffix }

Definition Source

New

Data Type

characterString


Refer to component simple elements



Source of Values


How Defined (e.g., locally, from standard, other)


Example

123 Main Street 123 A Main Street123 1/2 Main Street A 19 Calle 117 0 Prince Street 0 1/2 Fifth Avenue Milepost 240 Parks Highway Alaska Milepost 72.9 Interstate 84, Wasco County, OR Kilometer 0.5 Carretera 917, Urbanizacion April Gardens, Las Piedras PR 00771 Kilometer 2 Hectometer 7 Carretera 175, Barrio San Antonio, Caguas, Puerto Rico 00725 N89W16758 Appleton Avenue, Menomonee Falls, WI 53051 W63N645 Washington Avenue, Cedarburg, WI 53012 5-5415 Kuhio Highway, Hanalei, HI 96714 194-03 1/2 50th Avenue, New York, NY 11365

Notes/Comments

1. The Address Number element is required to compose a Complete Address Number. The other elements are optional. 2. The Address Number must be converted from integer to characterString when constructing the Complete Address Number. 3. The great majority of Complete Address Numbers are simple integers. Infrequently the integer is followed by an alphanumeric Address Number Suffix, typically a letter or a fraction. Even more rarely the integer is preceded by an alphanumeric Address Number Prefix. In addition to the typical numbering format, four special-case formats are found in the United States: Milepost addresses, grid-style address numbers, hyphenated address numbers, and other Address Number Prefix letters or symbols. 4. Milepost Complete Address Numbers. Road mileposts are sometimes used to specify locations along highways and similar roads. Mileposts are often used to locate, for example, crash sites, emergency call boxes, bridge locations, inspection stations, roadside rest stops, railroad crossings, highway exits, park and campground entrances, RV parks, and truck stops. Milepost addresses should be parsed as follows: ---"Milepost" (or equivalent word or phrase, such as "kilometer" or 'Mile Marker") is an Address Number Prefix ---The milepost number (integer part only) is an Address Number ---Tenths, if given, are an Address Number Suffix, including the decimal point. ---The road name or highway route number is a Complete Street Name, and parsed accordingly Note that, in Puerto Rico, road measurements are given in kilometers (km), which are sometimes divided into hectometers (hm). 5. Grid-style Complete Address Numbers. In certain communities in and around southern Wisconsin, Complete Address Numbers include a map grid cell reference preceding the Address Number. In the examples above, "N89W16758" should be read as "North 89, West 167, Address Number 58". "W63N645" should be read as "West 63, North, Address Number 645." The north and west values specify a locally-defined map grid cell with which the address is located. Local knowledge is needed to know when the grid reference stops and the Address Number begins. 6. Hyphenated Complete Address Numbers. In some areas (notably certain parts of New York City, southern California, and Hawaii), Complete Address Numbers often include hyphens. Hyphenated Complete Address Numbers should not be confused with Two Number Address Ranges. The former is a single Complete Address Number while the latter includes two Complete Address Numbers. 7. Hyphenated Complete Address Numbers can be parsed so that the number indicating the site or structure is the Address Number, and the remainder (including the hyphen) is the Address Number Prefix or Address Number Suffix. If necessary, the hyphen can be parsed as a Separator Element, to separate it from both the Address Number and the Address Number Prefix or Address Number Suffix. However, the Separator Element is rarely needed and its use should be minimized in constructing Complete Address Numbers. 8. In New York City, hyphenated Complete Address Numbers (the recommended format for storing complete address numbers in New York City) follow a more complex set of rules. The number to the left of the hyphen indicates the "block" (conceptually--the number does not always change at street intersections and sometimes it changes within a single block face). The number to the right of the hyphen indicates the site or house number within the "block". If the Address Number is less than ten, it is written with a leading zero, as in 194-03 1/2 above. Additional leading zeros may be added to either number to provide for correct sorting if the entire Complete Address Number is treated as a characterString with the hyphen included. Within the address standard, these numbers can be constructed and parsed as follows: a. The left-side number (194)) is the Address Number Prefix element (text), with leading zeros shown as needed. b. The hyphen is a Separator Element with no spaces inserted before or after the hyphen when constructing the Complete Address Number. c. The right-side number (3) is the Address Number (integer), converted to a characterString with leading the zero(s) added (03) upon conversion to Complete Address Number. d. The suffix, if any (such as the "1/2" in 194-03 1/2), is an Address Number Suffix. 9. Other Address Number Prefix Letters or Symbols. In Puerto Rico, Address Numbers are commonly preceded by an Address Number Prefix letter (e.g. "A 19"). In Portland, OR, negative Address Numbers have been assigned in an area along the west bank of the Willamette River. The minus sign is represented as a leading zero ("0121" and "121" are two different Complete Address Numbers). In such cases the leading zero should be treated as an Address Number Prefix. 10. Zero as a Complete Address Number. Special care should be taken with records where the Address Number is 0 (zero). Occasionally zero is issued as a valid address number (e.g. 0 Prince Street, Alexandria, VA 22314) or it can be imputed (1/2 Fifth Avenue, New York, NY 10003, for which the Address Number would be 0 and the Address Number Suffix would be "1/2"). More often, though, the Address Number is either missing or non-existent, and null value has been converted to zero.

XML Tag

XML Model

XML Exmample

551/2

MILEPOST72.9

Quality Measures

Pattern Sequence Measure

Quality Notes

2.8.2 Street Name Elements

2.8.2.1 Street Name Pre Modifier

Element Name

Street Name Pre Modifier


Prefix Qualifier (Census TIGER)

Definition

A word or phrase that precedes the Street Name and is not a Street Name Pre Directional or a Street Name Pre Type.

Definition Source

New

Data Type

characterString


No



Source of Values

Local

How Defined

Locally

Example

Old North First Street The Croft Lane

Notes/Comments

1. Census Bureau TIGER Technical Documentation (Appendix D) provides the following list of Street Name Pre Modifiers: Alternate, Business, Bypass, Extended, Historic, Loop, Old, Private, Public, Spur 2. Parsing rules allow some flexibility in deciding whether a Complete Street Name includes a Street Name Pre Modifier. In each of the examples above, for instance, the entire name could be treated as the Street Name element. If the Complete Street Name is parsed into components, the Street Name Pre Modifier provides a way to handle words that precede the Street Name and should be separated from it, or that are separated from the Street Name by a Street Name Pre Directional or a Street Name Pre Type. See Complete Street Name notes for a general discussion of Complete Street Name parsing principles.

XML Tag

XML Model

XML Example

OLDFIRSTSTREETSOUTHWEST

Quality Measures

Tabular Domain Measure Spatial Domain Measure

Quality Notes

1. Where a specific set of premodifiers are specified for use, they may be maintained as a domain and tested with Tabular Domain Measure. 2. Where a schema may designate a particular area with a Street Name Pre Modifier the entries may be tested with Spatial Domain Measure.

2.8.2.2 Street Name Pre Directional

Element Name

Street Name Pre Directional


Predirectional (USPS), Prefix Direction (Census TIGER), Prefix Directional, Predir

Definition

A word preceding the street name that indicates the directional taken by the thoroughfare from an arbitrary starting point, or the sector where it is located.

Definition Source

New

Data Type

characterString


USPS Publication 28 Section 233 and 294


English: East, West, South, North, Northeast, Southeast, Southwest, Northwest Spanish: Este, Oeste, Sur, Norte; Noreste, Sureste, Suroeste, Noroeste Equivalent words in other languages

Source of Values

USPS Publication 28 Sections 233 and 294 (unabbreviated)

How Defined

As provided by USPS Publication 28 Section 233 and 294

Example

123 North Main Street 123 West North Street North Avenue (directional word is the Street Name) South Carolina Avenue (directional word is part of the Street Name)

Notes/Comments

1. USPS Publication 28 recommends abbreviating pre-directionals. The Standard requires storing pre-directionals fully spelled out, exactly as given by the local naming authority, to avoid confusion. For example: "N W Jones St": Is it Northwest Jones Street? Ned Walter Jones Street? North Walter Jones Street? The abbreviations create ambiguity. If stored unabbreviated, directionals can be exported as standard abbreviations as needed for mailing and other purposes. 2. USPS standard abbreviations are recognized within the Postal Addressing Profile of this standard. USPS Publication 28 sections 233, 294, and Appendix B provide the USPS abbreviations for directionals in English and Spanish. 3. Directional words are often used as or in the Street Name (e.g. North Avenue, West Virginia Avenue). The proper parsing must be inferred from the syntax and context of the street name. (For example, does West Virginia Avenue at some point change names and become East Virginia Avenue? Then perhaps "Virginia" is the Street Name, and East and West are Street Name Pre Directionals.) See Complete Street Name for a general discussion of street name parsing principles. 4. USPS Publication 28 (paraphrased to omit reference to abbreviations): "233.21 Predirectional Field -- When parsing the address from right to left, if a directional word is found as the first word in the street name and there is no other directional to the left of it, ...locate it in the predirectional field..." 5. See Street Name Post Directional for additional USPS Publication 28 notes that also apply to this element.

XML Tag

XML Model

XML Example

NORTHMAINSTREET

Quality Measures


Quality Notes

1. Tabular Domain Measure can test entries against a tabular domain. 2. In cases where an address scheme designates particular areas as corresponding with a given Street Name Pre Directional and the geometry for both the streets and the address scheme's spatial domain, Tabular Domain Measure can test the entries.

2.8.2.3 Street Name Pre Type

Element Name

Street Name Pre Type


Prefix type (Census TIGER), Street prefix type, Pre-type

Definition

The element of the complete street name preceding the street name element that indicates the type of street.

Definition Source

New

Data Type

characterString


None (Appendix C1 of USPS Publication 28 provides a useful list of Street Suffixes, but does not recognize their use for Street Name Pre Types)


Yes. Although not recognized as Street Name Pre Types, Appendix C1 of USPS Publication 28 contains a useful list of Street Suffixes. Development of a list of Street Name Pre Types can incorporate Street Suffixes from USPS Publication 28 Appendix C1 with local additions.

Source of Values

Although not recognized as Street Name Pre Types, Section 234 and Appendix C of USPS Publication 28 contains a useful list of Street Types. Development of a list of Street Name Pre Types can incorporate Street Types from USPS Publication 28 with local additions.

How Defined

By local addressing authority.

Example

Avenue A Calle Aurora Avenue of the Americas Avenue at Port Imperial Alameda de las Pulgas Rue d' ArmourAvenue C Loop

Notes/Comments

1. Street Name Pre Types are recognized in this standard but not in USPS Publication 28. Within USPS Publication 28, Street Name Pre Types are combined into the USPS Primary Street Name. This practice is not recommended by the Address Standard as it complicates quality assurance testing of street names. USPS Publication 28 provides the most complete list of Street Suffixes, but it is not exhaustive. 2. USPS Publication 28 provides a standard list of street type abbreviations in Appendix C1 and Appendix H, and recommends their use. The Address Standard requires storing Street Name Pre Types and Street Name Post Types fully spelled out, exactly as given by the local naming authority, to avoid confusion. If stored unabbreviated, they can be exported as standard abbreviations as needed for mailing and other purposes. USPS Abbreviations are recognized within the Postal Addressing Profile of this standard. 3. Street Name Pre Types are much less common than Street Name Post Types in English. Street Name Pre Types are much more common in Spanish-, French-, and Italian-language street names. 4. If a prepositional phrase appears between the Street Name Pre Type and the Street Name, the prepositional phrase is considered a Separator Element: Avenue of the Americas, Alameda de las Pulgas. Such constructions are rare in English-language Complete Street Names, but they are common in Spanish, Italian and French. 5. A Complete Street Name usually includes either a Street Name Pre Type or a Street Name Post Type. Occasional Complete Street Names have neither ("Broadway") or both ("Avenue C Loop"). Parsing rules should be consistently applied. For example, if a jurisdiction parses "Avenue C" as a Street Name Pre Type plus a Street Name, then "Avenue C Loop" should be parsed as a Street Name Pre Type, Street Name, and Street Name Post Type. 6. See Complete Street Name notes for a general discussion of Complete Street Name parsing principles.

XML Tag

XML Model

XML Example

AVENUECLOOP

Quality Measures


Quality Notes

1. Tabular Domain Measure can test entries against a tabular domain. 2. In cases where an Address Reference System designates particular areas as corresponding with a given Street Name Pre Type and the geometry for both the streets and the address scheme's spatial domain, Tabular Domain Measure can test the entries. 3. In some cases a jurisdiction may have associated specific Street Name Pre Type entries with functional aspects of the road that require additional local quality measures. For example, a court may be required to be a dead end, or a boulevard limited to streets divided by a median. While these associations are beyond the scope of the standard they should be considered in planning a quality program for local addresses.

2.8.2.4.Street Name

Element Name

Street Name


Primary Street Name, Base Name (Census TIGER)

Definition

Official name of a street as assigned by a local governing authority, or an alternate (alias) name that is used and recognized, excluding street types, directionals, and modifiers.

Definition Source

Adapted from FGDC Draft Address Data Content Standard v. 3 (citing Census)

Data Type

characterString


Section 232 of USPS Publication 28


Official list of street names maintained by local authority.

Source of Values

Local

How Defined

Defined by local ordinance

Example

Central Street Southwest MacIntyre Drive Boston-Providence Highway Third Avenue 3rd Avenue

Notes/Comments

1. Domain of Values: Each jurisdiction should establish its own list of street names and use it as a domain of values to validate addresses. Alternate and Official names are distinguished by the Official Status attribute.

2. Use of Alternate or Alias Names: If alternate or abbreviated versions of street names are needed for a specialized purpose such as mailing or emergency dispatch, they can be created in views or export routines.

3. Spelling Consistency: Internal Capitalization, Apostrophes, Hyphens, Spaces Local addressing authorities are urged to follow consistent internal street naming practices, and to resolve internal street name inconsistencies, especially for internal capitalization ("McIntyre" or "Mcintyre" ?), hyphens, and apostrophes. Example: MacIntyre, McIntyre, Mc Intyre, Mcintyre Example: Smiths Lane, Smith’s Lane Example: Boston Providence Highway; Boston-Providence Highway; Rule: Follow the spelling adopted by the local street naming authority. Discussion: This standard cannot specify local naming conventions.

4. Numbered Streets Examples: Third Street, 3rd Street, 3 Street Rule: Use the name exactly as given by the local street naming authority. Discussion: This standard cannot specify local naming conventions. Different jurisdictions follow different practices for numbered street names. Pittsburgh spells out “First” through “Twelfth” and uses ordinal numbers (“13th”, 14th, etc.) for higher numbers. Washington DC uses ordinal numbers only (1st, 2nd, etc.). Other jurisdictions have their own conventions. This is a matter for local authorities to decide.

5. Parsing Ambiguous Complete Street Names: Some Complete Street Names can be parsed in more than one way. For example: -- County Road 88 or County Road 88 -- East River Avenue or East River Avenue -- The Croft Lane or The Croft Lane -- Boulevard of the Allies or Boulevard of the Allies

This standard accommodates any of the above choices. As a matter of guidance local authorities may prefer to parse the Complete Street Name so that the Street Name element can be used to create a sorted alphanumeric list of names. By this principle the first set of parsings would give the following sorted list: -- Boulevard of the Allies -- County Road 88 -- East River Avenue -- The Croft Lane

The second set of parsings would give a different list: -- 88, County Road -- Allies, Boulevard of the -- Croft Lane, The -- River Avenue, East

6. Additional Discussion of Street Name Parsing: See Complete Street Name for a general discussion of street name parsing principles.

XML Tag

XML Model

XML Example

CENTRALSTREETSOUTHWEST

BOSTON-PROVIDENCEHIGHWAY

Quality Measures


Quality Notes

In some cases a jurisdiction may have associated a given area with a type of street name: alpha characters, trees, flowers, birds, etc. Where such a scheme exists, along with the geometry for both the streets and the spatial domain, Spatial Domain Measure can be used to test conformance.

2.8.2.5 Street Name Post Type

Element Name

Street Name Post Type


Street Type, Street Suffix, Street Suffix Type, Suffix (USPS), Suffix Type (Census TIGER)

Definition

The element of the complete street name following the street name element that indicates the type of street.

Definition Source

New

Data Type

characterString


Section 234 and Appendix C of USPS Publication 28 with provision for local additions


USPS Publication 28 Appendix C with provisions for local additions.

Source of Values

Section 234 and Appendix C of USPS Publication 28 with provision for local additions.

How Defined

Locally

Example

123 Central Street Southwest 123 MacIntyre Drive 123 Boston-Providence Highway 123 Third Avenue 123 3rd Avenue Avenue C Loop

Notes/Comments

1. USPS Publication 28 provides the most complete list of Street Name Post Types, but it is not exhaustive. Where a Street Name Post Type is not included in USPS Publication 28, the USPS requires that it be incorporated into the Street Name. This standard does not recommend following this practice. 2. USPS Publication 28 provides a standard list of street type abbreviations in Appendix C1 and Appendix H, and recommends their use. The Address Standard recommends storing Street Name Post Types fully spelled out, exactly as given by the local naming authority, to avoid confusion. If stored unabbreviated, they can be exported as standard abbreviations as needed for mailing and other purposes. USPS Abbreviations are recognized within the Postal Addressing Profile of this standard. 3. A Complete Street Name usually includes either a Street Name Pre Type or a Street Name Post Type. Occasional Complete Street Names have neither ("Broadway") or both ("Avenue C Loop"). Parsing rules should be consistently applied. For example, if a jurisdiction parses "Avenue C" as a Street Name Pre Type plus a Street Name, then "Avenue C Loop" should be parsed as a Street Name Pre Type, Street Name, and Street Name Post Type. 5. See Complete Street Name notes for a general discussion of Complete Street Name parsing principles.

XML Tag

XML Model

XML Example

BOSTON-PROVIDENCEHIGHWAY

AVENUECLOOP

Quality Measures


Quality Notes

1. Tabular Domain Measure can test entries against a tabular domain. 2. In cases where an Address Reference System designates particular areas as corresponding with a given Street Name Post Type and the geometry for both the streets and the address scheme's spatial domain, Tabular Domain Measure can test the entries. 3. In some cases a jurisdiction may have associated specific Street Name Post Type entries with functional aspects of the road that require additional local quality measures. For example, a court may be required to be a dead end, or a boulevard limited to streets divided by a median. While these associations are beyond the scope of the standard they should be considered in planning a quality program for local addresses.

2.8.2.6 Street Name Post Directional

Element Name

Street Name Post Directional


Postdirectional (USPS), Post Directional, Post-direction, Postdir, Suffix Directional, Suffix Direction (Census TIGER)

Definition

A word following the street name that indicates the directional taken by the thoroughfare from an arbitrary starting point, or the sector where it is located.

Definition Source

New

Data Type

characterString


USPS Publication 28 Sections 233, 294 and Appendix B


English: East, West, South, North, Northeast, Southeast, Southwest, Northwest Spanish: Este, Oeste, Sur, Norte; Noreste, Sureste, Suroeste, Noroeste Equivalent words in other languages

Source of Values

USPS Publication 28 Sections 233, 294 and Appendix B (unabbreviated)

How Defined

As provided by USPS Publication 28 Sections 233, 294 and Appendix B

Examples

Cherry Street North North Avenue West

Notes/Comments

1. USPS Publication 28 recommends abbreviating post-directionals. The Standard requires storing post-directionals fully spelled out, exactly as given by the local naming authority, to avoid confusion. For example: "N Avenue W"-- Is it "North Avenue W"? "N Avenue West"? "North Avenue West"? The abbreviations create ambiguity. If stored unabbreviated, directionals can be exported as standard abbreviations as needed for mailing and other purposes.2. USPS standard abbreviations are recognized within the Postal Addressing Profile of this standard. USPS Publication 28 sections 233, 294, and Appendix B provide the USPS abbreviations for directionals in English and Spanish.

3. USPS Publication 28 Notes (paraphrased to omit reference to abbreviations):

* "233.22 Postdirectional Field -- When parsing from right to left, if a directional word is located to the right of the street name and suffix, ..locate it in the postdirectional field. "

* "233.23 Two Directionals -- When two directional words appear consecutively as one or two words, before the street name or following the street name or suffix, then the two words become either the pre- or the post-directionals. Exceptions are any combinations of NORTH-SOUTH or EAST-WEST as consecutive words. In these cases the second directional becomes part of the primary name and is spelled out completely in the street name element.

* "233.23 (Other Exception) The other exception is when the local address information unit has determined that one of the directional letters (N, E, W, S) is used as an alphabet indicator and not as a directional."

* "233.3 Directional as Part of Street Name -- If the directional word appears between the street name and the street type, then it should be considered part of the primary name and spelled out in that element. --Example: 12334 NORTH AVENUE (street name is "North"), --Example: 1234 WILD WEST STREET SOUTH (Street Name is "Wild West", "South" is a post-directional.)

* "233.3 (Alphabetical Indicators) -- The exception is when the local AIS unit has determined that the letters (E, N, S, or W) are used as alphabet indicators and not as directionals [abbreviations]

fgdc document number€¦ · web viewaddress feature type (the type of feature located by the...

Documents