Home » About URISA » Initiatives » Draft Address Data Standard

Draft Address Data Standard - Data Classification

Data Classification

Part 2: Street Address Data Classification
Data classification standards define groups or categories of data that serve an application. There are many valid potential ways to define groups or categories of addresses. The most appropriate way depends on the purpose the classification is intended to serve.

The classification part of this standard is created to serve geographic data processing needs, using the data elements defined in the content part of the standard. The standard classifies addresses according to their syntax, that is, their data elements and the order in which the elements are arranged. Syntax determines the record structure needed to hold and exchange the address, and often it is all we know about the addresses in a given file.

Part 2: Data Classification
(in .pdf form)

 


 

Standard_Part_Section:
Introduction
Type:
Substantive
Name:
Brett Brunk
Organization:
FAA ATO AIM
Organization_Comment:
I am commenting on behalf of my organization.
Email:
brett.brunk@faa.gov
Date:
09 Jan 2006

Comments

The standard should be easy to understand and relationships between complex and simple elements should be easy to see. The pages of tables and tabular cross referencing is inadequate.

Proposed_Changes

Provide a graphic (e.g., UML) that describes the structure and relationships.

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Editorial
Name:
Anne O'Connor
Organization:
U.S. Census Bureau
Organization_Comment:
I am commenting on behalf of my organization.
Email:
anne.v.o.connor@census.gov
Date:
10 Jan 2006

Comments

The 2nd bullet in the Notes refers to "street numbers". Shouldn't this be "address numbers" which you've consistently used throughout the document?

Proposed_Changes

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Editorial
Name:
Anne O'Connor
Organization:
U.S. Census Bureau
Organization_Comment:
I am commenting on behalf of my organization.
Email:
anne.v.o.connor@census.gov
Date:
10 Jan 2006

Comments

There's a typo in the 3rd bullet -- "In the example above, ... , would be one address..."

Proposed_Changes

Add the word 'be'.

Standard_Part_Section:
2.1 Basis for Classification
Type:
Editorial
Name:
Mike Walls
Organization:
Organization_Comment:
Email:
michael.walls@atosorigin.com
Date:
11 Jan 2006

Comments

Clarify focus on syntax of address record.

Proposed_Changes

I suggest adding a comment to the effect that the focus on syntax of the address record rather than the semantics (i.e. meaning) of the address values allows the users of the standard to avoid making any assumptions about what the address might reference "on the ground". This avoids difficult and frustrating efforts to separate mailing addresses from situs addresses from utility service addresses, or to separate addresses for buildings from addresses for signage.

Standard_Part_Section:
2.5 Address Classes - Generally
Type:
Substantive
Name:
Mike Walls
Organization:
Organization_Comment:
Email:
michael.walls@atosorigin.com
Date:
11 Jan 2006

Comments

ZIP Code is mandatory for all address classes.

Proposed_Changes

ZIP Code should be mandatory only for Postal Addresses. It is not necessary for a situs address such as those in Thoroughfare or Landmark classes, and can be misleading if included. ZIP Code geography is defined only for delivery of mail by the USPS -- all other uses are derivative of that function.

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Substantive
Name:
Robert Wolkowitz
Organization:
Midland Loan Services, Inc.
Organization_Comment:
Email:
robert.wolkowitz@midlandls.com
Date:
11 Jan 2006

Comments

When referring to raw land, real estate professionals often refer to the corner of two streets as NEC (northeast corner), SEC (southeast corner), NWC(northwest corner), or SWC(southwest cornder), representing the quadrant of the interesection.

Proposed_Changes

Recommended syntax for 2.5.1.3 Intersection Address: { Quadrant } + { Complete Street Name *} + { Separator Element *} + { Complete Street Name *} + { Place Name *} + { State Name *} + { Zip Code *} + { Zip Plus 4 } + { Nation Name }

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Substantive
Name:
Robert Wolkowitz
Organization:
Midland Loan Services, Inc.
Organization_Comment:
I am commenting on behalf of my organization.
Email:
robert.wolkowitz@midlandls.com
Date:
11 Jan 2006

Comments

When referring to raw land, real estate professionals often refer to the corner of two streets as NEC (northeast corner), SEC (southeast corner), NWC(northwest corner), or SWC(southwest cornder), representing the quadrant of the interesection.

Proposed_Changes

Recommended syntax for 2.5.1.3 Intersection Address: { Quadrant } + { Complete Street Name *} + { Separator Element *} + { Complete Street Name *} + { Place Name *} + { State Name *} + { Zip Code *} + { Zip Plus 4 } + { Nation Name }

Standard_Part_Section:
2.5 Address Classes - Generally
Type:
Substantive
Name:
Steve Grise
Organization:
ESRI
Organization_Comment:
Email:
sgrise@esri.com
Date:
13 Jan 2006

