Search the Address Standard



Address Attributes

Element Name Address Anomaly Status
Other common names for this element
Definition A status flag, or an explanatory note, for an address that is not correct according to the Address Reference System that governs it, but is nonetheless a valid address.
Definition Source New
Data Type characterString
Existing Standards for this Element No
Domain of Values? May be "yes" or "no", or may be an enumerated domain of anomaly types
How Defined (eg, locally, from standard, other) Locally
Example An address that has an even Address Number Parity but is located on the odd-numbered side of the street.
Notes/Comments This field may be used to identify the type of anomaly (e.g. wrong parity, out of sequence, out of range, etc.) rather than simply whether or not it is anomalous. Local jurisdictions may create specific categories for anomalies.
XML Tag < 
AddressAnomalyStatus
>
XML Model <xsd:simpleType id="AddressAnomalyStatus_type">
<xsd:restriction base="xsd:string"></xsd:restriction>
</xsd:simpleType>
XML Example <AddressAnomalyStatus>yes</AddressAnomalyStatus>
Quality Measures Tabular Domain Measure
Quality Notes Validation tests for conditions described Address Anomaly Status values are entirely dependent on local conditions, and are beyond the scope of this standard. Some of the measures described in the standards may provide complete or partial solutions.
Element Name AddressAuthority
Other common names for this element
Definition The name of the authority (e.g., municipality, county) that created or has jurisdiction over the creation, alteration, or retirement of an address
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element None
Source of Values None
How Defined (eg, locally, from standard, other) Locally
Example 1. Florence County, SC
2. City of Boulder, CO
3. University of Georgia, Athens, GA (for addresses within the campus)
4. Hartsfield-Jackson International Airport, Clayton County, GA (for addresses within the airport)
5. Bolling Air Force Base, Washington, DC (for addresses within the base)
Notes/Comments 1. The Address Authority is the agency responsible for assigning and administering addresses in a given area.
2. The Address Authority is also responsible for providing unique Address IDs for the addresses it administers. Thus the Address Authority name plus the ID in combination are likely to be unique nationwide.
3. The Address Authority may or may not be the same as the municipal or postal jurisdiction noted for the address. In a given area, there may be multiple authorities, a single authority or no known authority with jurisdiction over address assignment. For example, a state agency may be the Address Authority for a university campus within the municipal boundaries of a city.
4. Contact information for Address Authority will be found in the dataset metadata.
XML Tag < 
AddressAuthority
>
XML Model <xsd:simpleType id="AddressAuthority_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressAuthority>City of Boulder, CO</AddressAuthority>
<AddressAuthority>University of Georgia, Athens, GA</AddressAuthority>
Quality Measures TabularDomainMeasure
SpatialDomainMeasure
Quality Notes
Element Name AddressClassification
Other common names for this element Address Type, Address Class
Definition The class of the address as defined in the Classification Part of this standard.
Definition Source New
Data Type characterString
Existing Standards for this Element The Classification Part of this standard.
Domain of Values for this Element Class names given in the Classification Part of this standard.
Source of Values The Classification Part of this standard.
How Defined (eg, locally, from standard, other) In the Classification Part of this standard.
Examples Numbered Thoroughfare Address
Intersection Address
Two Number Address Range
Four Number Address Range
Unnumbered Thoroughfare Address
Landmark Address
Community Address
USPSPostal Delivery Box
USPSPostal Delivery Route
USPSGeneral Delivery Office
General Address Class
Notes/Comments Address classes are defined and described in the Classification part of this standard.
XML Tag < 
AddressClassification
>
XML Model <xsd:simpleType id="AddressClassification_type">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="NumberedThoroughfareAddress"></xsd:enumeration>
<xsd:enumeration value="IntersectionAddress"></xsd:enumeration>
<xsd:enumeration value="TwoNumberAddressRange"></xsd:enumeration>
<xsd:enumeration value="FourNumberAddressRange"></xsd:enumeration>
<xsd:enumeration value="UnnumberedThoroughfareAddress"></xsd:enumeration>
<xsd:enumeration value="LandmarkAddress"></xsd:enumeration>
<xsd:enumeration value="CommunityAddress"></xsd:enumeration>
<xsd:enumeration value="USPSPostalDeliveryBox"></xsd:enumeration>
<xsd:enumeration value="USPSPostalDeliveryRoute"></xsd:enumeration>
<xsd:enumeration value="USPSGeneralDeliveryOffice"></xsd:enumeration>
<xsd:enumeration value="GeneralAddressClass"></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressClassification>IntersectionAddress<AddressClassification>
Quality Measures Tabular Domain Measure
Pattern Sequence Measure
Quality Notes The Tabular Domain Measure checks on whether a classification entry actually exists. The Pattern Sequence Measure can be used to check whether the entry associated with the classification matches its description.
Element Name AddressCoordinateReferenceSystemAuthority
Other common names for this element Spatial Reference System Authority
Definition The Authority that assigns the unique Address Coordinate Reference System ID (number or name) to the Address Coordinate Reference System to which the Address XCoordinate and Address YCoordinate, Address Latitude and Address Longitude, USNational Grid Coordinate, or Address Elevation are referenced.
Definition Source New.
Data Type characterString
Existing Standards for this Element No
Domain of Values for this Element None
Source of Values New
How Defined (eg, locally, from standard, other) Authority name defined by creator of base map
Examples 1. EPSG Geodetic Parameter Dataset
2. Wisconsin State Cartographers Office
Notes/Comments 1. Coordinate values specify a location by reference to a grid, spheroid, or geoid. A coordinate location cannot be determined without knowledge of the coordinate reference system (CRS) by which the specific coordinate values are defined. The CRS itself is defined by a set of geodetic parameters. The parameters vary according to the type of CRS, but may include, for example, datum, unit of measure, or projection. When the CRS and its geodetic parameters are known, the address location can be determined unambiguously from its coordinates.
2. The Address Coordinate Reference System Authority, combined with the Address Coordinate Reference System ID in the complex element Address Coordinate Reference System, identifies the CRS to which the Address XCoordinate and Address YCoordinate, Address Latitude, Address Longitude, USNational Grid Coordinate, or Address Elevation values are referenced. The Address Coordinate Reference System Authority and the Address Coordinate Reference System ID should refer interested persons to an authoritative source where the geodetic parameters can be found, or else complete reference information should be provided in the file-level metadata.
3. The EPSG Geodetic Parameter Dataset, maintained and published by the Geodesy Subcommittee of the International Association of Oil and Gas Producers (OGP), is an extensive, authoritative, and public compilation of CRS, the geodetic parameters that define them, and conversion and transformation operations that allow coordinates to be changed from one CRS to another. Within the EPSG dataset, each CRS is identified by a COORD_REF_SYS_CODE. Although it is extensive, the EPSG dataset is not exhaustive. The OGC states, "The geographic coverage of the data is worldwide, but it is stressed that the dataset does not and cannot record all possible geodetic parameters in use around the world."
4. For examples of CRS not included in the EPSG dataset, see the Wisconsin State Cartographers Office's "Wisconsin Coordinate Systems." This publication gives the projection parameters and associated information for the Wisconsin Coordinate Reference Systems used by each of Wisconsin's 72 counties, identified by county name. The EPSG Dataset includes parameters for various versions of the Wisconsn State Plane Coordinate System, but not for each county CRS.
5. If all coordinate values in a dataset are referenced to the same CRS, the CRS should be described in the dataset-level metadata per FGDC's Content Standard for Digital Geospatial Metadata. The Address Coordinate Reference System Authority and Address Coordinate Reference System ID may then be omitted from the individual address records.
6. If the address data set includes Address XCoordinate and Address YCoordinate, Address Latitude, Address Longitude, or Address Elevation values based on more than one CRS, each address record should include the Address Coordinate Reference System Authority and Address Coordinate Reference System ID to show which system applies to each value.
7. EPSG Guidance Note 7-1 ("Using the EPSG Geodetic Prameter Dataset") provides a clear, concise explanation of the concepts underlying coordinate reference systems, and of the EPSG dataset and its use. EPSG Guidance Note 7-1 can be found at www.epsg.org under "Guidance notes" or "Geodetic dataset".
8. The Wisconsin State Cartographers Office publication also includes a concise, clear explanation of the concepts underlying CRS.
XML Tag < 
AddressCoordinateReferenceSystemAuthority
>
XML Model <xsd:simpleType id="AddressCoordinateReferenceSystemAuthority_type">
<xsd:restriction base="xsd:string" />
</xsd:simpleType>
XML Example <AddressCoordinateReferenceSystem>
<AddressCoordinateReferenceSystemAuthority>EPSG Geodetic aParameter Dataset </AddressCoordinateReferenceSystemAuthority>
<AddressCoordinateReferenceSystemID>2893</AddressCoordinateReferenceSystemID>
</AddressCoordinateReferenceSystem>
Quality Measure Tabular Domain Measure
Quality Notes
Element Name AddressCoordinateReferenceSystem
Other common names for this element
Definition { Address Coordinate Reference System Authority* } + { Address Coordinate Reference System ID* }
Data Type characterString
Existing Standards for this Element No
Domain of Values for this Element No
Source of Values
How Defined (eg, locally, from standard, other) From base mapping
Example EPSG:12349
Notes/Comments The Address Coordinate Reference System combines the Address Coordinate Reference System Authority and the Address Coordinate Reference System ID. Together they form a unique identifier for any coordinate reference system that might define the coordinate values associated with an address, whether an Address XCoordinate, Address YCoordinate, Address Latitude, Address Longitude, or Address Elevation
XML Tag < 
AddressCoordinateReferenceSystem
>
XML Model <xsd:complexType id="AddressCoordinateReferenceSystem_type">
<xsd:sequence>
<xsd:element id="AddressCoordinateReferenceSystemAuthority" type="AddressCoordinateReferenceSystemAuthority_type" />
<xsd:element id="AddressCoordinateReferenceSystemID" type="AddressCoordinateReferenceSystemID_type"></xsd:element>
</xsd:sequence>
</xsd:complexType>
XML Example <AddressCoordinateReferenceSystem>
<AddressCoordinateReferenceSystemAuthority>EPSG Geodetic Parameter Dataset </AddressCoordinateReferenceSystemAuthority>
<AddressCoordinateReferenceSystemID>2893</AddressCoordinateReferenceSystemID>
</AddressCoordinateReferenceSystem>
QualityMeasures Pattern Sequence Measure
QualityNotes
Element Name AddressCoordinateReferenceSystemID
Other common names for this element Spatial Reference ID (SRID)
Definition A name or number which, along with the Address Coordinate Reference System Authority, identifies the coordinate reference system to which Address XCoordinate and Address YCoordinate. Address Latitude and Address Longitude, USNational Grid Coordinate, or Address Elevation values are referenced.
Definition Source New
Data Type Integer
Existing Standards for this Element Yes
Domain of Values for this Element May be defined by the Address Coordinate Reference System Authority.
Source of Values Address Coordinate Reference System Authority.
How Defined (eg, locally, from standard, other) Address Coordinate Reference System Authority.
Example EPSG 2893
Wisconsin State Cartographers Office, "Dane County Coordinate System"
Notes/Comments 1. A coordinate location cannot be determined without knowledge of the coordinate reference system (CRS) by which the specific coordinate values are defined. The CRS itself is defined by a set of geodetic parameters. The parameters vary according to the type of CRS, but may include, for example, datum, unit of measure, or projection. When the CRS and its geodetic parameters are known, the address location can be determined unambiguously from its coordinates.
2. The Address Coordinate Reference System ID, combined with the Address Coordinate Reference System Authority in the complex element Address Coordinate Reference System, identifies the CRS to which the Address XCoordinate and Address YCoordinate, Address Latitude, Address Longitude, USNational Grid Coordinate, or Address Elevation values are referenced. The Address Coordinate Reference System Authority and the Address Coordinate Reference System ID should refer interested persons to an authoritative source where the geodetic parameters can be found, or else complete reference information should be provided in the file-level metadata.
3. See Address Coordinate Reference System Authority for additional pertinent notes.
XML Model <xsd:simpleType id="AddressCoordinateReferenceSystemID_type">
<xsd:restriction base="xsd:integer" />
</xsd:simpleType>
XML Example <AddressCoordinateReferenceSystem>
<AddressCoordinateReferenceSystemAuthority>EPSG Geodetic Parameter Dataset </AddressCoordinateReferenceSystemAuthority>
<AddressCoordinateReferenceSystemID>2893</AddressCoordinateReferenceSystemID>
</AddressCoordinateReferenceSystem>
Quality Measures TabularDomainMeasure
Related Element Value Measure
Quality Notes
Element Name AddressDirectSource
Other common names for this element
Definition Source from which the data provider obtained the address, or with which the data provider validated the address.
Definition Source New
Data Type Text
Existing Standards for this Element None
Domain of Values for this Element No
Source of Values NA
How Defined (eg, locally, from standard, other) By data provider
Examples Official Address Authority; regional or state address repository owner; phone company; assessor; commercial data provider
Notes/Comments 1. The Address Direct Source may or may not be the same as the Address Authority. For example, a regional GIS agency might obtain official address records from the cities and counties that are Address Authorities in the region. It might then provide the consolidated set of records to a state agency, which might in turn provide a state-wide file to a federal agency.
--When the regional agency receives address records from the city and county Address Authorities, the Address Authorities are also the Address Direct Sources.
--When the regional agency provides records to the state agency, the regional agency is the Address Direct Source. (The Address Authority remains unchanged.)
--When the state agency provides address records to the federal agency, the state agency is the Address Direct Source. (The Address Authority remains unchanged.)