Comments

By concentrating on Landmark and Thoroughfare Addresses (i.e., Address Ranges on Streets), only part of the addressing problem is being considered. GIS users typically assign addresses and named locations to a number of different kinds of features – parcels, buildings, building entrances, landmarks, points of interest, geographic landforms, schools, critical infrastructure, and administrative boundaries. Trying to push all of that into 2 types of addresses will be complex for partners.

Proposed_Changes

I believe you are oversimplifying the geographic location aspects of the information model, and that it will be difficult to integrate all address information without a more geo-centric approach that includes addresses and names for more types of geographic features.

Standard_Part_Section:
2.4 Formatting Conventions
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.4 Formatting Conventions -- Since bolding was removed from all Syntax statements in the Street Address Data Classification section, the last two sentences in this section are no longer valid and can be deleted.

Proposed_Changes

In item 3, delete the last two sentences beginning with “Because they occur in every address class, and always in the same order…”

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.1 Thoroughfare Address Classes -- Thoroughfare Address Classes are not always “designated by a number” as stated in the second sentence. Specifically, 2.5.1.3 Intersection Address and 2.5.1.6 Unnumbered Thoroughfare Address do not include a Complete Address Number in their syntax.

Proposed_Changes

Modify the second sentence to indicate that a thoroughfare name is always specified but an address number is only sometimes specified in a Thoroughfare Address Class.

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.1.1 Site Addresses -- The Examples section provides a good mix of element combinations although noticeably missing is a combination that includes a Zip Plus 4 Element.

Proposed_Changes

In the Examples section, add a Zip Plus 4 Element to one of the existing examples.

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Editorial
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.1.2 Landmark-Site Address -- At the end of the Syntax line there appears to be a misplaced asterisk (*).

Proposed_Changes

Delete the asterisk (*) at the end of the Syntax line following “{Nation Name}”.

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.1.4 Two-number Address Range -- In the Notes section, for consistency there should be a bulleted comment discussing Address Range Parity, similar to the second bulleted comment in 2.5.1.5 Four-number Address Range. It should also indicate that Address Range Parity is a required attribute with the Address Number Range Complex Element.

Proposed_Changes

In the Notes section, add a bulleted comment discussing Address Range Parity, including its requirement as an attribute with the Address Number Range Complex Element.

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Editorial
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.1.4 Two-number Address Range -- In the Notes section, the word “be” is missing from the last sentence.

Proposed_Changes

In the Notes section, add the word “be” in the last sentence: ‘…“214-02 Evergreen St” would be one address…’

Standard_Part_Section:
2.5.1 Thoroughfare Address Classes
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.1.5 Four-number Address Range -- In the Notes section, the second bulleted comment should also indicate that Address Range Parity is a required attribute with the Address Number Range Complex Element for consistency with 2.5.1.4 Two-number Address Range.

Proposed_Changes

In the Notes section, the second bulleted comment should also include a sentence regarding its requirement as an attribute with the Address Number Range Complex Element.

Standard_Part_Section:
2.5.2 Landmark Address Classes
Type:
Editorial
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.2.2 Multi-Site Landmark Address -- In the Examples section, the Zip Code in the second example is missing a zero.

Proposed_Changes

In the Examples section, change the “1001” Zip Code in the second example to “10004”.

Standard_Part_Section:
2.5.2 Landmark Address Classes
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.2.3 Community (Urbanization) Address -- Since the Examples Section only provides Puerto Rican addresses, someone could incorrectly assume that this Landmark Address Class only applies to addresses in Puerto Rico. An example in the continental United States should be included.

Proposed_Changes

In the Examples section, add the following valid address in New York City that utilizes a Community Place Name: “23B Edgewater Park, Bronx, NY 10465”

Standard_Part_Section:
2.5.2 Landmark Address Classes
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.2.3 Community (Urbanization) Address -- In the Notes section, “number” and “landmark class” in the second bulleted comment are a little too broad and could use further clarification.

Proposed_Changes

In the Notes section, change the second bulleted comment to: “If no Address Number precedes the Urbanization Name, the address fits into one of the Address Landmark Classes.

Standard_Part_Section:
2.5.2 Landmark Address Classes
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.2.3 Community (Urbanization) Address -- In the Notes section, “Landmark-site class” in the third bulleted comment could be confused as a Landmark Address Class, especially with the reference to the Address Landmark Class in the preceding bulleted comment. It is suggested that the class be further clarified as a Thoroughfare Address Class.

Proposed_Changes

In the Notes section, change the third bulleted comment to: “If the address includes a reference to a thoroughfare, the address fits in the “Landmark-Site Address” Thoroughfare Address Class.

Standard_Part_Section:
2.5.3 Postal Delivery Address Classes
Type:
Substantive
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.3.2 USPS Postal Delivery Route -- At the beginning of the Type 3: Overseas Military Delivery Syntax line, “(PSC, CMR, or UNIT):” duplicates the first element name in the Syntax line and causes confusion.

Proposed_Changes

In the beginning of the Type 3: Overseas Military Delivery Syntax line, delete “(PSC, CMR, or UNIT):”

Standard_Part_Section:
2.5.3 Postal Delivery Address Classes
Type:
Editorial
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.3.3 USPS General Delivery Address -- In the General Delivery Note and Example section, the example shown is a single, complete mailing address. It is not two separate examples.

Proposed_Changes

In the General Delivery Note and Example section, change the “Example:” heading to “Complete Example:” and remove the two open circle bullet symbols.

Standard_Part_Section:
2.5.3 Postal Delivery Address Classes
Type:
Editorial
Name:
Cheryl Benjamin
Organization:
NYS GIS Standards & Data Coordination Work Group
Organization_Comment:
I am commenting on behalf of my organization.
Email:
cheryl.benjamin@cscic.state.ny.us
Date:
13 Jan 2006

Comments

2.5.3.3 USPS General Delivery Address -- In the Overseas Military Addresses and Notes and Example section, the Complete Example shown at the end of the section is a single, complete mailing address. It is not two separate examples.

Proposed_Changes

In the Overseas Military Addresses and Notes and Example section, and remove the two open circle bullet symbols.

Standard_Part_Section:
2.5 Address Classes - Generally
Type:
Substantive
Name:
wendy blake-coleman
Organization:
USEPA
Organization_Comment:
I am commenting on behalf of my organization.
Email:
blake-coleman.wendy@epa.gov
Date:
16 Jan 2006

Comments

The entire section on Address Attributes does not appear to be directly relevant to a Street Address data standard. The need for it is questionable. The duplicative nature of these elements to a locational coordinate data standard seems apparent.

Proposed_Changes

Standard_Part_Section:
2.5 Address Classes - Generally
Type:
Substantive
Name:
Patricia Brown
Organization:
Harris Corporation
Organization_Comment:
I am commenting on behalf of my organization.
Email:
pbrown01@harris.com
Date:
17 Jan 2006

Comments

There does not appear to be an identifier in the standards that can be used to associate multiple addresses that refer to the same feature. I have read the rationale provided in response to this comment on the first draft. Nonetheless, it would seem that the exchange of data would be simplified, improved and facilitated if there were an ID associated with the addressable feature, not just the address record itself. This would allow agencies to communicate corrections and renamings and to associate the unabbreviated official address with aliases and abbreviated versions which might have been used in the past or may be in common use in other contexts, such as MSAG. Alternatively, additional field(s) could be provided to allow data originators to store abbreviations (including, for example, the name as it appears on street signs), aliases and so on. The record would be the official representation with zero to many alternative versions or aliases for each record.

Proposed_Changes

Include a means to communicate the fact that two addresses refer to the same feature (e.g. are aliases or abbreviations) through the exchange standard.

Standard_Part_Section:
2.5 Address Classes - Generally
Type:
Substantive
Name:
Patricia Brown
Organization:
Harris Corporation
Organization_Comment:
I am commenting on behalf of my organization.
Email:
pbrown01@harris.com
Date:
17 Jan 2006

Comments

Even after reviewing the first draft and second drafts and the comments to them, I am not sure that I understand the purpose or role of the address classes except as they are used in the data model. Here is a summary of my understanding: 1. There are thirteen address classes, which are usually described in the text at a general level as if there were four address classes. Are there thirteen, or four, address classes? If there are thirteen, I would suggest some clarification wherever the four general classes are described. If there are four, then I’d suggest a clarification at the beginning of section 2.5. 2. The address class is file-level metadata. Therefore, if I had an address database that included Site Addresses, Landmark Sites, and Two Number Address Ranges I’d have to call that General Address at the file level or somehow separate the data into three files, each consisting of records of a single address class. If I’ve misunderstood, then I would suggest that the draft be revised or amended to clarify things. There is some evidence in the XSD that the address class can be assigned at the record level, but the text is not clear on this issue. If address class is assigned at the file level, then I wonder why address class is established at the file level. Of course many, if not most, address databases contain records of various address classes. Is the idea that the various classes will be identified and separated during the export to the exchange format? If so, what is the purpose of the General Address Class? If an originating agency identified the class of each record in the source data, would it be required to create a separate file for each address class, up to thirteen (13) of them?

Proposed_Changes

Clarification of the points mentioned.

» login to post comments