2. The data provider should enter the Address Direct Source upon creation or transmittal of the address records. Individual address records need contain only the agency name. The file-level metadata should include complete contact information for the Address Direct Source.
Element Name AddressElevation
Other common names for this element Altitude, height, Z-coordinate
Definition Distance of the address in specified units above or below a vertical datum, as defined by a specified coordinate reference system.
Definition Source New
Data Type Real
Existing Standards for this Element Yes
Domain of Values for this Element None
Source of Values Locally defined.
How Defined (eg, locally, from standard, other) By reference to a coordinate reference system.
Examples 1023.0 (elevation in specified units above a specified vertical datum)
Notes/Comments 1. Address Elevation values can be interpreted only if their vertical datum, units of measure, and any other coordinate reference system parameters are provided. The parameters can be documented in the dataset metadata, per FGDC's Content Standard for Digital Geospatial Metadata, or by inclusion in each address record of the Address Coordinate Reference System Authority and Address Coordinate Reference System ID. See Address Coordinate Reference System Authority and Address Coordinate Reference System ID for more information.
2. The dataset metadata, or the Address Reference System documentation, should state what is measured by the Address Elevation (height of the driveway entrance, main building entrance, ground floor, subaddress main floor, etc.).
XML Tag < 
AddressElevation
>
XML Model <xsd:simpleType id="AddressElevation_type">
<xsd:restriction base="xsd:double">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressElevation>1023.0</AddressElevation>
Quality Measures Address Elevation Measure
Quality Notes
Element Name Address End Date
Other common names for this element
Definition The date on which the address is known to no longer be valid.
Definition Source New
Data Type Date
Existing Standards for this Element For representation of dates: YYYYMMDD (Year-month-date)(ISO 8601:2004 and FGDC CSDGM:1998).
Domain of Values for this Element May be created locally
Source of Values Local records
How Defined (eg, locally, from standard, other) Locally
Example 20110209
Notes/Comments 1. An address is given an end date when the Address Authority retires it.
2. Changes to the Complete Address Number value or to the Complete Street Name value warrant retirement of the address.
3. Changes to the values contained in Complete Subaddress, Place Name, and Zip Code do not necessarily warrant a "new" address.
4. Therefore, the Complete Address Number and the Complete Street Name, and the Place Name, and Zip Code elements should have start dates and end dates for the element itself, separate from the dataset start/end dates. The simple elements that make up the Complete Address Number and Complete Street Name do not need to have individual start/end dates.
5. The Address End Date is record-level metadata that should be stored for each address.
6. If the Address Lifecycle Status is potential, proposed or active, then the Address End Date must be null. If the Address Lifecycle Status is retired, then the address or street name must have an Address End Date.
7. Dates are stored in many different ways by various software programs, typically as an integer showing the number of days since some arbitrary beginning date, and converted upon display to a format that people can read. This standard does not prescribe how software should create or handle dates internally. However, for display and exchange of dates, this standard prescribes the YYYYMMDD format specified in ISO 8601:2004 and in the FGDC Content Standard for Digital Geospatial Metadata (v2, 1998). The standard format is unambiguous and easily-understood, it is recognized nationally and internationally, and it can be extended if needed to include hours, minutes and seconds.
XML Tag < 
AddressEndDate
>
XML Model <xsd:simpleType id="AddressEndDate_type">
<xsd:restriction base="xsd:date" />
</xsd:simpleType>
XML Example <AddressEndDate>19950517</AddressEndDate>
Quality Measures Start End Date Order Measure
Future Date Measure
Quality Notes
Element Name Address Feature Type
Other common names for this element
Definition A category of real world phenomena with common properties whose location is specified by an address.
Definition Source Adapted from FGDC Framework Data Content Standard, Part 0: Base Document, Section 5.22
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element May be created locally
Source of Values Local
How Defined (eg, locally, from standard, other) Locally
Example Parcel, building, building entrance, service entrance, subaddress, utility pole, cell tower
Notes/Comments Initial list of feature types: Block, block face, intersection, parcel, building, entrance, subaddress. The list might be expanded indefinitely to include infrastructure and other features. An address may designate multiple Address Feature Types.
XML Tag < 
AddressFeatureType
>
XML Model <xsd:simpleType id="AddressFeatureType_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The type of feature identified by the address
Initial list of feature types: Street block, street block face, intersection, parcel, building, entrance, unit.
The list might be expanded indefinitely to include infrastructure and other features.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value='.+*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressFeatureType>Cell Tower</AddressFeatureType>
Quality Measures Tabular Domain Measure
Address Reference System Rules
Address Completeness Measure
Quality Notes Address Feature Type elements may be defined in the Address Reference System Rules, and should be checked there. Address Completeness Measure checks whether all the addressable objects have assigned addresses.
Element Name AddressID
Other common names for this element
Definition The unique identifier assigned to an address.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element No
Source of Values Primary key, issued locally
How Defined (eg, locally, from standard, other) Locally
Example: Integer ID: 1243286
UUID: 550e8400-e29b-11d4-a716-446655440000
Notes/Comments 1. The Address ID is a required element of an address data record. The ID must be unique for each address assigned by an Address Authority. In cases where an Address Authority does not assign an Address ID, it may be assigned by an address aggregator, such as a regional government, state government, federal agency or a commercial address aggregator. The Address ID may be either a locally generated unique ID, or it may be a Universally Unique ID (UUID) which is machine-generated within the database environment.
2. IDs are almost always integers, and integer ID's are much easier to manage. However, some ID schemes use hyphens, leading zeros, or other non-integer characters, so the standard also accommodates alphanumeric IDs.

Notes and Reference Information on UUID
1. A UUID is presented as a 16-byte (128-bit) number written in hexadecimal form computed according to a UUID algorithm. At least five algorithms have been developed.
2. UUIDs are documented in two standards, ITU-T X.667 and IETF RFC 4122 (see Appendix A for complete references). The two standards are technically consistent.
3. This standard provides for a UUID as a means to identify an address while it is passed from the originating source through a chain of intermediaries to the end-user. The need arises because there exists within the United States no central coordinating body to identify and register addresses. There is not even a registry of the authorities empowered to create addresses, nor is one likely to be created.
4. "The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labelled with UUIDs can therefore be later combined into a single database without need to resolve name conflicts." (quoted from Wikipedia, "Universally Unique Identifier", as posted 4 September 2010 at: http://en.wikipedia.org/wiki/Universally_Unique_Identifier )
XML Tag <AddressID>
XML Model <xsd:simpleType id="AddressId_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressID>550e8400-e29b-11d4-a716-446655440000</AddressID>
Quality Measures Uniqueness Measure
Quality Notes
Element Name AddressLatitude
Other common names for this element
Definition The latitude of the address location, in decimal degrees.
Definition Source New
Data Type Real
Existing Standards for this Element Adapted from FGDC, "Content Standard for Digital Geospatial Metadata (CSDGM)", which refers to the following standard: ANSI INCITS 61-1986 (R2002), "Representation of Geographic Point Locations for Information Interchange".
Domain of Values for this Element Spatial extent of the jurisdiction(s).
Source of Values Source of spatial data collection.
How Defined (eg, locally, from standard, other) By reference to a coordinate reference system.
Example 33.77603207
Notes/Comments Address Latitude values can be interpreted only if their coordinate system, datum, units of measure, and any other coordinate reference system parameters are provided. The parameters can be documented in the dataset metadata, per FGDC's Content Standard for Digital Geospatial Metadata, or by inclusion of the Address Coordinate Reference System Authority and Address Coordinate Reference System ID in each address record. See Address Coordinate Reference System Authority and Address Coordinate Reference System ID for more information.
XML Tag < 
AddressLatitude
>
XML Model <xsd:simpleType id="AddressLatitude_type">
<xsd:restriction base="xsd:double">
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressLatitude>33.77603207</AddressLatitude>
Quality Measures XYCoordinate Completeness Measure
XYCoordinate Spatial Measure
Quality Notes
Element Name Address Lifecycle Status
Other common names for this element
Definition The lifecycle status of the address.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element Potential = Address falls within a theoretical range (See Address Range Type), but has never been used;
Proposed = Application pending for use of this address (e.g., address tentatively issued for subdivision plat that is not yet fully approved);
Active = Address has been issued and is in use;
Retired = Address was issued, but is now obsolete (e.g. street name has been changed, building was demolished, etc.)
Source of Values New
How Defined (eg, locally, from standard, other) From this standard
Notes/Comments 1. An address should be assigned as early as possible in the development process, generally upon subdivision of the land or issuance of the intial building permit. Long before occupancy, a site may require construction deliveries, emergency services, or mention in official records, all of which are facilitated if the address is assigned and known.
2. An address, once issued, should not be deleted from the records, even if it falls out of use. If an address becomes obsolete, its status should be changed from "active" to "retired".
XML Tag < 
AddressLifecycleStatus
>
XML Model <xsd:simpleType id="AddressLifecycleStatus_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The life cycle status of the address.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="Potential" >
<xsd:annotation>
<xsd:documentation>
Address falls within a theoretical range, but has never been used.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Proposed" >
<xsd:annotation>
<xsd:documentation>
Application pending for use of this address (e.g., address tentatively issued for subdivision plat that is not yet fully approved).
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Active" >
<xsd:annotation>
<xsd:documentation>
Address has been issued and is in use.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Retired" >
<xsd:annotation>
<xsd:documentation>
Address was issued, but is now obsolete (e.g. street name has been changed), building was demolished, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressLifecycleStatus>Proposed</AddressLifecycleStatus>
Quality Measures Tabular Domain Measure
Address Lifecycle Status Date Consistency Measure
Quality Notes Each locality will have records describing conditions associated with a given lifecycle status. While the nature of these records and methods for checking correspondence with Address Lifecycle Status entries are beyond the scope of the standard, they may be considered in a local quality program.
Element Name AddressLongitude
Other common names for this element
Definition The longitude of the address location, in decimal degrees.
Definition Source New
Data Type Real
Existing Standards for this Element Adapted from FGDC, "Content Standard for Digital Geospatial Metadata (CSDGM)", which refers to the following standard: ANSI INCITS 61-1986 (R2002), "Representation of Geographic Point Locations for Information Interchange".
Domain of Values for this Element Spatial extent of the jurisdiction(s).
Source of Values Source of spatial data collection.
How Defined (eg, locally, from standard, other) By reference to a coordinate reference system.
Example -84.29049105
Notes/Comments Address Longitude values can be interpreted only if their coordinate system, datum, units of measure, and any other coordinate reference system parameters are provided. The parameters can be documented in the dataset metadata, per FGDC's Content Standard for Digital Geospatial Metadata, or by inclusion of the Address Coordinate Reference System Authority and Address Coordinate Reference System ID in each address record. See Address Coordinate Reference System Authority and Address Coordinate Reference System ID for more information.
XML Tag < 
AddressLongititude
>
XML Model <xsd:simpleType id="AddressLongitude_type">
<xsd:restriction base="xsd:double">
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressLongitude>-84.29049105</AddressLongitude>
Quality Measures XYCoordinate Completeness Measure
XYCoordinate Spatial Measure
Quality Notes
Element Name AddressNumberParity
Other common names for this element
Definition The property of an Address Number with respect to being odd or even.
Definition Source Adapted from MerriamWebster's Dictionary
Data Type characterString
Existing Standards for this Element NA
Domain of Values for this Element "odd", "even"
Source of Values NA
How Defined (eg, locally, from standard, other) Defined in integer mathematics.
Notes/Comments 1. Address Number Parity applies to individual Address Numbers only. Address Range Parity shows the Address Number Parity values for the Address Numbers within a range.
2. Odd and even addresses are usually associated with opposite sides of a street. For example, a jurisdiction may consistently assign odd numbers to the "left" side of its streets and even numbers to the "right" side. ("Left" and "right" would be defined with reference to the Address Reference System.)
3. A Complete Address Number with an Address Number Suffix has the same parity as the Address Number alone. For example, 610 and 610A are both even; 611 and 611 1/2 are both odd.
4. In rare cases, the number "0" is used for an address. It is treated as an even number.
XML Tag 
AddressNumberParity
XML Model <xsd:simpleType id="AddressNumberParity_type">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="Even" />
<xsd:enumeration value="Odd" />
</xsd:restriction>
</xsd:simpleType>
XML Example <CompleteAddressNumber AddressNumberParity="even" >
<AddressNumber>456</AddressNumber>
<AddressNumberSuffix separator=" ">B</AddressNumberSuffix>
</CompleteAddressNumber>
Quality Measure Address Number Parity Measure
Quality Notes
Element Name AddressParcelIdentifier
Other common names for this element Parcel Identifier Number, PIN number
Definition The primary permanent identifier, as defined by the Address Parcel Identifier Source, for a parcel that includes the land or feature identified by an address. A parcel is "a single cadastral unit, which is the spatial extent of the past, present, and future rights and interests in real property."
Definition source For "parcel identifier": Adapted from FGDC, May 2008. "Geographic Information Framework Data Content Standard Part 1: Cadastral." Section 4.2.
For "parcel": FGDC, May 2008. "Cadastral Data Content Standard for the National Spatial Data Infrastructure." Vesion 1.4 Fourth Revision. p. 45. (Part 3.2 "Parcel)
Data Type characterString
Existing Standards for this Element Determined by local ordinance or procedure, or in some cases by state law.
Domain of Values for this Element Determined by local procedure.
Source of Values Address Parcel Identifier Source
How Defined (eg, locally, from standard, other) By local procedure, as it may be governed by local ordinance or state law.
Example 5142301020000 (= the address identifies the land or a feature within parcel 5142301020000)
07660254993-000 (= the address identifies the land or a feature within parcel 07660254993-000)
176-N-075 (= the address identifies the land or a feature within parcel 176-N-075)
Notes/Comments 1. Parcels and addresses are created independently of each other. Some addresses locate features on one parcel only, and some addresses locate features that encompass multiple parcels. There are addresses that locate features that are not on tax parcels, but that are on ownership parcels such as federally-managed lands or public rights of way. Conversely there are parcels that have no address at all, parcels that have one address, and parcels that have many addresses (e.g. large parcels that front on or encompass more than one thoroughfare).
2. Thus no specific address-parcel relationship can be assumed. Addresses and parcels should be treated as independent of each other, and the relationship between should be treated, in relational database terms, as a many-to-many relationship. By providing an Address Parcel Identifier and an Address Parcel Identifier Source, the address standard provides a means to link an address with any number of parcels, and to link a parcel with any number of addresses.
3. The Address Parcel Identifier corresponds to the Parcel ID element in the Cadastral Standard. The Parcel ID is the primary key that identifies each record or occurrence in the Parcel entity. That, plus the Address Parcel Identifier Source, are the only parcel elements included or needed within the address standard. All other parcel elements are defined within the Cadastral Standard and need not be repeated here.
XML Tag < 
AddressParcelIdentifier
>
XML Model <xsd:simpleType id="AddressParcelIdentifier_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressParcelIdentifier>07660254993-000</AddressParcelIdentifier>
Quality Measures Uniqueness Measure
Pattern Sequence Measure
Quality Notes
Element Name AddressParcelIdentifierSource
Other common names for this element
Definition The permanent identifier for the agency, organization, or jurisdiction that assigns and maintains the Address Parcel Identifier.
Definition source FGDC, May 2008. "Geographic Information Framework Data Content Standard Part 1: Cadastral." Section 4.7.
Data Type characterString
Existing Standards for this Element None.
Domain of Values for this Element None.
Source of Values None.
How Defined (eg, locally, from standard, other) By local government (typically county government) law or administrative procedure, as governed by state law.
Example Chester County (PA) Tax Assessment Department Bureau of Land Records
Wake County (NC) Revenue Department
Delaware County (OH) Auditor's Office
Notes/Comments 1. The Address Parcel Identifier Source designates the agency, organization or jurisdiction that assigns and maintains the Address Parcel Identifier.
2. If known, give the full name of the agency (department, office, etc.) rather than just the jurisdiction name.
3. In giving a jurisdiction name, if possible follow known naming standards, such as the ANSI (formerly FIPS) names or codes for states and counties, or GNIS names or codes for minor civil divisions, populated places, and other features.
XML Tag < 
AddressParcelIdentifierSource
>
XML Model <xsd:simpleType id="AddressParcelIdentifierSource_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressParcelIdentifierSource>Wake County (NC) Revenue Department </AddressParcelIdentifierSource>
Quality Measures Tabular Domain Measure
Quality Notes
Element Name AddressRangeDirectionality
Other common names for this element
Definition Whether the low Complete Address Number of an address range is closer to the from-node or the to-node of the transportation segment(s) that the range is related to.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element With - The low address is nearer the from-node; numbers ascend toward the to-node.
Against - The low address is nearer the to-node; numbers descend toward the to-node.
With-Against - The numbers run in opposite directions on either side of the street. The low number on the left side is nearer the from-node. The low number on the right side is nearer the to-node.
Against-With - The numbers run in opposite directions on either side of the street. The low number on the left side is nearer the to-node. The low number on the right side is nearer the from-node.
Null - The address range has null values for the high and low Complete Address Numbers.
NA - Does not apply (transportation segment directionality is inconsistent within the range).
Unknown - The address range directionality is not known.
Source of Values New
How Defined (eg, locally, from standard, other) New
Example Smalltown has a digital street centerline network model. Each street is mapped as a series of segments that run from one intersection to another.

1. With: Segment 1 represents Main Street from First Street to Second Street. It runs from Node 1 to Node 2. (That is, From-node = Node 1; To-node = Node 2). Node 1 = Main and First; Node 2 = Main and Second. The Four Number Address Range along this segment is 100 - 198; 101 - 199 Main Street. 100 Main and 101 Main are both near Node 1 (First and Main); the high numbers are near Main and Second. The Address Range Directionality for this Four Number Address Range is With the segment directionality.

with_range_directionality.jpg

2. Against: Segment 25 represents Elm Street from Oak Street to Pine Street. For Segment 25, the From-node = Node 92 = Elm and Oak; and the To-node = Node 77 = Elm and Pine. The Four Number Address Range along this segment is 110 - 180; 111 - 187 Elm Street. 110 Elm and 111 Elm are both near Node 77 (Elm and Pine); the high numbers are near Elm and Oak. The Address Range Directionality for this Four Number Address Range is Against the segment directionality.

against_range_directionality.jpg

3. Special Case: With - Against: Segment 157 is unusual--the address numbers run in different directions on each side of the street. Segment 157 represents Old Border Road from Farm Road to Park Street. Segment 157 From-node = Node 308; To-node = Node 566. Node 308 = Old Border and Farm; Node 566 = Old Border and Park. The Four Number Address Range along this segment is 4102 - 4188; 4111 - 4181 Old Border Road. 4102 Old Border and 4181 Old Border are both near Node 308 (Old Border and Farm). 4188 Old Border and 4111 Old Border are both near Node 566 (Old Border and Park). The Address Range Directionality for this Four Number Address Range is With - Against the segment directionality.

with_against_range_directionality.jpg

4. Special Case: Against - With: This is the reverse of the previous case. Segment 443 also has address numbers that run in different directions on each side of the road. Segment 443 represents Walden Pond Trail from Northwoods Lane to Thoreau Drive. Segment 443 From-node = Node 618; To-node = 279. Node 618 = Walden Pond Trail and Northwoods Lane, and Node 279 = Walden Pond Trail and Thoreau Drive. The Four Number Address Range along this segment is 8108 - 8192; 8101 - 8191. 8192 Walden Pond Trail and 8101 Walden Pond Trail are near Node 618 (Walden Pond Trail and Northwoods Lane) while 8108 Walden Pond Trail and 8191 Walden Pond Trail are near Node 279 (Walden Pond Trail and Thoreau Drive). The Address Range Directionality for this Four Number Address Range is Against - With the segment directionality.
against_with_range_directionality.jpg
Notes/Comments 1. Address Range Directionality has nothing to do with traffic flow or compass direction.
2. Address Range Directionality states whether the Complete Address Numbers ascend or descend as one proceeds from the from-node to the to-node of the transportation segments (TranSeg(s)) to which the range is related.
3. Address Range Directionality can be defined only for a Two Number Address Range or a Four Number Address Range that has been related to a specific TranSeg (or set of TranSegs) in a particular transportation network model.
4. By definition, TranSegs have a from-node and a to-node, which determine the TranSeg's directionality, right side, and left side.
5. If the low Complete Address Number of a range is closer to the from-node, and the high Complete Address Number is closer to the to-node, then the Complete Address Numbers ascend With the TranSeg directionality.
6. If the low Complete Address Number of a range is closer to the to-node, and the high Complete Address Number is closer to the from-node, then the Complete Address Numbers ascend Against the TranSeg directionality.
7. If the low and high Complete Address Numbers of a range are equal, or equidistant from the from-node and to-node, or if the from-node and the to-node are the same (a loop), then by definition the Complete Address Numbers are considered to ascend With the Tran Seg directionality.
8. If the two ranges of a Four Number Address Range have different Address Range Directionality, then give the left range directionality first, followed by the right range directionality: "With - Against" or "Against - With."
9. Special values apply in the following cases:
---Null - the address range contains null values.
---Unknown - the range directionality (or the relative locations of the low and high Complete Address Numbers) is unknown.
---NA (not applicable) - the range covers multiple TranSegs, and the TranSegs have inconsistent segment directionality.
10. Use the Address Transportation System Name, Address Transportation System Authority, Address Transportation Feature Type, Address Transportation Feature ID, and Related Transportation Feature ID attributes to relate a particular address range to a specific transportation segment (or set of segments) in a specific transportation network model. TranSegs, and transportation network models generally, are defined and described in the FGDC's "Geographic Information Framework Data Content Standard Part 7: Transportation Base."
XML Tag < 
AddressRangeDirectionality
>
XML Model <xsd:simpleType id="AddressRangeDirectionality_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
Whether the low Complete Address Number of an address range is closer to the from-node or the to-node of the transportation segment(s) that the range is related to.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="With">
<xsd:annotation>
<xsd:documentation>The low address is nearer the from-node; numbers ascend toward the to-node.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Against">
<xsd:annotation>
<xsd:documentation>The low address is nearer the to-node; numbers descend toward the to-node.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="With-Against">
<xsd:annotation>
<xsd:documentation>The numbers run in opposite directions on either side of the street. The low number on the left side is nearer the from-node. The low number on the right side is nearer the to-node.</xsd:documentation></xsd:annotation></xsd:enumeration>
<xsd:enumeration value="Against-With">
<xsd:annotation>
<xsd:documentation>The numbers run in opposite directions on either side of the street. The low number on the left side is nearer the to-node. The low number on the right side is nearer the from-node.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Null">
<xsd:annotation>
<xsd:documentation>The address range has null values for the high and low Complete Address Numbers.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="NA">
<xsd:annotation>
<xsd:documentation>Does not apply (transportation segment directionality is inconsistent within the range).
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Unknown">
<xsd:annotation>
<xsd:documentation>The address range directionality is not known.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressRangeDirectionality>With-Against</AddressRangeDirectionality>
Element Name AddressRangeParity
Other common names for this element
Definition The set of Address Number Parity values specified in the Address Reference System Numbering Rules for the Address Numbers in an address range.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element Even, Odd, Both, None, Unknown
Source of Values New
How Defined (eg, locally, from standard, other) Odd - All Address Numbers in the range have an Address Number Parity of "odd"
Even - All Address Numbers in the range have an Address Number Parity of "even"
Both - Both even and odd Address Numbers are found in the range
None - No Address Number is found within the range
Unknown - The parity of the Address Numbers in the range in not known.
Examples Odd - 101 - 199 Main Street
Even - 100 - 198 Main Street
Both - 100 - 199 Main Street
None - (null) - (null) Main Street (no address numbers assigned to that specific segment)
Notes/Comments 1. Odd and even Address Numbers are usually associated with opposite sides of a thoroughfare. For example, a jurisdiction may have rules within its Address Reference System Rules to consistently assign odd numbers to the "left" side of its thoroughfares and even numbers to the "right" side. (See Address Range Side for how "left" and "right" are defined).
2. The Address Range Parity is determined using the Address Reference System Numbering Rules. For theoretical type ranges, the low and high numbers are the lowest and highest numbers of the identified parity found within the identified block within the Address Reference System. For actual ranges, the lowest and highest Address Number in use for the selected block are identified and used. Anomalous addresses (e.g., those Address Numbers that have a parity that is not the same as the Address Range Parity) are not used in creating the actual AddressRange or in determining the Address Range Parity.
3. The expected values for Address Range Parity depend on rules found in the Address Reference System Rules, and are associated with the Address Range Side. If the address range includes addresses from only one side of the thoroughfare, the Address Range Parity is typically but not always "odd" or "even". If the range covers both sides of the thoroughfare, then the Address Range Parity is typically "both"
4. Address ranges composed of milepost Complete Address Numbers (e.g., Milepost 21 - Milepost 24) by definition have a parity of "both". Milepost numbers denote distance only, not side of street. (For more information on milepost Complete Address Numbers, see Complete Address Number.)
5. If no addresses occur within a range, then the Address Range Parity is "None."
XML Tag < 
AddressRangeParity
>
XML Model <xsd:simpleType id="AddressRangeParity_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The set of Address Number Parity values specified in the Address Reference System Numbering Rules for the Address Numbers in an address range.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
<xsd:enumeration value="even" >
<xsd:annotation>
<xsd:documentation>
All Address Numbers in the range have an Address Number Parity of "even".
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="odd" >
<xsd:annotation>
<xsd:documentation>
All Address Numbers in the range have an Address Number Parity of "odd".
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="both" >
<xsd:annotation>
<xsd:documentation>
Both even and odd Address Numbers are found in the range.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="none" >
<xsd:annotation>
<xsd:documentation>
No Address Number is found within the range.
</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="unknown" >
<xsd:annotation>
<xsd:documentation>The parity of the Address Numbers in the range in not known. </xsd:documentation></xsd:annotation></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressRangeParity>odd</AddressRangeParity>
Element Name AddressRangeSide
Other common names for this element
Definition The side of the transportation segment(s) (TranSeg) or path (TranPath) on which the address range is found (right, left or both).
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element right, left, both, none, unknown
Source of Values New
How Defined (eg, locally, from standard, other) New
Example Elm Street runs south-to-north. For each block,the from-node is at the south end, and the to-node is at the north end. "Right" and "left" are defined by standing at the south (from) end, and facing the north (to) end. The "right" side is in this case the east side, and the "left" side is the west side. (If the from- and to- nodes were reversed, "left' and "right' would also be reversed.)
Notes/Comments 1. Address Range Side has nothing to do with traffic flow or compass direction.
2. Address Range Side states whether the range includes Complete Address Numbers on right side, left side, or both sides of the thoroughfare.
3. "Right" and "left" must be defined by reference to a specific transportation segment (or set of segments) in a particular transportation network model. By definition, every transportation segment has a from-node at one end and a to-node at the other end. The directionality, right side, and left side of the segment are determined by standing at the from-node and facing the to-node. Address Left Right Measure and Address Range Directionality Measure provide tools for determining "left", "right" and directionality.
4. Address Range Directionality can be defined only for a Two Number Address Range or a Four Number Address Range that has been related to a specific transportation segment (or set of segments) in a particular transportation network model.
5. Use the Address Transportation System Name, Address Transportation System Authority, Address Transportation Feature Type, Address Transportation Feature ID, and Related Transportation Feature ID attributes to relate a particular address range to a specific transportation segment (or set of segments) in a specific transportation network model. Transportation segments, and transportation network models generally, are defined and described in the FGDC's "Geographic Information Framework Data Content Standard Part 7: Transportation Base."
XML Tag < 
AddressRangeSide
>
XML Model <xsd:simpleType id="AddressRangeSide_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The side of the transportation segment (right , left,
both, none, unknown) on which the address range applies.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
<xsd:enumeration value="right" >
<xsd:annotation>
<xsd:documentation>
The address is related to the right side of the street.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="left" >
<xsd:annotation>
<xsd:documentation>
The address is realted to the left side of the street.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="both">
<xsd:annotation>
<xsd:documentation>
The address pertains to both sides of the street.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="none" >
<xsd:annotation>
<xsd:documentation>The address is not on either or both sides of the street or the concept of side of street does not apply to the address.
For instance an intersection address would have an Address Side Of Street of none.
</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="unknown" ></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressRangeSide>left</AddressRangeSide>
Quality Measures Left Right Odd Even Parity Measure
Address Left Right Measure
Quality Notes Note that this measure checks the agreement of an Address Range Side attribute with geometry, while Left Right Odd Even Parity Measure checks the agreement of an Address Number against an established local rule for associating address parity with the right or left side of the street when traveling away from the governing Address Reference System Axis Point Of Beginning.
Element Name AddressRangeSpan
Other common names for this element
Definition Whether an address range covers part of a transportation segment, one segment, multiple segments, or the entire thoroughfare within the Address Reference System Extent.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element Partial Segment, Single Segment, Multi Segments, Entire Street (within a given Address Reference System Extent), Unknown. Other values may be defined locally.
How Defined (eg, locally, from standard, other) New
Example Oak Street is four blocks long. Each block is represented as a single transportation segment. Each block has a different hundred range: 1-99, 100-199, 200-299, 300-399. On the first block, a small strip shopping center with a single entrance has storefronts with Complete Address Numbers 2-42. Address Range Spans for following address ranges would be:
1. 2 -42 Oak Street Address Range Span = Partial block
2. 200- 299 Oak Street Address Range Span = Single block
3. 100- 299 Oak Street Address Range Span = Multi-block
4. 1 - 399 Oak Street Address Range Span = Entire street
Notes/Comments 1. Address Range Span states whether an address range covers part of a transportation segment, one segment, multiple segments, or the entire thoroughfare within the Address Reference System Extent.
2. Address Range Span indicates the nature and extent of the geometric features that the range is associated with. It might cover a single building, a portion of a street segment, a full street segment (the most common way in which a range is used), a group of segments, or entire street within a jurisdiction. The latter two categories are often used in E-911 applications where the entire range of addresses found in a single Emergency Service Zone is used.
3. Address Range Span can be defined only for a Two Number Address Range or a Four Number Address Range that has been related to a specific transportation segment (or set of segments) in a particular transportation network model.
4. Use the Address Transportation System Name, Address Transportation System Authority, Address Transportation Feature Type, Address Transportation Feature ID, and Related Transportation Feature ID attributes to relate a particular address range to a specific transportation segment (or set of segments) in a specific transportation network model. Transportation segments, and transportation network models generally, are defined and described in the FGDC's "Geographic Information Framework Data Content Standard Part 7: Transportation Base."
XML Tag < 
AddressRangeSpan
>
XML Model <xsd:simpleType id="AddressRangeSpan_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
Whether an address range covers part of a transportation
segment, one segment, multiple segments, or the entire
thoroughfare within the Address Reference System Extent.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Partial Segment" ></xsd:enumeration>
<xsd:enumeration value="Single Segment" ></xsd:enumeration>
<xsd:enumeration value="Multi Segment" ></xsd:enumeration>
<xsd:enumeration value="Entire Street" ></xsd:enumeration>
<xsd:enumeration value="Unknown" gt;</xsd:enumeration>
<xsd:pattern value=".+"></xsd:pattern>
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressRangeSpan>Entire Street</AddressRangeSpan>
Quality Measures Tabular Domain Measure
Quality Notes
Element Name AddressRangeType
Other common names for this element
Definition This attribute states whether an address range (either a Two Number Address Range or a Four Number Address Range) is actual or potential.
Actual range: the low and high Complete Address Numbers are numbers that have been assigned and are in use along the addressed feature.
Potential range: the low and high Complete Address Numbers are numbers that would be assigned if all possible numbers were in use along the addressed feature, and there were no gaps between the range and its preceding and following ranges.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element Actual, Potential, Unknown
Source of Values New
How Defined (eg, locally, from standard, other) New
Example Actual range
Notes/Comments 1. Ranges may be actual or potential.
2. Actual ranges give the lowest and highest Complete Address Numbers that have been assigned and are in use along the addressed featurem, excluding any addresses that are anomalies, especially with regard to parity or sequence.
3. Potential (or theoretical) ranges include all the numbers that could be assigned along the addressed feature based on the Address Reference System Numbering Rules. Potential ranges permit no numbering gaps between the range and its preceding and following ranges. Potential ranges are equal to or broader than actual ranges.
4. The Census Bureau uses theoretical ranges in its TIGER files, to ensure continuity from census to census. Potential ranges are also used in Googlemaps, Mapquest and other online road map and routing services, because they get their data originally from Census TIGER files.
5. Theoretical ranges are useful for software, such as some computer aided emergency dispatching applications, that requires continuous ranges along the length of a street.
6. Ranges are often used for geocoding, but point matches are preferable.
7. When constructing actual ranges, the lowest assigned Address Number and the highest assigned Address Number in use along a given segment are used. However, no Address Number which is an anomaly (as to range parity or side, or for any other reason) is to be used in constructing the actual address range.
XML Tag < 
AddressRangeType
>
XML Model <xsd:simpleType id="AddressRangeType_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
This attribute states whether an address range (either a Two Number Address Range or a Four Number Address Range) is actual or potential.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Actual" >
<xsd:annotation>
<xsd:documentation>the low and high Complete Address Numbers are numbers that have been assigned and are in use along the addressed feature.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Potential" >
<xsd:annotation>
<xsd:documentation>The low and high Complete Address Numbers are numbers that would be assigned if all possible numbers were in use along the addressed feature, and there were no gaps between the range and its preceding and following ranges.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Unknown" >
<xsd:annotation>
<xsd:documentation>The relationship between the low and high Complete Address Numbers and the addressed feature is unknown.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressRangeType>Actual</AddressRangeType>
Quality Measures Tabular Domain Measure
Quality Notes
Element Name AddressRelationType
Other common names for this element
Definition The manner in which an address identified by a Related Address ID is related to an address identified by an Address ID.
Definition Source New
Data Type characterString
Required Element None.
Existing Standards for this Element None
Domain of Values for this Element May be created locally to standardize terms used to describe relationships.
How Defined (eg, locally, from standard, other) New
Example 1. 123 Main St (Address ID = 1000) is also known as the "Grand Old Office Building" (a landmark name, Address ID = 5000). Then for:
Related Address ID = 5000, Address ID = 1000, Address Relation Type = Landmark Name Alias
Related Address ID = 1000, Address ID = 5000, Address Relation Type = Official Street Address

2. Tax bills for 123 Main St (Address ID = 1000) should be sent to
PO Box 150080, Omaha, NE 68153 (Address ID = 8000).
Correspondence for the owner should be sent to 108 East Burnside Street, Portland, OR 97214. (Address ID = 10267). Then for:
Related Address ID = 8000, Address ID = 1000, Address Relation Type = Tax Billing
Related Address ID = 10267, Address ID = 1000, Address Relation Type = Owner Mailing

3. 123 Main Street was created years ago when 101 Main Street (Address ID = 250) was subdivided into several properties. Then for:
Related Address ID = 250, Address ID = 1000, Address Relation Type = Historical Predecessor

4. This particular part of Main Street is part of State Route 88. 123 Main Street (Address ID = 1000) is the official address, but 123 State Route 88 (Address ID = 8943) is also recognized. Then for:
Related Address ID = 8943, Address ID = 1000, Address Relation Type = Official Alias Address
Related Address ID = 1000, Address ID = 8943, Address Relation Type = Official Address

5. A large building occupies an entire square block in a downtown area. It has a main entrance to its public lobby at 123 Main Street. However, its loading dock, mail and goods receiving entry, and trash pickup location are on the "back" of the building, which faces Elm Street, and is given the address of 122 Elm Street. In this instance, the main entrance at 123 Main Street has Address ID = 1000, while the service entrance at 122 Elm Street has Address ID = 789. The Relationship would be:
Related Address ID = 789, Address ID = 1000, Address Relation Type = Service Entrance
Related Address ID = 1000, Address ID = 789, Address Relation Type = Official Address
Notes/Comments 1. This element describes how two addresses, identified by their Related Address ID and Address ID respectively, are related. Relationships may be defined and described in any way, according to the needs of the user. To maximize efficiency and clarity, users should establish a limited, standard set of descriptors that meet local needs.
2. To minimize ambiguity, the descriptors should state how the Related Address ID is related to the Address ID, not the other way around.
3. To minimize clutter, short connector words such as "is", "are", "for", "of", etc. may be omitted from the descriptors if the meaning is otherwise clear.
4. Examples 1, 3, and 4 above show how Related Address ID can be used to link an address to its alias addresses or to its historical predecessor address.
5. Example 1 above shows that two related addresses must have reciprocal relations, each being designated by the Address ID in one case and the Related Address ID in the other.
6. Example 5 shows how one feature (such as a large building) may have more than one address, each with a different purpose (official street address vs service entrance).
7. Example 2 above shows that Related Address ID may designate an address that is outside the control of, and perhaps distant from, the Address Authority that created the address it is related to. It is common, for example, for owners to live in different states from properties they own, or for tax bills to be sent to out-of-state mortgage service addresses.
XML Tag < 
AddressRelationType
>
XML Model <xsd:simpleType id="AddressRelationType_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <RelatedAddressID AddressRelationType="Historical Predecessor" >250</RelatedAddressID>
Quality Measures Tabular Domain Measure
Quality Notes
Element Name AddressSideOfStreet
Other common names for this element
Definition The side of the transportation segment (right , left, both, none, unknown) on which the address is located.
Data Type characterString
Existing Standards for this Element U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base," sections 7.3.2 and B.3.6
Domain of Values for this Element right, left, both, none, unknown
Source of Values
How Defined (eg, locally, from standard, other) U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base," Annex B.
Example See domain of values above.
Notes/Comments 1. "Left" and "right" are defined by reference to the direction of the transportation segment to which the address is related. "The direction of a TranSeg is determined by its "from" and "to" TranPoints" (Transporation base standard, section 7.3.2). "Left" and "right" are defined by facing the "to" TranPoint.
2. Most addresses are located to the left or right of the segment. The value of "none" can be used only for Intersection Addresses, which by definition occur at the point of intersection of two or more street segments. An Intersection Address begins or ends a segment and so is not on either side of it.
3. If an addressed feature straddles the thoroughfare to which it is addressed (a rare occurence but it does happen), it should be given the Address Side Of Street value that corresponds to the correct side for the number that was assigned to the feature.
4. Address Side Of Street does not apply to address ranges. Use the the Address Range Side attribute to give the side of a Two Number Address Range or a Four Number Address Range.
XML Tag < 
AddressSideOfStreet
>
XML Model <xsd:simpleType id="AddressSideOfStreet_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
<xsd:enumeration value="right" >
<xsd:annotation>
<xsd:documentation>
The address is related to the right side of the street.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="left" >
<xsd:annotation>
<xsd:documentation>
The address is realted to the left side of the street.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="both" >
<xsd:annotation>
<xsd:documentation>
The address pertains to both sides of the street.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="none" >
<xsd:annotation>
<xsd:documentation>The address is not on either or both sides of the street or the concept of side of street does not apply to the address.
For instance an intersection address would have a Address Side Of Street of none.
</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="unknown" ></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressSideOfStreet>both</AddressSideOfStreet>
Element Name Address Start Date
Other common names for this element
Definition The earliest date on which the address is known to exist.
Definition Source New
Data Type Date
Existing Standards for this Element For representation of dates: YYYYMMDD (Year-month-date)(ISO 8601:2004 and FGDC CSDGM:1998).
Domain of Values for this Element May be created locally
Source of Values Local records
How Defined (eg, locally, from standard, other) Locally
Example 20050413
Notes/Comments 1, The Address Start Date is record-level metadata that should be stored for each address.
2. Changes to the Complete Address Number values or to the Complete Street Name values warrant retirement and creation of a "new" address record.
3. Changes to the values contained in Complete Subaddress, Place Name, and Zip Code do not necessarily warrant creation of a "new" address record.
4, Therefore, the Complete Address Number and the Complete Street Name, and the Place Name, and Zip Code elements should each have their own start dates and end dates, separate from the address start/end dates, and the dataset start/end dates. The simple elements that make up the Complete Address Number and Complete Street Name do not need to have individual start/end dates.
5. An address start date is not assigned until the Address Lifecycle Status is "proposed" or "active". The start date is generally the date on which the address authority assigns or reserves the address for use. As a rule this should be done as early as possible in the development process, generally upon subdivision of the land or issuance of the intial building permit.
6. By definition, an address with a Address Lifecycle Status of "potential" has no Address Start Date.
7. Dates are stored in many different ways by various software programs, typically as an integer showing the number of days since some arbitrary beginning date, and converted upon display to a format that people can read. This standard does not prescribe how software should create or handle dates internally. However, for display and exchange of dates, this standard prescribes the YYYYMMDD format specified in ISO 8601:2004 and in the FGDC Content Standard for Digital Geospatial Metadata (v2, 1998). The standard is unambiguous and easily-understood, it is recognized nationally and internationally, and it can be extended if needed to include hours, minutes and seconds.
XML Tag < 
AddressStartDate
>
XML Model <xsd:simpleType id="AddressStartdDate_type">
<xsd:restriction base="xsd:date" />
</xsd:simpleType>
XML Example <AddressStartDate>19950517</AddressStartDate>
Quality Measures Start End Date Order Measure
Future Date Measure
Quality Notes
Element Name AddressTransportationFeatureID
Other common names for this element
Definition The unique identifier assigned to the particular feature that represents an address within a transportation base model.
Data Type characterString
Existing Standards for this Element U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base."
"Framework Data Content Standard Part 7c: Roads,"
Domain of Values for this Element Constrained by reference transportation base model.
Source of Values Reference transportation base model.
How Defined (eg, locally, from standard, other) Within reference transportation base model.
Example 9087456
Notes/Comments 1. The reference transportation base model might identify addresses by their Address ID, or it might assign a different identifier within the transportation base model.
2. If a different identifier is assigned within the transportation base model, then the Address Transportation Feature ID will serve, within the scope of the address record, as a foreign key to the transportation base model.
XML Tag < 
AddressTransportationFeatureID
>
XML Model <xsd:simpleType id="AddressTransportationFeatureId_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressTransportationFeatureID>9087456</AddressTransportationFeatureID>
Quality Measures Pattern Sequence Measure
Uniqueness Measure
Quality Notes
Element Name AddressTransportationFeatureType
Other common names for this element Point, centroid; node, intersection; line, arc, segment, edge; path, route
Definition The type of transportation feature (TranFeature) used to represent an address.
Data Type characterString
Existing Standards for this Element For transportation features generally: U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base."
For road features only: U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base," as extended by "Framework Data Content Standard Part 7c: Roads."
Domain of Values for this Element For transportation features generally: Point event, linear event, transportation point (TranPoint), transportation segment (TranSeg), or transportation path (TranPath)
For road features only: RoadPointFeatureEvent, RoadLinearFeatureEvent, RoadPoint, RoadSeg, or RoadPath
Source of Values U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base." See especially Sections 5 (Terms and Definitions), and Section 7 (Requirements).
How Defined (eg, locally, from standard, other) For all transportation features: U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base."
For road features: "Framework Data Content Standard Part 7c: Roads."
Examples Point event: parcel centroid, building centroid, etc., located along a thoroughfare.
Linear event: parcel frontage, building frontage, etc. located along a thoroughfare
Transportation point: Any Intersection Address
Transportation segment: A length of road between two intersecting roads (First Street between A Street and B Street)
Transportation path: A length of road including multiple segments (First Street from beginning to end)
Notes/Comments 1. This element is meaningful only in the context of a transportation base model as defined in the FGDC's "Framework Data Content Standard Part 7." Transportation features are defined therein.
2. The type of transportation feature used to represent an address depends on:
--a. the class of the address, and
--b. (in some cases) how the address is mapped (i.e. as a point, line, or polygon).
These relationships are explained more fully in Appendix H (Section 3) of this standard.
XML Tag < 
AddressTransportationFeatureType
>
XML Model <xsd:simpleType id="AddressTransportationFeatureType_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressTransportationFeatureType>RoadPoint</AddressTransportationFeatureType>
Quality Measures Address Completeness Measure
Intersection Validity Measure
Segment Directionality Consistency Measure
XYCoordinate Completeness Measure
XYCoordinate Spatial Measure
Quality Notes
Element Name AddressTransportationSystemAuthority
Other common names for this element Department of Transportation, Public Works Department, Roads Department, etc.
Definition The authority that maintains the transportation base model specified by the Address Transportation System Name, and assigns Address Transportation Feature IDs to the features it represents.
Data Type characterString
Existing Standards for this Element None.
Domain of Values for this Element None.
Source of Values None.
How Defined (eg, locally, from standard, other) NA
Example District of Columbia Department of Transportation (Street Spatial Data Base)
U.S. Census Bureau (TIGER/MAF file)
Notes/Comments The authority is typically the office or agency responsible for opening, maintaining, and closing the transportation features represented in the transportation base model. In some cases, the data model may be maintained by a federal agency or a private-sector firm.
XML Tag < 
AddressTransportationSystemAuthority
>
XML Model <xsd:simpleType id="AddressTransportationSystemAuthority_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressTransportationSystemAuthority>District of Columbia Department of Transportation</AddressTransportationSystemauthority>
Quality Measures Tabular Domain Measure
Quality Notes
Element Name AddressTransportationSystemName
Other common names for this element Street centerline file, road network file, street network file, centerline network file
Definition The name of the transportation base model to which the address is related.
Data Type characterString
Existing Standards for this Element 1. There are no standards specifically for naming specific transportation base models.
2. The content requirements for transportation base models are set forth in: U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base."
3. The Transportation base part is extended by the "Framework Data Content Standard Part 7c: Roads," which sets forth the requirements for road system models.
4. The Framework Data Content Standard Part 7: Transportation is incorporated into this standard by reference.
Domain of Values for this Element None.
Source of Values None.
How Defined (eg, locally, from standard, other) By Address Transportation System Authority
Example DC Street Spatial Data Base
TIGER/MAF File
Notes/Comments 1. The Transportation Standard base part "defines the data model for describing transportation systems components of transportation systems for the modes [Roads, rail, inland waterways, and transit] that compose the Transportation theme of the NSDI." ("Framework Data Content Standard Part 7: Transportation base", Section 1, "Scope." ).
2. All thoroughfare addresses, by definition, are located by reference to a thoroughfare--that is, by reference to a component of a transportation system. In addition, many landmark addresses and some postal addresses may also be so located, by virtue of alias addresses, road frontages, etc.
3. To make explicit the relationship between addresses and transportation networks, to provide a foundation for Address Reference Systems, and to strengthen address data quality testing, the "Framework Data Content Standard Part 7: Transportation" is incorporated by reference into this standard.
4. A thoroughfare is defined in Part 3: Street Address Data Classification of this Standard as follows: "...a road or other access route by which the addressed feature can be reached... A thoroughfare is typically but not always a road it may be, for example, a walkway, a railroad, or a river. Most Address Reference Systems pertain only to road systems--addresses are rarely assigned along rail lines or waterways.
5. Where only roads are of concern, reference should also be made to the "Framework Data Content Standard Part 7c: Roads," which extends the Transportation Standard base part.
XML Tag < 
AddressTransportationSystemName
>
XML Model <xsd:simpleType id="AddressTransportationSystemName_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressTransportationSystemName>TIGER/MAF File</AddressTransportationSystemName>
Quality Measures Tabular Domain Measure
Quality Notes
Element Name Address XCoordinate
Other common names for this element
Definition The X coordinate of the address location.
Definition Source New
Data Type Real
Existing Standards for this Element Yes
Domain of Values for this Element Spatial extent of the jurisdiction(s).
Source of Values Source of spatial data collection.
How Defined (eg, locally, from standard, other) By reference to a coordinate reference system (see note below).
Example 750908.0469
Notes/Comments Address XCoordinate values can be interpreted only if their coordinate system, datum, units of measure, and any other coordinate reference system parameters are provided. The parameters can be documented in the dataset metadata, per FGDC's Content Standard for Digital Geospatial Metadata, or by inclusion of the Address Coordinate Reference System Authority and Address Coordinate Reference System ID in each address record. See Address Coordinate Reference System Authority and Address Coordinate Reference System ID for more information.
XML Tag < 
AddressXCoordinate
>
XML Model <xsd:simpleType id="AddressXCoordinate_type">
<xsd:restriction base="xsd:double">
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressXCoordinate>750908.0469</AddressXCoordinate>
Quality Measures XYCoordinate Completeness Measure
XYCoordinate Spatial Measure
Quality Notes
Element Name Address YCoordinate
Other common names for this element
Definition The Y coordinate of the address location.
Definition Source New
Data Type Real
Existing Standards for this Element Yes
Domain of Values for this Element Spatial extent of the jurisdiction(s).
Source of Values Source of spatial data collection.
How Defined (eg, locally, from standard, other) By reference to a coordinate reference system.
Example 3740623.0628
Notes/Comments Address YCoordinate values can be interpreted only if their coordinate system, datum, units of measure, and any other coordinate reference system parameters are provided. The parameters can be documented in the dataset metadata, per FGDC's Content Standard for Digital Geospatial Metadata, or by inclusion of the Address Coordinate Reference System Authority and Address Coordinate Reference System ID in each address record. See Address Coordinate Reference System Authority and Address Coordinate Reference System ID for more information.
XML Tag < 
AddressYCoordinate
>
XML Model <xsd:simpleType id="AddressYCoordinate_type">
<xsd:restriction base="xsd:double">
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressYCoordinate>3740623.0628 </AddressYCoordinate>
Quality Measures XYCoordinate Completeness Measure
XYCoordinate Spatial Measure
Quality Notes
Element Name AddressZLevel
Other common names for this element Floor, building level, story
Definition Floor or level of the structure
Definition Source New
Data Type Integer
Existing Standards for this Element N/A
Domain of Values for this Element Positive integers
Source of Values Field observations, building plans, or other source of spatial data collection.
How Defined (eg, locally, from standard, other) The lowest level of a building is 1, and ascending numbers are assigned in order to each higher level.
Examples 1 (=lowest floor), 3 (the ground floor, if the structure has two below-ground floors)
Notes/Comments 1. This attribute is intended for use with multi-story buildings, where the Subaddress Element does not indicate the building level on which the subaddress is found. Common examples include hotel lobbies and mezzanines, named meeting rooms in conference centers, and multi-unit residential buildings whose unit identifiers do not indicate the building level ("Penthouse", "Basement").
2. "Ground level" is often ambiguous (especially when the building itself is built on sloping ground), and floor designations often omit parking and basement levels at the base of the building. To avoid confusion in assigning Address ZLevel values, 1 should be assigned to the lowest level of the building, and ascending numbers assigned in order to each higher level, regardless of how that level is named within the building floor plan. Use the Subaddress Element to record how a subaddress is named in the building floor plan.
XML Tag < 
AddressZLevel
>
XML Model <xsd:simpleType id="AddressZLevel_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <AddressZLevel>13</AddressZLevel>
Quality Measures Tabular Domain Measure
Quality Notes
Element Name ANSIState County Code
Other common names for this element (Obsolete) FIPS State Codes (FIPS Publication 5-2), FIPS County Codes (FIPS Publication 6-4)
Definition A set of two-digit numeric codes identifying the states, the District of Columbia, Puerto Rico, and the insular areas of the United States, which may be followed by a three-digit numeric code identifying a county or equivalent entity therein.
Definition Source State codes: ANSI INCITS 38:2009.
County codes: ANSI INCITS 31:2009.
Data Type Text
Existing Standards for this Element State codes: ANSI INCITS 38:2009.
County codes: ANSI INCITS 31:2009.
Domain of Values for this Element State codes: 01 through 99 (not all codes are in use).
County codes: 001 through 999 (not all codes are in use).
Source of Values State codes: ANSI INCITS 38:2009.
County codes: ANSI INCITS 31:2009.
How Defined (eg, locally, from standard, other) State codes: ANSI INCITS 38:2009.
County codes: ANSI INCITS 31:2009.
Examples 48 (Texas)
48301 (Loving County, Texas: 48 = Texas; 301 = Loving County)
15005 (Kalawao County, Hawaii: 15 = Hawaii; 005 = Kalawao County)
51610 (Falls Church, Virginia: 51 = Virginia; 610 = Falls Church city (an independent city with county-level governance status))
01117 (Shelby County, Alabama: 01 = Alabama; 117 = Shelby County)
Notes/Comments 1. The state and county codes provide numeric identifiers for states and state equivalents (see State Name) and their counties or county equivalents (see Place Name - Other common names for this element (county)).
2. State codes are two-digit numbers, which may include a leading zero. County codes are three-digit numbers that typically begin with 001 for each state and state equivalent. A county identifier is a five digit combination of the state code followed by the county code.
3. The state and county codes were originally established and maintained by the National Institute of Standards and Technology (NIST) as Federal Information Processing Standards (FIPS) Publications 5-2 (for state codes) and 6-4 (for county codes). The standards were withdrawn by NIST on September 2, 2008 and replaced by the ANSI INCITS 38:2009 standard and ANSI INCITS 31:2009 standard respectively, with the Census Bureau as the maintenance authority for both.
4. ANSI Standards are protected by ANSI copyright. The Census Bureau provides the codes copyright-free via its public website. Part Six of this standard provides complete references to the Census Bureau website and the ANSI Standards, listed under U.S. Census Bureau.
XML Tag <ANSIStateCountyCode>
XML Model <xsd:simpleType id="ANSIStateCountyCode_type">
<xsd:restriction base="xsd:string" />
</xsd:simpleType>
XML Example <ANSIStateCountyCode> 01015 </ANSIStateCountyCode>
Quality Measures Tabular Domain Measure
Spatial Domain Measure
Quality Notes
Element Name AttachedElement
Other common names for this element
Definition This attribute identifies when two or more Complete Address Number elements or two or more Complete Street Name elements have been combined without a space separating them.
Definition Source New
Data Type characterString
Required Element No
Existing Standards for this Element None
Domain of Values for this Element Attached, Not Attached, Unknown
Source of Values New
How Defined (eg, locally, from standard, other) New
Example 121E E Street ( Attached)
121 E E Street ( Not Attached)
Banhoffstrasse ( Attached)
Banhoff Street ( Not Attached)
Notes/Comments 1. The Attached Element attribute can be used to indicate that two or more Complete Address Number elements or two or more Complete Street Name elements have been combined with no space between them, so that the parsing and construction of the elements can be managed correctly.
2. Complete Address Numbers are often written with no space between the Address Number and the Address Number Prefix or Address Number Suffix (e.g., 121E E Street). The Attached Element can be used to indicate where the space is omitted as a standard practice.
3. German-language street names words are often written as a single word, combining the Street Name and Street Name Post Type (e.g., Banhoffstrasse). The Attached Element can be used to indicate such names. Attached Elements are rare in the United States street names, and normally this attribute will not be needed. In such cases the entire single word can be placed in the Street Name field, and the street type field can be left blank (e.g., "Broadway").
XML Tag 
AttachedElement
XML Model <xsd:simpleType id="AttachedElement_type">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Attached">
<xsd:annotation>
<xsd:documentation>The elements inside the Complete Address Number or Complete Street Name are attached and need special parsing rules.</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="Not Attached"></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <CompleteAddressNumber Address Number Parity="even" AttachedElement="Attached" >
<AddressNumber>456</AddressNumber>
<AddressNumberSuffix separator=" ">B</AddressNumberSuffix>
</CompleteAddressNumber>
Quality Measures CheckAttachedPairsMeasure
Tabular Domain Measure
Quality Notes CheckAttachedPairsMeasure checks for adjacent pairs of attached attributes. The value of the street name as a whole, including the attached components are checked in the Tabular Domain Measure and Pattern Sequence Measure, applied to CompleteStreetName.
Element Name DataSetID
Other common names for this element
Definition An identifier in each record of a transmitted dataset, assigned by the sender or the receiver of the dataset, to associate each record of the dataset to the file-level metadata that accompanies the dataset.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element Yes
Source of Values Assigned by the sender or the receiver of a data set.
How Defined (eg, locally, from standard, other) Assigned by the sender or the receiver of a data set.
Example Dataset ID 1475
Notes/Comments 1. The content of the file-level metadata is specified in the FGDC's Content Standard for Digital Geospatial Metadata.
2. The ID may be assigned by the sender upon transmittal of the dataset or the recipient upon receipt.
3. Normally the identifier will be numeric, but the standard does not preclude alphanumeric identifiers.
XML Tag < 
DataSetID
>
XML Model <xsd:simpleType id="DataSetID_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value=".*"></xsd:pattern>
</xsd:restriction>
</xsd:simpleType>
XML Example <DataSetID>1457</DataSetID>
Quality Measures Related Not Null Measure
Quality Notes
Element Name DeliveryAddressType
Other common names for this element
Definition Whether the Delivery Address includes or excludes the Complete Subaddress.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element Subaddress Included - The Delivery Address includes the Complete Subaddress (if any)
Subaddress Excluded - The Delivery Address excludes the Complete Subaddress (if any)
Unstated - Not stated/no information (default value)
Source of Values New
How Defined (eg, locally, from standard, other) Defined herein.
Example Delivery Address = 123 Main Street, Apt. 1 (Delivery Address Type = Subaddress Included)
Delivery Address = 123 Main Street Complete Subaddress = Apt. 1 (Delivery Address Type = Subaddress Excluded)

Delivery Address = Ames High School, Room 12 (Delivery Address Type = Subaddress Included)
Delivery Address = Ames High School Complete Subaddress = Room 12 (Delivery Address Type = Subaddress Excluded)
Notes/Comments 1. The Delivery Address typically includes the Complete Subaddress. However, there are sometimes reasons to omit or separate the Complete Subaddress from the Delivery Address. For example, the Complete Subaddress can hamper address geocoding, and contact lists often separate the Complete Subaddress from the rest of the Delivery Address (see, for example, the EPA Contact Information Data Standard).
2. The Delivery Address Type shows whether the Delivery Address includes or excludes the Complete Subaddress.
3. If all the records in a file have the same Delivery Address Type, this information can be included in the file-level metadata. If records of different types are likely to be mixed together, the Delivery Address Type should be included in each record.
XML Tag 
DeliveryAddressType
XML Model <xsd:simpleType id="DeliveryAddressType_type">
<xsd:restriction base="xsd:token">
<xsd:enumeration value='SubAddress Included' >
<xsd:annotation>
<xsd:documentation>The Delivery Address includes the Complete Subaddress (if any) </xsd:documentation></xsd:annotation></xsd:enumeration>
<xsd:enumeration value='SubAddress Excluded' >
<xsd:annotation>
<xsd:documentation>The Delivery Address includes the Complete Subaddress (if any) </xsd:documentation></xsd:annotation></xsd:enumeration>
<xsd:enumeration value='Unstated' >
<xsd:annotation>
<xsd:documentation>Not stated/no information (default value) </xsd:documentation>
</xsd:annotation></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <DeliveryAddress DeliveryAddressType="Subaddress Included" >123 Dartmouth College Highway, Suite 100</DeliveryAddress>
<DeliveryAddress DeliveryAddressType="Subaddress Excluded" >123 Dartmouth College Highway, Suite 100</DeliveryAddress>
Quality Measures Tabular Domain Measure
Delivery Address Type Subaddress Measure
Quality Notes
Element Name Element Sequence Number
Other common names for this element
Definition The order in which the Subaddress Elements should be written within a Complete Subaddress; the order in which the Landmark Names should be written within a Complete Landmark Name; or the order in which the Place Names should be written within a Complete Place Name.
Definition Source New
Data Type Integer
Existing Standards for this Element None
Domain of Values for this Element Positive integers
Source of Values Locally determined
How Defined (eg, locally, from standard, other) Locally
Example For the Complete Place Name "Sun Valley, San Rafael, Marin County," the Place Name elements would have the following Element Sequence Numbers:
Sun Valley: Element Sequence Number= 1
San Rafael: Element Sequence Number= 2
Marin County: Element Sequence Number= 3
Notes/Comments 1. Complete Subaddresses, Complete Landmark Names, or Complete Place Names can include more than one component element. When that occurs, the Element Sequence Number shows the order in which the components should be assembled.
2. If the Element Sequence Number is omitted, the sequence is presumed to be unknown or irrelevant.
XML Tag 
ElementSequenceNumber
XML Model <xsd:simpleType id="ElementSequenceNumber_type">
<xsd:restriction base="xsd:integer" />
</xsd:simpleType>
XML Example <CompleteLandmark Separator=",">
<LandmarkName ElementSequenceNumber="1" >CAMP CURRY</LandmarkName>
<LandmarkName ElementSequenceNumber="2" >YOSEMITE NATIONAL PARK</LandmarkName>
</CompleteLandmark>
Quality Measures Element Sequence Number Measure
Related Element Uniqueness Measure
Uniqueness Measure
Quality Notes
Element Name GNISFeature ID
Other common names for this element (Obsolete) FIPS Codes for populated places (FIPS 5-5), counties (FIPS 6-4), and states (FIPS 5-2) (all subsumed and superseded by GNISFeature ID)
Definition "A permanent, unique number assigned to a geographic feature for the sole purpose of uniquely identifying that feature as a record in any information system database, dataset, file, or document and for distinguishing it from all other feature records so identified. The number is assigned sequentially (highest existing number plus one) to new records as they are created in the Geographic Names Information System."
Definition Source Geographic Names Project, USGS, 523 National Center, Reston, VA 20192-0523, as posted August 25, 2009 at: http://geonames.usgs.gov/domestic/metadata.htm "Feature Identifier"
Data Type Integer
Existing Standards for this Element U.S. Geological Survey, 19810501, U.S. Geographic Names Information System (GNIS): U.S. Geological Survey, Reston, VA.
Domain of Values for this Element Integers from 1 to 9,999,999,999 inclusive.
Source of Values U.S. Geological Survey, 19810501, U.S. Geographic Names Information System (GNIS): U.S. Geological Survey, Reston, VA. Accessible at: http://geonames.usgs.gov/domestic/index.html
How Defined (eg, locally, from standard, other) Assigned within U.S. Geographic Names Information System (GNIS)
Example 531676 - United States Department of the Interior Building, Washington DC
1658360 - Curry Village, Yosemite National Park, CA (Old FIPS55 Place Code: 17638)
1248001 - Florence County, SC (Old FIPS55 Place Code: 99041)
Notes/Comments 1. The Geographic Names Information System (GNIS) is the Federal and national standard for geographic nomenclature. The U.S. Geological Survey developed the GNIS in support of the U.S. Board on Geographic Names as the official repository of domestic geographic names data, the official vehicle for geographic names used by all departments of the Federal Government, and the source for applying geographic names to Federal electronic and printed products.
The GNIS contains information about physical and cultural geographic features of all types in the United States, associated areas, and Antarctica, current and historical, but not including roads and highways. The database holds the Federally recognized name of each feature and defines the feature location by state, county, USGS topographic map, and geographic coordinates. Other attributes include names or spellings other than the official name, feature designations, feature classification, historical and descriptive information, and for some categories the geometric boundaries.
The GNIS collects data from a broad program of partnerships with Federal, State, and local government agencies and other authorized contributors, and provides data to all levels of government, to the public, and to numerous applications through a web query site, web map and feature services, file download services, and customized files upon request. (Quoted August 25, 2009 from http://geonames.usgs.gov/domestic/index.html )
2. "The [GNIS Feature Identifier] number, by design, carries no information or association to the content of the feature record and therefore is not subject to change as attribute values change. Once assigned to a feature, the number is never changed or withdrawn, and never reassigned. The Feature ID can be applied in conjunction with system-unique record identifiers in any database or system, thus providing a national standard common reference identifier across multiple datasets. The Feature ID is stored in the GNIS database as an integer with a maximum of ten digits. (Source: Geographic Names Project, USGS, 523 National Center, Reston, VA 20192-0523.)" (Quoted August 25, 2009 from: http://geonames.usgs.gov/domestic/metadata.htm "Feature Identifier")
3. The Board of Geographic Names has set forth its principles, policies, and procedures for recognizing and standardizing domestic geographic names in its "Principles, Policies, and Procedures," posted at: http://geonames.usgs.gov/domestic/policies.htm
4. In the context of the address standard, GNISFeature ID is applicable primarily to Landmark Names, Place Names and State Names. GNIS also includes the names of natural features, which are generally outside the scope of the address standard.
5. The Board of Geographic Names seeks to include in GNIS all feature names of public interest. Local authorities are encouraged to submit local feature names that are not already included in GNIS.
6. GNIS offers useful guidance to address authorities in selecting one name as a standard where several variants exist. GNISFeature ID's, if assigned to Landmark Names or Place Names, can help reconcile minor name variations that can frustrate computer matches (e.g., DeKalb, Dekalb, De Kalb). GNISFeature ID's also provide a way to link a preferred local variant name to a nationally-recognized standard.
7. GNIS provides a primary location point (x, y coordinate) for each feature. The GNIS primary point will in many cases differ from address coordinates assigned to the same feature by the addressing authority, due to differences in procedure and precision. GNIS procedures are described at: http://geonames.usgs.gov/domestic/metadata.htm "Primary Point".
XML Tag 
GNISFeatureID
XML Model <xsd:simpleType id="GNISFeatureID_type">
<xsd:restriction base="xsd:integer" />
</xsd:simpleType>
XML Example <CompleteLandmark Separator=",">
<LandmarkName ElementSequenceNumber="0" GNISFeatureID="1658360" >CURRY VILLAGE</LandmarkName>
<LandmarkName Element Sequence Number="1">YOSEMITE NATIONAL PARK</LandmarkName>
</CompleteLandmark>
Quality Measures Spatial Domain Measure
Tabular Domain Measure
Quality Notes
Element Name Location Description
Other common names for this element Additional Location Information
Definition A text description providing more detail on how to identify or find the addressed feature.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element No
Source of Values None
How Defined (eg, locally, from standard, other) Locally
Example "White house at intersection.", "400 yards west of water tank."
Notes/Comments
XML Tag <
LocationDescription
>
XML Model <xsd:simpleType id="LocationDescription_type">
<xsd:restriction base="xsd:string"></xsd:restriction>
</xsd:simpleType>
XML Example <LocationDescription>White house at intersection</LocationDescription>
Quality Measures Location Description Field Check Measure
Quality Notes
Element Name MailableAddress
Other common names for this element
Definition Identifies whether an address should have USPS mail sent to it.
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element Yes, No, Unknown
Source of Values New
How Defined (eg, locally, from standard, other) New definition
Example 1391 North Oak Street (apartment building): Mailable Address = Yes
645 Maine Avenue (vacant lot): Mailable Address = No
701 Lee Street (business): Mailable Address = Yes
703 Lee Street (vacant storefront): Mailable Address = Yes
1440 Golden Gate Avenue (recreational field, no structures): Mailable Address = No
6813 Homestead Road (residence, in USPS home delivery area): Mailable Address = Yes
49984 Aspen Road (residence, outside USPS home delivery area): Mailable Address = No
Notes/Comments 1. The Mailable Address attribute indicates whether USPS mail should be sent to the address. This attribute is useful in determining where not to send notices or correspondence via USPS mail.
2. There are many addressed features where USPS mail cannot be delivered: vacant lots, pumping stations, parking lots, structures under construction or destroyed by disaster, and undeveloped parklands, for example. These addresses would have a Mailable Address = No.
3. There are many addressed, occupied features, including residences, businesses, and other features which have been addressed to facilitate the provision of E-911 and on-emergency services, and for other types of premises-based delivery services, but which are not served by premises-based USPS delivery. It is important that these location (situs) addresses not be confused with mailable addresses. The thoroughfare addresses assigned to these features, while appearing to be mailable, would be Mailable Address = No.
4. In addition, many addresses are in areas where the USPS delivers mail to a PO Box, Rural Route Box, or General Delivery address, not to the premises address. These premise addresses also would have a Mailable Address = No.
5. Postal Delivery Address Class addresses (e.g., PO Box, RD Route, and General Delivery addresses) all have a Mailable Address value = Yes, except in unusual circumstances such as the temporary closure of a Post Office.
6. The USPS ZIP+4 address validation service cannot be used to determine whether an address is mailable or not. The USPS ZIP+4 address validation service only validates street name and address range to a ZIP Code. Thus a vacant, addressed parcel would potentially validate as mailable if it fell within an address range on a street that was verified within the ZIP Code.
7. The Mailable Address attribute can also be used to identify addresses where mail delivery has been temporarily suspended due to a large-scale natural disaster or other event.
8. The Mailable Address attribute is not intended for tracking normal vacancies due tenant turnover or change in ownership. It should be set to "No" only if mail cannot be delivered because of USPS delivery rules or long-term physical conditions at the address.
XML Tag < 
MailableAddress
>
XML Model <xsd:simpleType id="MailableAddress_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
<xsd:enumeration value="Yes" >
<xsd:annotation>
<xsd:documentation>The USPS delivers mail to this address.</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="No" >
<xsd:annotation>
<xsd:documentation>The USPS does not deliver mail to this address.</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="Unknown" >
<xsd:annotation>
<xsd:documentation>It is unknown whether the USPS delivers mail to this address.</xsd:documentation>
</xsd:annotation></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <MailableAddress>Yes</MailableAddress>
Element Name Official Status
Other common names for this element Official address, legal address, alias address, alternate address, variant address
Definition Whether the address, street name, landmark name, or place name is as given by the official addressing authority (official), or an alternate or alias (official or unofficial), or a verified error.
Definition Source New
Data Type characterString
Existing Standards for this Element No
Domain of Values for this Element 1. Official
2. Alternate or Alias
---2.1 Official Alternate or Alias
------2.1.1 Alternate Established by an Official Renaming Action of the Address Authority
------2.1.2 Alternates Established by an Address Authority
---2.2 Unofficial Alternate or Alias
------2.2.1 Alternate Established by Colloquial Use
------2.2.2. Unofficial Alternate in Frequent Use
------2.2.3. Unofficial Alternate in Use by Agency or Entity
------2.2.4. Posted or Vanity Address
3. Verified Invalid
Source of Values New
How Defined (eg, locally, from standard, other) New
Example See notes below.
Notes/Comments 1. Official
The address or name as designated by the Address Authority.
2. Alternate or Alias
An alternate or alias to the official address or name that is also in official or popular use. The Related Address ID can be used to link an alternate or alias to the Address ID of the official address. There are two types of alternate or alias names, official and unofficial, each of which has subtypes.
2.1 Official Alternate or Alias: These are alternate names designated by an official Address Authority. Subtypes include, but are not limited to:
2.1.1 Official Renaming Action of the Address Authority
An Address Authority may replace one address or name with another, e.g. by renaming or renumbering. The prior, older address should be retained as an alias, to provide for conversion to the new address.
2.1.2 Alternates Established by an Address Authority
An Address Authority may establish a name or number to be used in addition to the official address or name. For example, a state highway designation (State Highway 7) may be given to a locally-named road, or a memorial name may be applied to an existing street by posting an additional sign, while the local or original name and addresses continue to be recognized as official.
2.2 Unofficial Alternate or Alias: These are addresses or names that are used by the public or by an individual, but are not recognized as official by the Address Authority: Some examples include, but are not limited to:
2.2.1 Alternates Established by Colloquial Use in a Community
An address or name that is in popular use but is not the official name or an official alternate or alias.
2.2.2 Unofficial Alternates Frequently Encountered
In data processing, entry errors occur. Such errors if frequently encountered may be corrected by a direct match of the error and a substitution of a correct name.
2.2.3 Unofficial Alternates In Use by an Agency or Entity
For data processing efficiency, entities often create alternate names or abbreviations for internal use. These must be changed to the official form for public use and transmittal to external users.
2.2.4 Posted or Vanity Address
An address that is posted, but is not recognized by the Address Authority (e.g. a vanity address on a building);
3. Verified Invalid
An address that has been verified as being invalid, but which keeps appearing in address lists. Different from Unofficial Alternate Names in that these addresses are known not to exist.
XML Tag < 
OfficialStatus
>
XML Model <xsd:simpleType id="OfficialStatus_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
Whether the address, street name, landmark name, or place name is as given by the official addressing
authority (official), or an alternate or alias (official or unofficial), or a verified error.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
<xsd:enumeration value="Official" >
<xsd:annotation>
<xsd:documentation>
The address or name as designated by the Address Authority.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Alternate or Alias" >
<xsd:annotation>
<xsd:documentation>
An alternate or alias to the official address or name that is also in official or popular use.
The Related Address ID can be used to link an alternate or alias to the Address ID of the
official address. There are two types of alternate or alias names, official and
unofficial, each of which has subtypes.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Official Alternate or Alias" >
<xsd:annotation>
<xsd:documentation>
These are alternate names designated by an official Address Authority.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Official Renaming Action of the Address Authority" >
<xsd:annotation>
<xsd:documentation>An Address Authority may replace one address or name with another, e.g. by renaming or renumbering. The prior, older address should be retained as an alias, to provide for conversion to the new address.</xsd:documentation></xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Alternates Established by an Address Authority" >
<xsd:annotation>
<xsd:documentation>An Address Authority may establish a name or number to be used in addition to the official address or name. For example, a state highway designation (State Highway 7) may be given to a locally-named road, or a memorial name may be applied to an existing street by posting an additional sign, while the local or original name and addresses continue to be recognized as official.</xsd:documentation></xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Unofficial Alternate or Alias" >
<xsd:annotation>
<xsd:documentation>
These are addresses or names that are used by the public or by an individual, but are not
recognized as official by the Address Authority.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Alternate Names Established by Colloquial Use in a Community" >
<xsd:annotation>
<xsd:documentation>An address or name that is in popular use but is not the official name or an official alternate or alias. </xsd:documentation></xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Unofficial Alternate Names Frequently Encountered" >
<xsd:annotation>
<xsd:documentation>In data processing, entry errors occur. Such errors if frequently encountered may be corrected by a direct match of the error and a substitution of a correct name.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Unofficial Alternate Names In Use by an Agency or Entity" >
<xsd:annotation>
<xsd:documentation>For data processing efficiency, entities often create alternate names or abbreviations for internal use. These must be changed to the official form for public use and transmittal to external users.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Posted or Vanity Address" >
<xsd:annotation>
<xsd:documentation>An address that is posted, but is not recognized by the Address Authority (e.g. a vanity address on a building);</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="Verified Invalid" >
<xsd:annotation>
<xsd:documentation>
An address that has been verified as being invalid, but which keeps appearing in address
lists. Different from Unofficial Alternate Names in that these addresses are known not to exist.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <OfficialStatus>Official Renaming Action of the Address Authority</OfficialStatus>
Quality Measures Tabular Domain Measure
Official Status Address Authority Consistency Measure
Quality Notes Each locality will have records describing conditions associated with a given Official Status. While the nature of these records and methods for checking correspondence between entries are beyond the scope of the standard, they may be considered in a local quality program.
Element Name PlaceNameType
Other common names for this element Type of Place Name
Definition The type of Place Name used in an Address
Definition Source The element definition is new. The definitions of the specific examples given below (community, municipal, etc.) are new and partly adapted from:
1. FGDC's "Framework Data Content Standard Part 5: Governmental unit and other geographic area boundaries"; and,
2. USPS Publication 28, Section 292, "Urbanization."
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element Community, Municipal, USPS, County, Region, Unknown. Additional values may be created as needed.
Source of Values Locally determined
How Defined (eg, locally, from standard, other) Community: The name of an area, sector, or development, such as a neighborhood or subdivision in a city, or a rural settlement in an unincorporated area, that is not an incorporated general-purpose local government or county. The name may arise from official recognition or from popular usage.
Municipal: The name of the general-purpose local government (if any) where the address is physically located.
USPS: A place name listed in the USPS City State File for delivery of mail to an address.
County: The county or county equivalent where the address is physically located.
Region: The name of the region where the address is physically located. Typically this is the name of the central city within the region. If precisely-defined names are needed, Census terms and definitions may be applied, but popular usage is often imprecise and to some extent subjective.
Unknown: The Place Name Type is not known.
Example A part of the Regent Square neighborhood is within Swissvale Borough, just outside the city limits of Pittsburgh, PA. It is served by the Wilkinsburg post office. The following place names might be used for this part of the neighborhood:
Community: Regent Square
Municipal: Swissvale
USPS: Wilkinsburg
County: Allegheny
Region: Pittsburgh
Notes/Comments 1. Place Name Type is an attribute of the Place Name element. It is used to show what kind of place name is given for the address.
XML Tag 
PlaceNameType
XML Model <xsd:simpleType id="PlaceNameType_type">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Community" >
<xsd:annotation>
<xsd:documentation xml:lang="en">
The name of an area, sector, or development, such as a neighborhood or subdivision in a city, or a rural settlement in an unincorporated area, that is not an incorporated general-purpose local government or county. The name may arise from official recognition or from popular usage.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="USPS" >
<xsd:annotation>
<xsd:documentation xml:lang="en">
The name assigned to the post office from which the USPS delivers mail to the address.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Municipal" >
<xsd:annotation>
<xsd:documentation xml:lang="en">
The name of the general-purpose local government (if any) where the address is physically located.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="County" >
<xsd:annotation>
<xsd:documentation xml:lang="en">
the county or county equivalent where the address is physically located.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Region" >
<xsd:annotation>
<xsd:documentation xml:lang="en">
The name of the region where the address is physically located. Typically this is name of the central city within the region. For precise, systematic terms, Census terms and definitions may be applied, but popular usage is often imprecise and to some extent subjective.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="Unknown" >
<xsd:annotation>
<xsd:documentation xml:lang="en">
The PlaceNameType is not known.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:pattern value=".+"></xsd:pattern>
</xsd:restriction>
</xsd:simpleType>
XML Example <PlaceName PlaceNameType="County" >Shelby</PlaceName>
<PlaceName PlaceNameType="USPS" >Washington</PlaceName>
<PlaceName PlaceNameType="Community" >Urbanizacion Los Olmos</PlaceName>
Quality Measures Tabular Domain Measure
Quality Measures Place Name Type classifications are locally determined. Validation routines should be written to test against local rules. Tabular Domain Measure can test for consistent use of the Place Name Type values for a given area.
Element Name Related Address ID
Other common names for this element
Definition The identifier of an address that is related to the identifier of another address.
Definition Source New
Data Type characterString
Existing Standards for this Element None
Domain of Values for this Element None
Source of Values None
How Defined (eg, locally, from standard, other) Locally
Examples: See examples under Address Relation Type
Notes/Comments 1. The Related Address ID is used to relate one address identifier to another address identifier.
2. In database terms, the Related Address ID is linked to the Address ID in a linking table or relationship table. Logically, a Related Address ID cannot exist unless it is associated with an Address ID.
3. In some cases, the Related Address ID designates an alternate address at the same location, for example, a Landmark Address associated with a Numbered Thoroughfare Address, or an official address with its alias, or a retired address in the same location as an active address.
4. In other cases, the Related Address ID designates an address at a different location, for example, the address of a property owner (if the owner does not live on the property), or a property's tax billing address (if it is sent to the mortgage holder).
5. The Address Relation Type attribute can be used to record how the address identified by the Related Address ID is related to the address identified by the Address ID. (See Address Relation Type example and notes for additional discussion of Related Address ID.)
XML Tag < 
RelatedAddressID
>
XML Model <xsd:complexType id="RelatedAddressID_type">
<xsd:simpleContent>
<xsd:extension base="addr_type:AddressID_type">
<xsd:attribute id="AddressRelationType" type="addr_type:AddressRelationType_type" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
XML Example <RelatedAddressID Address Relation Type="Historical Predecessor" >250</RelatedAddressID>
Quality Measures RelatedElementUniquenessMeasure
Related Not Null Measure
Tabular Domain Measure
Quality Notes
Element Name RelatedTransportationFeatureID
Other common names for this element
Definition The unique identifier assigned (within the reference transportation base model) to a transportation feature to which an address is related.
Data Type characterString
Existing Standards for this Element U.S. Federal Geographic Data Committee, "Framework Data Content Standard Part 7: Transportation base."
"Framework Data Content Standard Part 7c: Roads."
Domain of Values for this Element Constrained by reference transportation base model.
Source of Values Reference transportation base model.
How Defined (eg, locally, from standard, other) Within the reference transportation base model.
Example 786542
Notes/Comments 1. Thoroughfare addresses (other than Intersection Addresses) are represented within a transportation base model as point events or linear events, each with a unique Address Transportation Feature ID. These point events and linear events may, in turn, be related to one or more transportation segments within the transportation base model. The transportation segment must have a Complete Street Name and an address range that includes the Complete Street Name and Complete Address Number of the address.
2. The Related Transportation Feature ID provides the ID, as assigned within the transportation base model, of the related segment.
4. Intersection Addresses are related to one or more transportation points within the transportation data model. For Intersection Addresses, the TranPoint ID would be placed within the Related Transportation Feature ID element.
XML Tag < 
RelatedTransportationFeatureID
>
XML Model <xsd:simpleType id="RelatedTransportationFeatureId_type">
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <RelatedTransportationFeatureID>786542</RelatedTransportationFeatureID>
Quality Measures Related Element Uniqueness Measure
Quality Notes
Element Name Subaddress Component Order
Other common names for this element None
Definition The order in which Subaddress Type and Subaddress Identifier appear within a Subaddress Element
Definition Source New
Data Type Integer
Existing Standards for this Element None
Domain of Values for this Element 1 = Subaddress Type first, then Subaddress Identifier (or: Subaddress Element does not include a Subaddress Type).
2 = Subaddress Identifier first, then Subaddress Type.
3 = Not stated.
Source of Values New
How Defined (eg, locally, from standard, other) Within this standard
Example 1. Room 212 (Subaddress Component Order = 1 = "Room" (the type) precedes "212" (the identifier))
2. Empire Room (Subaddress Component Order = 2 = "Room" (the type) follows "Empire" (the identifier))
3. Mezzanine (Subaddress Component Order = 1 = "Mezzanine" (the identifier) only; no type is given.)
4. Floor 5 (Subaddress Component Order = 1 = "Floor" (the type) precedes "5" (the identifier))
5. Fifth Floor (Subaddress Component Order = 2 = "Floor" (the type) follows "Fifth" (the identifier))
6. Terrace Ballroom (Subaddress Component Order = 2 --this would refer to a ballroom, the "Terrace" ballroom)
7. Ballroom Terrace (Subaddress Component Order = 2 --this would refer to a terrace, the "Ballroom" terrace)
Notes/Comments 1. This attribute tells data users how to construct an Subaddress Element from its component Subaddress Type and Subaddress Identifier. There are three possibilities, described below. The order is usually obvious for any given record, but if there are a large number of records it may not be feasible to examine each record individually. This attribute supports automated procedures for composing Subaddress Elements.
2. Usually a Subaddress Element is composed of a Subaddress Type followed by a Subaddress Identifier (e.g. "Room 212", "Floor 5")
3. However, if the Subaddress Identifier is a name or an ordinal number, it typically precedes the Subaddress Type (e.g. "Empire Room", "Fifth Floor")
4. Occasionally a Subaddress Element includes only a Subaddress Identifier (e.g. "Mezzanine", "Penthouse", "Rear"). These cases are grouped under Type 1.
5. Usually the component order is obvious upon examination, but ambiguous cases occur, such as "Terrace Ballroom" and "Ballroom Terrace" above. In these cases the order can be determined only by field examination or reference to authoritative records.
XML Tag 
SubaddressComponentOrder
XML Model <xsd:simpleType id="SubaddressComponentOrder_type">
<xsd:restriction base="xsd:integer">
<xsd:enumeration value="1">
<xsd:annotation>
<xsd:documentation>SubaddressType first, then Subaddress Identifier (or: Subaddress Element does not include an Subaddress Type).
Example: "Floor 7"</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="2">
<xsd:annotation>
<xsd:documentation>SubaddressIdentifier first, then Subaddress Type.
Example: "Empire Room"</xsd:documentation>
</xsd:annotation></xsd:enumeration>
<xsd:enumeration value="3">
<xsd:annotation>
<xsd:documentation>Order is not known or unstated.</xsd:documentation>
</xsd:annotation></xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
XML Example <CompleteSubaddress>
<SubaddressElement Element Sequence Number="1" "SubaddressComponentOrder="1" >
<SubaddressType>Building</SubaddressType>
<SubaddressIdentifier>A</SubaddressIdentifier>
</SubaddressElement>
<SubaddressElement Element Sequence Number="1" SubaddressComponentOrder="2" >
<SubaddressType>Room</SubaddressType>
<SubaddressIdentifier>Empire</SubaddressIdentifier>
</SubaddressElement>
</CompleteSubaddress>
Quality Measures Tabular Domain Measure
Subaddress Component Order Measure
Quality Notes
Element Name USNationalGridCoordinate
Other common names for this element USNG Coordinate
Definition The USNG is an alphanumeric point reference system that overlays the Universal Transverse Mercator (UTM) numerical coordinate system.
A USNG coordinate consists of three parts, the:
1. Grid Zone Designation (GZD) for worldwide unique geoaddresses (two digits plus one letter, developed from the UTM system).
2. 100,000-meter Square Identification for regional areas (two letters).
3. Grid Coordinates for local areas (always an even number of digits between 2 and 10 depending upon precision).
Definition Source Adapted from US National Grid, FDGC-STD-011-2001, Section 3.3
Quoted from: Tom Terry, "The United States National Grid." Professional Surveyor Magazine. Oct. 2004, p. 12.
Data Type characterString
Required Element No
Existing Standards for this Element US National Grid, FGDC-STD-011-2001.
Domain of Values for this Element No
Source of Values
How Defined (from standard, other) As prescribed in FGDC-STD-011-2001.
Example 18SUJ2348306479 or 18S UJ 23483 06479

18S Identifies a GZD
18S UJ Identifies a specific 100,000-meter square in the specified GZD
18S UJ 2 0 - Locates a point with a precision of 10 km
18S UJ 23 06 - Locates a point with a precision of 1 km
18S UJ 234 064 - Locates a point with a precision of 100 meters
18S UJ 2348 0647 - Locates a point with a precision of 10 meters
18S UJ 23483 06479 - Locates a point with a precision of 1 meter
Notes/Comments 1. USNG basic coordinate values and numbering are identical to Universal Transverse Mercator (UTM) coordinate values over all areas of the United States including outlying territories and possessions. The USNG is based on universally defined coordinate and grid systems and can, therefore, be easily extended for use world-wide as a universal grid reference system.
2. USNG coordinates shall be identical to the Military Grid Reference System (MGRS) numbering scheme over all areas of the United States including outlying territories and possessions.
3. While their coordinates are the same, the key difference between MGRS and USNG is in the organization of their 100,000-m Square Identification schemes. MGRS uses two 100,000-m Square Identification lettering schemes, depending on which datum is used, while USNG uses only the single scheme associated with NAD 83/WGS 84. When USNG values are referenced to NAD 83/WGS 84, USNG and MGRS values are identical and MGRS can be used as a surrogate when software does not yet support USNG.
4. The USNG is not intended for surveying, nor is it intended to replace the coordinate reference system used for digital mapping by local authorities (typically, local or state plane coordinate systems). USNG provides a nationally consistent presentation format and grid for public safety, general public, and commercial activities that is user-friendly in both digital and hardcopy products. USNG values enable use of geocoded address point data with low cost consumer grade GPS receivers and properly gridded maps.
5. USNG provides a flexible numbering scheme to accommodate variable precision from tens of kilometers to one meter or higher.
XML Tag < 
USNationalGridCoordinate
>
XML Model <xsd:simpleType id="LocationUSNG_type">
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value='.*' />
</xsd:restriction>
</xsd:simpleType>
XML Example <USNationalGridCoordinate>18SUJ2348306479</USNationalGridCoordinate>
<USNationalGridCoordinate>18S UJ 23483 06479</USNationalGridCoordinate>
Quality Measures Usng Coordinate Spatial Measure
Quality Notes There are a variety of ways to check USNG coordinate values. Due to the complexity of the USNG standard entire working functions are offered as examples, rather than pseudocode: coord2usng, converting Universal Transverse Mercator (UTM) coordinates to USNG, and usng2coord, converting USNG to UTM.
1. The coord2usng function requires both UTM and longitude latitude coordinates, and calculates the UTM zone on the fly. This method was chosen due to common confusion about zone numbers. There are a variety of other ways to structure the conversion.
2. Usng2coord requires only USNG, and is fairly straightforward.

<Previous> <Home> <Up> <Next>