Draft Address Data Standard - Data Content

Data Content

 

Part 1: Street Address Data Content
Data content standards provide semantic definitions of a set of objects. The content part of the street address data standard specifies and defines the data elements which may appear in or describe street, landmark, and postal addresses.

Part 1: Data Content
(in .pdf form)

 

---

---

 

Standard_Part_Section:

1.7.2 Street Name Elements

Type:

Substantive

Name:

Elizabeth M. Wojdak

Organization:

Southern California Association of Governments

Organization_Comment:

Email:

wojdak@scag.ca.gov

Date:

06 Dec 2005

Comments

I would strongly recommend that the commitee use the abbreviations for both street name prefixes and suffixes and not spell them out (i.e.Use N not North). When addresses are maintained in an organization, their purpose is often to generate mailing lists. In order to get a discount on their mail (5.5 cents per letter), they must adhere to the USPS postal standards--which uses the abbreviations. This is because the USPS scanners look for their standards, deviations cause the mail to be sorted by hand, not automated. If your standards are adopted, organizations would need the information stored within their databases both ways, making databases larger than they have to be and who wants to input data twice. Or, they discontinue getting their discount--which is unrealistic--meaining they will not implement your standards. I now work for a MPO, but I worked for a county government agency that mailed 25,000 rent checks out each month for section 8 housing. We set up the USPS Postal satndards so they could get the discount and geocoding of the addresses was easily made. GIS can use the abbreviations just fine. The USPS postal standards should be sufficient in this matter--why re-invent the wheel when the wheel ain't broke.

Proposed_Changes

use the US Postal standards for the prefix and suffixes of street names. E instead of East and ST instead of Street,

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Substantive

Name:

Matthew Gilmore

Organization:

DC government

Organization_Comment:

Email:

matthew.gilmore@dc.gov

Date:

13 Dec 2005

Comments

I wonder at the use of the word "thoroughfare". I believe that conveys more of transitway and we don't really make sure we include other "means of egress" kinds of addresses, such as alleys, walkways, etc.

Proposed_Changes

The term "thoroughfare" should be more rigorously/completely defined to include the whole scope of "means of egress" addresses (walkways are already mentioned) or another term should be considered...I am not sure what that would be--"access" is the broadest but probably too borad.

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Substantive

Name:

Matthew Gilmore

Organization:

OCTO

Organization_Comment:

Email:

matthew.gilmore@dc.gov

Date:

13 Dec 2005

Comments

If we implement the standard correctly and store the data correctly then we merely need the correct translator/transformation to produce a CASS certified/postal standard output. This output product should not govern the standard...since there are many differing outputs we want to produce. The suggestion that we retain or continue to use abbreviations is based on a misunderstanding of standards creation. The standard should set up the clearest, cleanest, most rational organization and population of data.

Proposed_Changes

---

Standard_Part_Section:

1.8.1 Address ID

Type:

Substantive

Name:

Henning Schulzrinne

Organization:

Columbia University

Organization_Comment:

Email:

hgs@cs.columbia.edu

Date:

17 Dec 2005

Comments

The address ID is assumed to be an "integer" of unknown size. It seems plausible that addressing authorities would use alphanumeric data formats of various sorts, given that the entities doing the labeling are left open-ended.

Proposed_Changes

Allow at least XSD token.

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

Name:

Henning Schulzrinne

Organization:

Columbia University

Organization_Comment:

Email:

hgs@cs.columbia.edu

Date:

17 Dec 2005

Comments

The standard can't be complete without specifying the country element. Anything less is likely to lead to unnecessary incompatibility.

Proposed_Changes

All known Internet-related standards use the 2-letter abbreviations (3166), which are widely available, and it would thus be rather strange to invent or use something different.

---

Standard_Part_Section:

Introduction

Type:

Editorial

Name:

Henning Schulzrinne

Organization:

Columbia University

Organization_Comment:

Email:

hgs@cs.columbia.edu

Date:

17 Dec 2005

Comments

It would be helpful to compare the elements to the NENA addressing elements. Many are very similar and one of the largest street-level databases is MSAG data, so conversion between the two formats will be common.

Proposed_Changes

Identify NENA address elements (informative).

---

Standard_Part_Section:

1.7.1 Address Number Elements

Type:

Editorial

Name:

Matthew McCready

Organization:

U.S Census Bureau

Organization_Comment:

Email:

matthew.j.mccready@census.gov

Date:

21 Dec 2005

Comments

There is a missing "be" on page 15. It is in this sentence under the Address Number Range element (section 1.7.1.6). Here is the sentence: In the fourth example above, "214-02 Evergreen St" would one address, and "214-14 1/2 Evergreen Street" would be a second address, and neither one alone is an address range.

Proposed_Changes

I would add the missing "be".

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Editorial

Name:

Lewis Slagle

Organization:

1.7.2 Street Name Elements

Organization_Comment:

Email:

lewis_slagle@calpers.ca.gov

Date:

28 Dec 2005

Comments

After 150 years I think the street names managed by the cities and counties are just fine. The Federal goverment has better things to be concerned with. Like data security, public safety, quility of life in the United States. Don't make life any more difficult.

Proposed_Changes

Fine something more important to do with you idle time.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

Many of the address components have overloaded semantics which makes it difficult to interpret and understand the data element. For example 1.7.1.2 Address number is used to represent Street Number, Building Number, House Number, Site Number, Structure Number.

Proposed_Changes

Its seems like these overloaded data elements should be modeled separately.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

In 1.7.1.2 the distinction that 0 and 1 are numbers and 1/2 is not a number seems arbitrary.

Proposed_Changes

---

Standard_Part_Section:

1.1 Organization

Type:

Substantive

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

I disagree that Address Elements includes all the Larger Areas identified in part 1.7. The location of an address/address point with regard to a government or other type of legal, administrative, or statistical geographic area that is not actually part or required for an address is an Attribute Element, no less than the Address Coordinates. See more detailed comments under the 1.7 portions.

Proposed_Changes

---

Standard_Part_Section:

1.5 Open Discussion Item 2: Use of FIPS Codes and Similar Codes within the Standard

Type:

Substantive

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

Item 1. Bullet 4 The timing for adding a feature into a coding database should not be a consideration for eliminating the need for a code. The code can remain null if nonexistent in the coding database, but if a code exists, it should be used. If anything, having the code identifier in the standard may enhance the response and improve the national Geographic Names Information System that will store the official names and identifiers for features.

Proposed_Changes

---

Standard_Part_Section:

1.5 Open Discussion Item 2: Use of FIPS Codes and Similar Codes within the Standard

Type:

Substantive

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

Item 2. Use of geographic feature codes and identifiers (former Federal Information Processing Standards [FIPS]) or developing American National Standards Institute code standards) facilitate unambiguous and more reliable data exchange. It should be included as a data element whenever and wherever a geographic feature is included. It is a situs attribute that has nothing to do with maintenance or authority. The use of name text fields to identify geographic entities could lead to differences and inconsistencies. This is especially true since the standards and criteria for filling the name fields are not detailed or comprehensive concerning geographic area name. For example, does one include a legal description and how is it represented, thus Birmingham, Birmingham city, city of Birmingham, City of Birmingham, Birmingham (city), et al are all names describing the same feature that for text matching purposes will not match. Codes and identifiers are standardized and less ambiguous.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

Name:

Anne O'Connor

Organization:

U.S. Census Bureau

Organization_Comment:

Email:

anne.v.o.connor@census.gov

Date:

10 Jan 2006

Comments

The Street Address Data Standard has gone beyond its scope by including “Larger-Area Elements” that are not related to addressing. In particular, sections 1.7.5.1. and 1.7.5.2. contain geographic names for features that are not related to addressing requirements. The additional geographic area features are additional attributes or geocoding results. There also can be a question about including even state and equivalent entity and county and equivalent entity data for an address record, especially since these results may differ from the address data (e.g., Ardmore town, Limestone County, Alabama has a postal address for Ardmore, Tennessee in Giles County). I can understand including the higher levels of geography where there is complete and discrete coverage, for example, at the nation, state or equivalent area, or county or equivalent area level, but if included then there needs to be some attribute that defines whether even these names represent the physical location of a delivery point or the postal distribution addressing names. Below the county level there are a variety of local governmental jurisdictions and statistically defined areas that can qualify for inclusion. Admittedly, municipal jurisdiction may be the most important, but it is not the only other geography below the county level. Lastly, the geographic features included do not include American Indian, Alaska Native, and Native Hawaiian entities. In some cases, these areas have sovereign status and a government-to-government relationship with the federal government at least at the same significance as a state. These areas must be added if the standard includes geographic areas that are unrelated to addressing as part of the federal government’s commitments.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

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

1.7.5.1. Should this only apply to urbanizacion in Puerto Rico, which is the only community name that I am aware of that is actually used in addressing. The inclusion of other nebulous types and how these other types apply to an address standard is not explained. I strongly recommend eliminating any geographic feature types that are not part of addressing. If this section is retained for communities other than urbanizacion, with which I do not agree, then the Other common names for this element should include the Board on Geographic Names, Geographic Names Information System (GNIS) types of Populated Place and Locale. I also do not believe that Census designated placename (sic) qualifies and actually is but a portion of the official Federal names list embodied in the GNIS. Please note that the definition does not explain the full class, Community Place Name, but only addresses urbanizacion. Either include a definition of the other types of geographic features that qualify for inclusion in this element, or delete these other types from the valid list of feature types. See comment on definition. Either define and cite the source for other “community place name” types or delete. The Notes/Comments only provide background on Puerto Rico urbanizacion. The standard seems to be creating this element only to store this data, but the Element Name overextends the valid list of features that qualify. If you intend to include neighborhoods and so forth, then define, cite the definition, and provide some notes on what is the spirit of the element. (The example, Capitol Hill neighborhood, has no boundary or definition, either as a class or as a specific area.) Lastly, add as a feature the official American National Standards Institute (ANSI) locality code, which is under development to replace the Federal Information Processing Standards (FIPS) 55 standard. This facilitates data transfer where naming conventions and standards in addressing files might differ. The new ANSI standard will use the official U.S. Board on Geographic Names feature ID as contained in the Geographic Names Information System (GNIS) database. The feature ID is an up to ten-digit numeric value that is unique nationwide. To reiterate, my recommendation is to rename this Element: Urbanizacion and make its definition and application apply only to Puerto Rico addresses.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

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

1.7.5.2 I strongly recommend eliminating this element because it goes beyond the scope of a street address data standard. Municipality is a spatial attribute of an address point that is better left to database designers at the Federal, state, tribal, and local level as additional data and not as part of the national standard. If this element is retained, then the element name needs review. The types of jurisdictions for which an address applies can include many types of areas; the narrow definition of a “municipal” jurisdiction does not take into account the variety of legal governments or administrative areas that may be of interest to collect and carry as data. If the intent only is to add municipal jurisdiction as a spatial attribute, then this seems arbitrary. For example, besides municipal jurisdiction there can be other taxing governments (school district, independent improvement district, etc.), administrative areas (voting precinct, congressional district, police response area, etc.), or programmatic funding areas (designated brownfields, community districts, etc.) Lastly, there can be overlapping jurisdictions since the definition of municipality includes township. For example, the City of Groton, Connecticut makes up a portion of the Town of Groton, both of which are municipal governments by the standards definition. How does one store multiple overlapping jurisdictions, especially if all governmental units beyond those defined as municipal governments are included in the standard. If this element is retained and not redefined to include further geographic area types, the list of Other common names should include, Borough, Town, Municipality, Corporation, Consolidated Government, Metropolitan Government, Unified Government, and maybe others of which I am unaware If this element is retained and not redefined to include further geographic area types, the definition source should acknowledge the Governmental Unit Boundary Standard in some way. The FGDC standards are intended to reference and build upon one another. If this element is retained and not redefined to include further geographic area types, the Source of Values.incorrectly references FIPS Publication 5 (National compendium); the former standard (since withdrawn by the NIST) was the FIPS Publication 55-3, Codes for Named Populated Places, Primary County Divisions, and Other Locational Entities of the United States, Puerto Rico, and the Outlying Areas. This is being replaced by an American National Standards Institute standard, which is under development. Even so, the ultimate sources are state and county governments and the U.S. Census Bureau, which is the maintenance authority for the Governmental Unit Boundary Standard. If this element is retained and redefined to include additional geographic feature types, then the type of feature should be an independent attribute with legal values to include (among others) general-purpose government, special-purpose government, school district, administrative area, statistical area, et al. If this element is retained and not redefined to include further geographic area types, then the type of government should be an independent attribute with legal values to include municipality, county subdivision, consolidated government, et al. If this element is retained, add as a feature the official American National Standards Institute (ANSI) locality code, which is under development to replace the Federal Information Processing Standards (FIPS) 55 standard. This facilitates data transfer where naming conventions and standards in addressing files might differ. The new ANSI standard will use the official U.S. Board on Geographic Names feature ID as contained in the Geographic Names Information System (GNIS) database. The feature ID is an up to ten-digit numeric value that is unique nationwide. In the examples, why is it Birmingham, Alabama and not City of Birmingham or Birmingham city. The feature represented is a place name, not the legal name of the municipal corporation. The example for Castle Rock Township includes the legal description making the examples inconsistent. If the intent is as shown, then the standard needs to define naming standards (or at least guidelines) applied to any data in fields containing geographic feature names. The Notes/Comments field uses a broader definition (tax and service determinations) than the definition of the element, which only applies to municipal corporations. If this element is retained and not redefined to include further geographic area types, then the note/comments should be tailored to municipal corporations rather than the broader usage for taxing authority, which includes other geographic feature types. To reiterate, my recommendation is to remove this data element. If not removed, broaden the definition to features included in the Governmental Unit Boundary Standard and allow for multiple fields of data (a relational database approach) such that an address can be geocoded to multiple levels of taxing and/or administrative authority.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

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

1.7.5.3 Rename the Element Name as City State Mailing Name to conform to USPS PUB 28 section 221 as shown in the examples in section 223. The USPS publication includes both elements in section 22.The example is technically incorrect under the current element name description. The text, “Washington”, is the Mailing City name; the DC is the postal state abbreviation. Add as a feature the official American National Standards Institute (ANSI) locality code, which is under development to replace the Federal Information Processing Standards (FIPS) 55 standard. This facilitates data transfer where naming conventions and standards in addressing files might differ. The new ANSI standard will use the official U.S. Board on Geographic Names feature ID as contained in the Geographic Names Information System (GNIS) database. The feature ID is an up to ten-digit numeric value that is unique nationwide. In the How Defined element, delete references to FIPS City Code, which in itself has no meaning since it references no FIPS publication. If there is a need to refer to the former Federal Information Processing Standards, use FIPS Publication 55-3, Codes for Named Populated Places, Primary County Divisions, and Other Locational Entities of the United States, Puerto Rico, and the Outlying Areas, but with the understanding that this standard has been withdrawn and has not been maintained by the USPS, and thus could be incomplete.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

Name:

Anne O'Connor

Organization:

U.S. Census Bureau

Organization_Comment:

I am commenting on behalf of my organization.

Email:

Anne O'Connor

Date:

10 Jan 2006

Comments

1.7.5.4. General: If this is to represent the county in which the address point is located, include this in the element definition. Add to the common names: Census Area, City and Borough, and Unorganized Borough (Alaska), Municipality (Alaska and the Commonwealth of the Northern Mariana Islands), Municipio (Puerto Rico), City (Maryland, Missouri, Nevada, and Virginia), District (American Samoa), Island (American Samoa and U.S. Virgin Islands) The definition source for a geographic/governmental unit should reference the FGDC standard for these areas and not an internal reference. Below I provide a definition that should be used for both standards. Definition: Change to read, the legal name of the primary legal, administrative, or statistical subdivision of a state or equivalent entity in the United States, Puerto Rico, and the Insular Areas. Change Source of Values to “State (or equivalent area) Legislature/Legislative Acts” The information in How Defined is incorrect. The correct reference is former FIPS Publication 6-4, Counties and Equivalent Entities of the United States, Its Possessions, and Associated Areas. This is being developed as a new American National Standards Institute code standard. [FIPS Publication 5 refers to state names and codes.] Add as a feature the official American National Standards Institute (ANSI) county code, which is under development to replace the Federal Information Processing Standards (FIPS) 6-4 standard. This facilitates data transfer where naming conventions and standards in addressing files might differ. The new ANSI standard will use the same coding standard that was used in FIPS 6-4, that is, a three-character numeric code to represent county or equivalent area.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

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

1.7.5.5. Recommend that this element be deleted. If this feature stores only one entity and that entity is stored simply somewhere else, what is the intent of this record. If the intent is to establish name primacy, then add that as an attribute of the individual features rather than creating a redundant record. Element Name is not appropriate to the feature; it doesn’t seem to be a place name but some sort of concatenation of names. What is the intent of this feature since it is not self-evident from the description or definition? In the definition, all the components are shown as required, although these are not required at the simple level. The format for showing required fields needs to be changed[Section 1.3] since this definition violates that section only requiring that one and only one of these fields be used to fill this field. In the notes/comments, since this is an address standard, my opinion is to have the USPS City Mailing Name always as the preferred name, and thus this data element becomes superfluous.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

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

1.7.5.6 This data element seems to represent a USPS state for City State Mailing Name. This state could be different from the state in which the address point is located. The definition should further elaborate that this field represents the addressing state name as opposed to the geocoded location. In addition, the standard will need to add another element to store the actual site state location. Rename element name from State Name to Postal State Abbreviation since that is the actual data that is described in the examples. Add MP to the list of areas using commonwealth; Add to Other common names for element Territory (AS, GU, and VI) Change Definition Source, Existing Standards, Source of Values, and How Defined to read, “former FIPS Publication 5-2, Codes for the Identification of the States, the District of Columbia, the Outlying Areas of the United States, and Associated Areas. Somehow these sources should reference the original source, that being, USPS Publication 28, Appendix B. In addition, the FIPS standard is being reissued as an American National Standards Institute codes standard, in development. Add as features both the 2-digit former FIPS 5-2 code (noted above) and the official American National Standards Institute (ANSI) locality code, which is under development to replace the Federal Information Processing Standards (FIPS) 55 standard. This facilitates data transfer where naming conventions and standards in addressing files might differ. The new ANSI standard will use the official U.S. Board on Geographic Names feature ID as contained in the Geographic Names Information System (GNIS) database. The feature ID is an up to ten-digit numeric value that is unique nationwide

Proposed_Changes

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Substantive

Name:

Anne O'Connor

Organization:

U.S. Census Bureau

Organization_Comment:

I am commenting on behalf of my organization.

Email:

anne.v.o.connor

Date:

10 Jan 2006

Comments

Insert a new feature: Element Name: Situs State Name Other common names for this element: Situs Commonwealth Name, Situs Territory Name Definition: The name of a state, the District of Columbia, Puerto Rico or one of the insular areas of the United States in which an address/address point record is located; this may differ from the Postal State Abbreviation data element used for mail delivery. Definition Source: Former FIPS Publication 5-2, Codes for the Identification of the States, the District of Columbia, the Outlying Areas of the United States, and Associated Areas; American National Standards Institute state and equivalent area code standard under development. Data Type: Text Existing Standards: FIPS Publication 5-2, Codes for the Identification of the States, the District of Columbia, the Outlying Areas of the United States, and Associated Areas Domain of Values for this Element: Yes Source of Values: FIPS Publication 5-2, Codes for the Identification of the States, the District of Columbia, the Outlying Areas of the United States, and Associated Areas How defined: FIPS Publication 5-2, Codes for the Identification of the States, the District of Columbia, the Outlying Areas of the United States, and Associated Areas Examples: Alabama, District of Columbia, Guam

Proposed_Changes

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Substantive

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

Insert a new feature

Proposed_Changes

Element Name: American National Standards Institute (ANSI) Locality Code Other common names for this element: Geographic Names Information System (GNIS) Identifier (ID), place code Definition: The new ANSI standard will use the official U.S. Board on Geographic Names feature ID as contained in the Geographic Names Information System (GNIS) database. The feature ID is an up to ten-digit numeric value that is unique nationwide. This code is applied to the situs location for whichever geographic entity is appropriate. Definition Source: Under development, American National Standards Institute (ANSI) Locality Code/Geographic Names Information System (GNIS) database Data Type: Number Existing Standards: Under development, American National Standards Institute (ANSI) Locality Code/Geographic Names Information System (GNIS) database Domain of Values for this Element: Yes Source of Values: Under development, American National Standards Institute (ANSI) Locality Code/Geographic Names Information System (GNIS) database How defined: Under development, American National Standards Institute (ANSI) Locality Code/Geographic Names Information System (GNIS) database Examples: 1256, 80968 Notes/Comments: In fixed-field files, the numeric value can be represented with leading zeroes, for the preceding examples, a text fixed-length file would represent the codes as 0000001256 and 0000080968.

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Substantive

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

Insert a new feature

Proposed_Changes

Element Name: American National Standards Institute (ANSI) County and Equivalent Area Code Other common names for this element: county code Definition: A three-character numeric code representing a county or equivalent area in the United States, Puerto Rico, and the Insular Areas. The new ANSI standard will use the existing FIPS 6-4 coding structure. Definition Source: Under development, American National Standards Institute (ANSI) County and Equivalent Area Code (former FIPS Publication 6-4) Data Type: Text (numeric character) Existing Standards: Under development, American National Standards Institute (ANSI) County and Equivalent Area Code (former FIPS Publication 6-4) Domain of Values for this Element: Yes Source of Values: Under development, American National Standards Institute (ANSI) County and Equivalent Area Code (former FIPS Publication 6-4) How defined: Under development, American National Standards Institute (ANSI) County and Equivalent Area Code (former FIPS Publication 6-4) Examples: 001, 510 Notes/Comments: The county code requires a state code to uniquely identify a county or equivalent entity. An alternative is to develop a single code feature element, State County ANSI Code that is the concatenation of the ANSI State and Equivalent Area Code and ANSI County and Equivalent Area Code.

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Substantive

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

Insert a new feature

Proposed_Changes

Element Name: American National Standards Institute (ANSI) State and Equivalent Area Code Other common names for this element: county code Definition: A three-character numeric code representing a state or equivalent area in the United States, Puerto Rico, and the Insular Areas. The new ANSI standard will use the existing FIPS 5-2 coding structure. Definition Source: Under development, American National Standards Institute (ANSI) State and Equivalent Area Code (former FIPS Publication 6-4) Data Type: Text (numeric character) Existing Standards: Under development, American National Standards Institute (ANSI) State and Equivalent Area Code (former FIPS Publication 6-4) Domain of Values for this Element: Yes Source of Values: Under development, American National Standards Institute (ANSI) State and Equivalent Area Code (former FIPS Publication 6-4) How defined: Under development, American National Standards Institute (ANSI) State and Equivalent Area Code (former FIPS Publication 6-4) Examples: 01, 51 Notes/Comments: Since the county code requires a state code to uniquely identify a county or equivalent entity, an alternative is to develop a single code feature element, State County ANSI Code that is the concatenation of the ANSI State and Equivalent Area Code and ANSI County and Equivalent Area Code.

---

Standard_Part_Section:

1.6 Open Discussion Item 3: Start and End Dates

Type:

Substantive

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

On page 9, the first bullet in 1.6 under item 2: I think this may be an overstatement. Do we create new records to account for minor spelling errors in a street name? What about if we placed a secondary street name on the outgoing file but the primary street name came in on the incoming file? I don't know exactly where the line is, but I think the current statement is too broad and we should either be more specific or state that we are talking general concepts.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

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

Page 29, section 1.7.5.4. Isn't "Township" another common name for this element? I had the impression that Pennsylvania had townships instead of counties, for example.

Proposed_Changes

---

Standard_Part_Section:

1.8.3 Descriptive Attributes

Type:

Substantive

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

Page 42, section 1.8.3.3. I think we might need to have more categories for address lifecycle status. I'm not sure that we can always tell exactly what the distinction is between potential and proposed, proposed and active, and active and retired with the way they are defined here, and I'm not even sure why we need potential. The distinction between the categories is according to whom? The provider of the addresses? The examples given for retired address don't account for the case in which a unit bearing that address has never existed. Are these values assigned to addresses on some other file or within a file delivery? If the latter, why would somebody be delivering a retired or deleted record? I don't think this description is complete enough to be clear.

Proposed_Changes

---

Standard_Part_Section:

1.7.2 Street Name Elements

Type:

Substantive

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

While the description of Community Place Name accurately describes how urbanizacion is used in Puerto Rico addresses, it seems inconsistent then that Complex Element: Complete Street Name doesn't include Community Place Name.

Proposed_Changes

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

Type:

Substantive

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

Section 1.7.5.4 should also list municipio (Puerto Rico) as an additional common name.

Proposed_Changes

---

Standard_Part_Section:

1.7.1 Address Number Elements

Type:

Substantive

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

One thing I feel is omitted in Section 1 is a discussion of how to provide a unit identifier for multi-unit structures in which units don't have a formal number on the door. Examples might be 1) a single-family home that's made the basement into a separate apartment, 2) apartments over businesses, 3) apartments over garages, 4) mobile homes out back which receive mail at the same delivery point as a main house. We struggle in MAF updating right now when field staff return addresses like this -- 101 Main Street & 101 Main Street, basement. For the DAAL project, we've trained FRs to call the first address 101 Main Street, upstairs or main house. This also happens when the DSF provides a basic address for a multi-unit structure plus all of the unit addresses -- 101 Elm Street, 101 Elm Street Apt 1, 101 Elm Street Apt 2. Are there three units here or is the unit w/o the unit designation just a delivery point? Your standard should recommend how to store information for these situations.

Proposed_Changes

---

Standard_Part_Section:

1.4 Open Discussion Item 1: Abbreviating Street Directionals and Types - Generally

Type:

Substantive

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

Retain both abbreviated and complete words in the standard. Implement the standard to store the data correctly (abbreviated and complete) and still produce abbreviations on an as-needed basis.

Proposed_Changes

---

Standard_Part_Section:

1.7.2 Street Name Elements

Type:

Substantive

Name:

Mike Walls

Organization:

Organization_Comment:

Email:

michael.walls@atosorigin.com

Date:

11 Jan 2006

Comments

1.7.2.3 proposes handling the "Boulevard" in "Boulevard of the Allies" as a Pre-Type. How would one handle the remainder of this street name?

Proposed_Changes

I recommend a business rule to the effect that if parsing out other elements of the complete street name result in an incoherent Street Name element then the complete street name should be stored in the Street Name. In this example, "Avenue of the Allies" is a street name, not "of the Allies". If this recommendation is not accepted, then please add the "Avenue of the Allies" example to the other street name elements to illustrate how this class of names should be completely parsed.

---

Standard_Part_Section:

1.8.4 Spatial Organization Attributes

Type:

Substantive

Name:

Mike Walls

Organization:

Organization_Comment:

Email:

michael.walls@atosorigin.com

Date:

11 Jan 2006

Comments

1.8.4.4 Address Scheme Origin, 1.8.4.5 Address Scheme Axes and 1.8.4.6 Address Scheme Extent are typed as Geometry, and 1.8.4.7 Address Scheme is typed as Geometry Collection. This presupposes the availability of a GIS representation of these scheme elements, which in many jurisdictions will not exist or not be available to the originator of a transfer data set.

Proposed_Changes

1) Allow NIL in all geometry attributes -- that is, make them optional. 2) Add option for list of named streets for Axes (e.g. grid based on Main and High)and bounding streets for Extent and name of jurisdiction for Extent (e.g. the city limits of "City of X") 3) Add option for intersection or landmark for origin.

---

Standard_Part_Section:

1.8.5 Address Lineage Attributes

Type:

Substantive

Name:

Mike Walls

Organization:

Organization_Comment:

Email:

michael.walls@atosorigin.com

Date:

11 Jan 2006

Comments

1.8.5.4 Addressing Authority does not allow for the ambiguities in authority to be encountered on the ground.

Proposed_Changes

1) Must allow for more than one entry, for overlapping authorities. 2) Must be optional, for circumstances in which no acknowledged authority exists. 3) Should allow detail below jurisdictional level -- that is "County Assessor" rather than just "County" or "City Public Works Dept."

---

Standard_Part_Section:

1.4.2 Considerations for placing complete words in the master record

Type:

Editorial

Name:

Mike Walls

Organization:

Organization_Comment:

Email:

michael.walls@atosorigin.com

Date:

11 Jan 2006

Comments

Emphasize "lossy" nature of abbreviations. The best argument to me for fully spelling out all words in the "primary" address record in the master address list is implied but made sufficiently explicit (or convincing, judging by the comments to date).

Proposed_Changes

Add a paragraph to the effect that abbreviations in a multiple use database inevitably risk data loss. Just as some raster image formats reduce image size through an irrevocable and irreversable loss of detail during compression, abbreviations lose information about the full address. The preferred solution is to store the data with the greatest usable detail, then compress/generalize through abbreviation for EMS and other special needs. If a link is preserved between the primary record and its recognized alternatives, abbreviations are unambiguously expandable when necessary -- as for instance when address information must be shared between two agencies that use different abbreviation rules.

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Substantive

Name:

Richard Block

Organization:

Organization_Comment:

Email:

crblock@rcn.com

Date:

11 Jan 2006

Comments

Having geo-coded many thousands of crime incidents in Chicago, I note the following problems. The standards don't seem to deal adequately with alias names. Lake Shore Dr is also in places U.S. 41 or U.S. 14. Garfield Blvd is often identified as 55th St. In police work in Chicago, crimes occuring in non-addressed areas are treated as if they have an address (eg 4900 s Dan Ryan Expy) or an area in a park. In addition it is not clear how the standard would deal with a five or six way intersections.

Proposed_Changes

---

Standard_Part_Section:

1.1 Organization

Type:

Substantive

Name:

Steve Grise

Organization:

ESRI

Organization_Comment:

Email:

sgrise@esri.com

Date:

13 Jan 2006

Comments

Essentially, this standard is defining a vocabulary for XML-based data exchanges. The vocabulary will be expressed in a set of XML tags and values that are exchanged. It is difficult in these types of standards to be specific enough so that programmers do not have to handle too much chaos in data exchanges. There are a number of examples of standards that have problems along these lines, a few examples that come to mind are the XMI specification (eXtensible Metadata Interchange for CASE tools), and a more basic example is date formats in FGDC metadata. While there is often some guidance on XML tagging approaches in standards, there is usually very little in the way of tools that validate and enforce those rules, and programmers are left trying to handle huge differences in “standard” files. For this reason I encourage you to have very simple exchanges with tight rules and clear formatting instructions. There are several areas where I think the standard will be problematic: I don't have time to enter each one of these concerns separately on the web forms.

Proposed_Changes

a. 1.5 - ID management – there is discussion but no conclusion here. The standard must have specific recommendations here, or the standard should dismiss the idea of incremental add/delete updates to address repositories. Other communities appear to be headed in the following direction: i. Local unique id as assigned by data producer, oriented around their needs, not necessarily globally unique. Format should be a long string and producer should have metadata or a web site that describes how these ids are managed and what they mean. ii. Identification of the data producer, FIPS code will not work, but guidance on a textual description using names would be useful, i.e., Oakland County, CA, Building Services Department. iii. Globally unique identifier using UUID or GUID. This is the computer system handle for an individual object, and the basis of identity for update transactions. iv. It will be difficult to assign equivalencies between data providers on the same objects – for example the Census Bureau and a local Government agency may have street centerlines with the same names and different attributes. It’s not the job of one organization to manage equivalencies to another organization’s datasets or identifiers, unless there is funding or other agreements in place outside of this standard. It’s almost impossible to do this from a data processing standpoint, especially without geometry. b. A description for Add and Delete transactions is provided, but no discussion about Modify or Update transactions is included. There is also no guidance on providing descriptions about the nature of changes that might require further investigation by partners – for instance is it just a correction to existing information, or did address 52 legally change to 54 as a result of new construction? Managing change at individual record levels needs to be clearly defined, and partners need to understand the responsibilities that this type of relationship may introduce into their own data management systems and procedures. A simpler approach would be change detection between 2 XML datasets, and this may meet the needs of many data processing c. Data typing is included in the standard, but in XML everything will be om an XML document that programmers will attempt to “cast” into different datatypes. Correct formatting examples for programmers on both ends of exchanges will have a major impact on cost, implementation complexity, and ability to share information using the standard. d. 4.1.1 - Federal agencies are required to provide FGDC CGDSM metadata. This standard cannot mandate that all address exchanges will correspond to Federal metadata requirements. This standard needs to be precise about the metadata elements required for address exchanges. In addition, since the standard excludes geometry/coordinates in the scope defintion, the datasets are not geospatial in nature and Federal agencies may not be required to provide FGDC metadata. e. 1.8.2.1, 1.8.2.2 – The standard cannot rely on metadata records at the dataset level to handle spatial reference information. Many exchanges will be made up of information from multiple sources. The standard needs to either define a consistent, simple spatial reference for coordinates or include the option to handle this for each feature. The same is likely true for other parts of the metadata record, but it is too general to say that any FGDC metadata could also be supplied at a feature level. The standard needs to define which metadata elements are valid and specify exactly how to format them. f. 1.8.2 - There are too many options for types of X/Y coordinates. Pick one and insist on it. Provide algorithms/guidance on how to transform to/from this approach and other representations, or stick to the scope and ignore geometry. g. 1.8.2.6 - Z values are described as “floor numbers” in buildings, and this doesn’t work for many cases such as mountain peaks. If floor number is the extent of elevation needs, which I doubt, then it should be called “Floor Number”. If it will be Z value, be clear about this and include instructions on which vertical datum to use. h. 1.7.4 – Landmark Addresses – “Generally the use of a landmark's street address is preferable because it is unambiguous.” Actually, the street address for many landmarks is ambiguous. Both Street Address and coordinate locations should be provided for landmarks. Trying to locate many Landmarks along roads is difficult and without a specific set of rules it is complicated. i. 3.7 - The qc rules have pseudocode examples in SQL. This is not appropriate because a) it implies there is a “master database” or this will be the method used for quality control, b) rules such as “non-overlapping” don’t have an example because it can’t work in SQL, c) the examples don’t use the XML-based techniques promoted by the standard. j. 1.7.1.5 (and throughout) The use of a notation with “{ … }” surrounding values is not appropriate. Since this is an XML standard it should use XML tagging examples to clarify the standard and to reduce awkwardness in the text. For example, · { Address Number Prefix } + { Separator Element } + { Address Number *} + { Separator Element } + {Address Number Suffix } · 123 Main Street · 123 A Main Street · 0 Prince Street · 0 1/2 Fifth Avenue · 27N4W305-A County Road 45 · 194-03 1/2 50th Avenue, New York, NY 11365 The examples demonstrate a level of knowledge about addresses, but they don’t provide anyone with an idea of what these addresses look would look like in XML. It also concentrates efforts on breaking down strings into component elements rather than utilizing the power of the XML-based approach to simplify the complexity of these strings.

---

Standard_Part_Section:

1.4 Open Discussion Item 1: Abbreviating Street Directionals and Types - Generally

Type:

Substantive

Name:

Steve Grise

Organization:

ESRI

Organization_Comment:

Email:

sgrise@esri.com

Date:

13 Jan 2006

Comments

1.4 – Discussion point on Abbreviations. Why not have a tagging scheme in XML that supports exchanges using either “full name” or “abbreviation” formats?

Proposed_Changes

support both abbreviation and full name versions of strings with different XML tag names.

---

Standard_Part_Section:

Introduction

Type:

Editorial

Name:

Steve Grise

Organization:

ESRI

Organization_Comment:

Email:

sgrise@esri.com

Date:

13 Jan 2006

Comments

1. Data Content, Introduction. In several places the following phrasing is used: “Data content standards provide semantic definitions of a set of objects”. I don’t think this sentence means much. I think the second sentence could be cleaned up to provide a better introduction: “The Data Content section of the of the street address data standard specifies and defines the data elements which may appear in or describe street, landmark, and postal addresses.”

Proposed_Changes

The Data Content section of the of the street address data standard specifies and defines the data elements which may appear in or describe street, landmark, and postal addresses.

---

Standard_Part_Section:

1.7.3 Building, Floor, and Unit Elements

Type:

Substantive

Name:

Steve Grise

Organization:

ESRI

Organization_Comment:

Email:

sgrise@esri.com

Date:

13 Jan 2006

Comments

1.7.3 – If the goal is to support the development of master address repositories at the federal level, it is worth noting that Local Governments are not typically authorities for building unit and floor addressing. That is usually the responsibility of the property owner. Other organizations can use these descriptive properties for mailing purposes, but they usually have no responsibility for verifying these are legally correct, just useful for mailing purposes. It will be difficult to get organizations to share information about units and other mailing address properties because there may be liability associated with these being perceived/used as authoritative. Also, most local governments don’t have this level of information so it is superfluous for many address exchanges between government organizations. They may, however, be interesting in validating mailing address information to USPS and other standards: is this part of the scope of the standard being described here?

Proposed_Changes

If the goal is the development of a master address repository using this type of exchange, is postal address information something that can be/will be shared between organizations: is there is implied authority/correctness in these exchanges? If the goal is simply to exchange mailing address information, why not just use USPS standards?

---

Standard_Part_Section:

1.3 Notation for Constructing Complex Elements

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

Regarding the last item discussing the concatenation symbol, nowhere in this standard could we find a complex element definition that states spaces are optional or not required between any of the elements constructing the complex element. Only within the simple element 1.7.1.4 Separator Element is there a statement regarding optional spaces between elements. Complex elements containing the Zip Plus 4 element typically (and as shown in examples within the Standard) would not have spaces between the Zip Code and Zip Plus 4 elements, only a separator. Consideration should be given to redefining all complex elements containing Zip Code and Zip Plus 4 elements to include a Separator Element, a notation that spaces are not implied before or after the Separator Element, and indicate if it is required in the complex elements. Another example where this notation would be needed is the last note in 1.7.1.5 Complete Address Number for the New York City-style hyphenated addresses (submitted as a separate comment specific to section 1.7.1.5).

Proposed_Changes

Throughout the Standard, redefine all complex elements containing Zip Code and Zip Plus 4 elements to include a Separator Element and a notation that spaces are not implied before or after the Separator Element. The Classification, Quality, and Transfer Sections of the Standard should also be reviewed for potential changes related to uses of the Separator Element in complex elements.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.2 Address Number -- In the Notes/Comments section, add an example to the third bulleted comment regarding parsing of non-integer elements for further clarification on how non-integer elements are parsed.

Proposed_Changes

Add at the end of the third bulleted comment in the Notes/Comments section: “For example, if the New York City hyphenated address 194-03 ½ 50th Avenue, New York, NY 11365 were to be parsed rather than represented as a Complete Address Number, the Address Number Prefix would be “194”, the Separator would be “-“, the Address Number would be “03” and the Address Number Suffix would be “1/2”.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.4 Separator Element -- The Definition section should also discuss use of the Separator Element between the Zip Code and Zip Plus 4 elements.

Proposed_Changes

Add a sentence to the Definition section to include the use of a Separator Element between the Zip Code Element and Zip Plus 4 Element in complex elements.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.4 Separator Element -- “Complete street number” is used throughout 1.7.1.4 Separator Element to refer to the Complete Address Number complex element. For consistency, the Standard’s official element name should be used rather than an alternate common name.

Proposed_Changes

Throughout section 1.7.1.4 Separator Element, replace “complete street number” with “Complete Address Number”.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.4 Separator Element -- In the Example section, the Separator Elements in the examples need to be bolded for clarity.

Proposed_Changes

In the Example section, bold the hyphens and “and” separators.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.5 Complex Element: Complete Address Number -- In the Notes/Comments section, the last bulleted comment that discusses hyphenated address numbers in New York City needs further clarification regarding when the number to the left of the hyphen changes and also that there must be no spaces before or after the Separator Element when constructing the Complete Address Number for a NYC-type hyphenated address.

Proposed_Changes

Change the first sentence of the last bulleted comment in the Notes/Comments section to: “In New York City, hyphenated Complete Address Numbers (the recommended format for storing hyphenated addresses in New York City), follow a more complex set of rules.” In the second sentence, change the text within the parenthesis to: “(conceptually—the number does not always change at street intersections and sometimes it changes within a single block face).” Near the end of the same bulleted comment, change “The hyphen is a Separator Element.” to: “The hyphen is a Separator Element with no spaces inserted before or after the hyphen when constructing the Complete Address Number.”

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.5 Complex Element: Complete Address Number --In the Notes/Comments section, the fourth bulleted comment has two instances of double closure parenthesis “))" that should be represented with only single closure parenthesis “)”.

Proposed_Changes

In the Notes/Comments section, replace the double closure parenthesis with single closure parenthesis.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.6 Complex Element: Address Number Range -- In the Example section, the Address Number Range Element in the last example should be bolded for clarity. It is also suggested that for display purposes in this last example only, two spaces be placed both before and after the middle dash character to highlight the syntax of this element.

Proposed_Changes

Bold “214-02 – 213-14 ½” in the last example.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.6 Complex Element: Address Number Range -- In the Notes/Comments section, the second through fifth bulleted comments (2-5) should be indented to clarify that they are associated with the first bulleted comment.

Proposed_Changes

In the Notes/Comments section, indent bulleted comments 2-5.

---

Standard_Part_Section:

1.7.1 Address Number Elements

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

1.7.1.6 Complex Element: Address Number Range -- In the Notes/Comments section, the last bulleted comment is inconsistently worded with the fifth bulleted comment in the Notes/Comments section of 1.7.1.5 Complex Element: Complete Address Number.

Proposed_Changes

In the Notes/Comments section, change the third sentence in the last bulleted comment to: “The former comprises two Address Numbers while the latter is a single Address Number.”

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.2 Street Name Pre Directional -- In the Notes/Comments section, the last bulleted comment incorrectly references “post-directionals” when it should reference “pre-directionals.”

Proposed_Changes

In the Notes/Comments section, change the two occurrences of “post-directionals” in the last bulleted comment to “pre-directionals.”

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.3 Street Name Pre Type -- In the Notes/Comments section, the first bulleted comment indicates that a street cannot have both a pre-type and a post-type; however, in New York City this does occur. Specifically in Manhattan there is a street named “Avenue C Loop”. (Locate in maps.google.com: Avenue C Loop, New York, NY 10009)

Proposed_Changes

Delete the first bullet in the Notes/Comments section.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.3 Street Name Pre Type -- In the Notes/Comments section, the last sentence in the third bulleted comment incorrectly references directionals rather than pre-types and post-types.

Proposed_Changes

In the Notes/Comments section, change the last sentence in the third bulleted comment to: “If stored unabbreviated, the pre-types and post-types can be exported as standard abbreviations as needed for mailing and other purposes.”

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.4 Street Name -- In the Notes/Comments section, the second bulleted comment lists examples for numbered streets in parenthesis. The examples should include “20”, another common reference to numbered streets.

Proposed_Changes

In the Notes/Comments section, change the numbered street examples in the second bulleted comment to: (“Twentieth”, “20th”, or “20”)

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.5 Street Name Post Type - In the Notes/Comments section, the first bulleted comment indicates that a street cannot have both a pre-type and a post-type however in New York City this does occur. Specifically in Manhattan there is a street named “Avenue C Loop” (Locate in maps.google.com: Avenue C Loop, New York, NY 10009).

Proposed_Changes

Delete the first bullet in the Notes/Comments section.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.5 Street Name Post Type -- In the Notes/Comments section, the last sentence in the third bulleted comment incorrectly references directionals rather than pre-types and post-types.

Proposed_Changes

In the Notes/Comments section, change the last sentence in the third bulleted comment to: “If stored unabbreviated, the pre-types and post-types can be exported as standard abbreviations as needed for mailing and other purposes.”

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.6 Street Name Post Directional -- In the Example section, the two exceptions listed in the “USPS Publication 28 Notes” that discuss directional letters (N, E, W, S) used as alphabet indicators would benefit by including parsed out examples.

Proposed_Changes

In the Example section, add examples and parse the street name appropriately for the two exceptions that discuss directional letters (N, E, W, S) used as alphabet indicators: 233.23: Example: “Avenue E South” (Pre Type is “Avenue”, Street Name is “E”, Post-Directional is “South”) 233.3: Example: “Avenue E” (Pre Type is “Avenue”, Street Name is “E”)

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.6 Street Name Post Directional -- In the Notes/Comments section, the bulleted comments following the fourth bulleted comment (“USPS Publication 28 Notes”) should be indented to clarify that they are associated with the preceding bulleted comment. Also in the same section, the text in the third bulleted comment from the end should be included with the preceding bullet that begins with “233.3 Directional as Part of Street Name”.

Proposed_Changes

In the Notes/Comments section, indent the bulleted comments following the fourth bulleted comment, “USPS Publication 28 Notes”. Also in the same section, combine the third bullet from the end with the bullet immediately preceding it that begins with “233.3 Directional as Part of Street Name”.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.6 Street Name Post DirectionaIn the Notes/Comments section, the bullet beginning with “233.23 Two Directionals –” is missing a single closure parenthesis “)”.l --

Proposed_Changes

Add a single closure parenthesis to the end of bulleted item 233.23.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.8 Complete Street Name -- In the Notes/Comments section, the first bulleted comment indicates that a street cannot have both a pre-type and a post-type however in New York City this does occur. Specifically in Manhattan there is a street named “Avenue C Loop”. (Locate in maps.google.com: Avenue C Loop, New York, NY 10009)

Proposed_Changes

Delete the second sentence in the first bulleted comment in the Notes/Comments section.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.2.8 Complete Street Name -- In the Example section, the Complete Street Name Complex Element in the examples should be bolded for clarity.

Proposed_Changes

In the Example section, bold the Complete Street Name Complex Elements in the examples.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.3.4 Floor Type -- In the Example section, the Floor Type Element in the second example should be bolded for clarity.

Proposed_Changes

In the Example section, bold “Floor” in the second example.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.3.5 Floor Identifier -- In the Example section, the Floor Identifier Element in the second example should be bolded for clarity.

Proposed_Changes

In the Example section, bold “Mezzanine” in the second example.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.3.7 Unit Type -- In the Example section, the Unit Type Elements in the first and third examples should be bolded for clarity.

Proposed_Changes

In the Example section, bold “Apartment” in the first example and “Apartamento” in the third example.

---

Standard_Part_Section:

1.7.2 Street Name Elements

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

1.7.3.8 Unit Identifier -- The Domain of Values for this Element section is unpopulated.

Proposed_Changes

Assign “No” as the Domain of Values.

---

Standard_Part_Section:

1.7.3 Building, Floor, and Unit Elements

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

1.7.3.11 Complex Element: Complete Occupancy Identifier -- In the Example section, the Complete Occupancy Identifier Complex Element in the first example should be bolded for clarity.

Proposed_Changes

In the Example section, bold “Building 12, Mezzanine Level, Suite 200” in the first example.

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

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

1.7.5.1 Community Place Name -- New York City is an incorporated city with five administrative or (from Merriam Webster’s Collegiate Dictionary) “constituent political divisions” known as “Boroughs”. Boroughs are a large, formal subdivision of New York City and since they fit the Community Place Name Element definition, “Borough” should be added as another common name for this element. Note that New York City also has neighborhood names within each Borough. For example, the address 64-00 Saunders Street in Zip Code 11374 has three different Place Names: USPS Place Name: Flushing Community Place Name (Borough): Queens Community Place Name (neighborhood): Rego Park

Proposed_Changes

In the Other common names for this element section, add “Borough of New York City”. In the Example section, add “Edgewater Park” as an example. In the Notes/Comments section add: “New York City comprises five administrative “Boroughs” (Bronx, Brooklyn, Manhattan, Queens, and Staten Island). The Boroughs are legally distinct from the five Counties that are also subdivisions of New York City (Bronx, Kings, New York, Queens, and Richmond) even though the Boroughs and Counties have identical boundaries and two even share the same name.

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

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

1.7.5.1 Community Place Name -- In the Example section, only one of the examples has the Community Place Name Element bolded. All examples should have the Community Place Name Element bolded for clarity.

Proposed_Changes

In the Example section, bold the Community Place Name Elements in the examples.

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

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

1.7.5.2 Municipal Jurisdiction -- In the Example section, the Municipal Jurisdiction Element in the second example should be bolded for clarity.

Proposed_Changes

In the Example section, bold “Castle Rock Township” in the second example.

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

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

1.7.5.5 Complex Element: Place Name -- In the Notes/Comments section, the four bulleted comments following the first bulleted comment should be indented to clarify that they are the four types of place names recognized by the Standard that the first bulleted comment is referencing. Similarly the last four bulleted comments should be indented to clarify that they are the four selection rules the immediately preceding bulleted comment is referencing.

Proposed_Changes

In the Notes/Comments section, indent the four bulleted comments following the first bulleted comment and also indent the last four bulleted comments.

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

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

1.7.5.6 State Name -- In 1.7.5.6 State Name there are two typographical errors associated with periods that should be commas.

Proposed_Changes

In the Other common names for this Element section, change the period following “MA” to a comma. In the Notes/Comments section, change the period following “small” to a comma.

---

Standard_Part_Section:

1.7.5 Larger-Area Elements

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

1.7.5.9 Nation Name -- In the Notes/Comments section, the word “to” is missing from the first sentence.

Proposed_Changes

In the Notes/Comments section, add the word “to” in the first sentence: “…is restricted to US addresses…”

---

Standard_Part_Section:

1.8.2 Address Coordinates

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

1.8.2.6 Address Z Value -- The Domain of Values for this Element section is unpopulated.

Proposed_Changes

Assign “See notes below” as the Domain of Values.

---

Standard_Part_Section:

1.8.2 Address Coordinates

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

1.8.2.6 Address Z Value -- It would be helpful to have examples shown for both ratio measurements and ordinal measurements.

Proposed_Changes

Add Address Z Values examples to section 1.8.2.6.

---

Standard_Part_Section:

1.8.3 Descriptive Attributes

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

1.8.3.4 Address Official Status -- The Definition section seems to imply that “official” is a valid value for this descriptive attribute. However the Domain of Values for this Element section refers the reader to the Notes/Comments section which only includes notes about Alternate/Alias names. If the only valid Domain values for this descriptive attribute are those referring to Alternate/Alias names as listed in the Notes/Comments section, a more appropriate element name would be “Alternate Address Type”. However if “Official” is a valid Domain value for this descriptive attribute, it should be noted in the Notes/Comments section.

Proposed_Changes

In the Notes/Comments section, add a bulleted comment describing “Official Name” as a valid Domain value otherwise change the Element Name to “Alternate Address Type”.

---

Standard_Part_Section:

1.8.3 Descriptive Attributes

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

1.8.3.4 Address Official Status -- In the Notes/Comments section, there is a spelling error in the last bulleted comment.

Proposed_Changes

In the Notes/Comments section, change “Altername” in the last bulleted comment to “Alternate”,

---

Standard_Part_Section:

1.8.3 Descriptive Attributes

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

1.8.3.6 Address Range Type -- In the Domain of Values for this Element section, it is not clear if “Actual/theoretical” is referring just to “site” or if would apply to all of the domains listed. We believe it should apply to all domains. Further clarification is needed to eliminate potential confusion.

Proposed_Changes

If “Actual/theoretical” refers to all domain values listed, in the Domain of Values for this Element section, add a colon immediately after “Actual/theoretical” so it clearly applies to all listed domains.

---

Standard_Part_Section:

1.8.3 Descriptive Attributes

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

1.8.3.6 Address Range Type -- In the Domain of Values for this Element section, the “hyphenated single address number” domain should not be listed as a domain since it does not reference an address range, but only a single address.

Proposed_Changes

In the Domain of Values for this Element section, delete “hyphenated single address number (not a range at all)”.

---

Standard_Part_Section:

1.8.4 Spatial Organization Attributes

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

1.8.4.1 Address Number Parity -- Parity is not used for individual addresses but rather for address ranges. A more appropriate Element Name is “Address Range Parity”.

Proposed_Changes

Change the Element Name to “Address Range Parity”.

---

Standard_Part_Section:

1.8.4 Spatial Organization Attributes

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

1.8.4.1 Address Number Parity -- This element should be required with the Address Number Range Complex Element.

Proposed_Changes

Add a “Required Element” section with the following text: “Required with Address Number Range Complex Element”

---

Standard_Part_Section:

1.8.4 Spatial Organization Attributes

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

1.8.4.1 Address Number Parity -- In the Domain of Values for this Element section, “both” should be a valid domain to indicate an address range that encompasses both odd and even address numbers. This case arises where both odd and even addresses exist on the same side of a street.

Proposed_Changes

Add “both” to the Domain of Values for this Element section.

---

Standard_Part_Section:

1.8.4 Spatial Organization Attributes

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

1.8.4.2 Address Scheme Name -- The Domain of Values for this Element section is unpopulated. Since these are locally defined and the Address Scheme Name Element in 1.8.4.7 Address Scheme Complex Element is clearly a locally defined value, there should not be any Domain values.

Proposed_Changes

Assign “No” as the Domain of Values.

---

Standard_Part_Section:

1.8.4 Spatial Organization Attributes

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

1.8.4.4 Address Scheme Origin -- Throughout section 1.8.4.4 there are several misspellings of the word “axis”.

Proposed_Changes

Throughout section 1.8.4.4, change “axes” to axis”.

---

Standard_Part_Section:

1.8.4 Spatial Organization Attributes

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

1.8.4.5 Address ScheThroughout section 1.8.4.5 there are several misspellings of the word “axis”, including the attribute name.me Axes --

Proposed_Changes

Throughout section 1.8.4.5, change “axes” to axis”.

---

Standard_Part_Section:

1.8.4 Spatial Organization Attributes

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

1.8.4.7 Complex Element: Address Scheme -- Throughout section 1.8.4.7 there are several misspellings of the word “axis”.

Proposed_Changes

Throughout section 1.8.4.7, change “axes” to axis”.

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Editorial

Name:

Dan Jacobson

Organization:

None

Organization_Comment:

Email:

jidanni@jidanni.org

Date:

13 Jan 2006

Comments

It would be a shame if you didn't incorportate capability for addresses like No. 6, ALLEY 333, LANE 444, DONGGUAN RD, SEC 5 as seen on http://jidanni.org/geo/house_numbering/taiwan_english_addresses_en.html If being a brilliant form of addressing is not enough, then all I can do is use "Taiwan might soon be the 51st state" as an excuse, http://www.taiwanadvice.com/fapa/insular.htm

Proposed_Changes

---

Standard_Part_Section:

1.7.1 Address Number Elements

Type:

Substantive

Name:

Wendy Blake-Coleman

Organization:

USEPA

Organization_Comment:

I am commenting on behalf of my organization.

Email:

blake-coleman.wendy@epa.g

Date:

16 Jan 2006

Comments

1. It is our understanding that a single data element should not refer to multiple concepts. In the standard the use of multiple concepts for a single data element occurs throughout, for example, in the standard data element 1.7.1.2 "Address Number" can mean street number, building number, house number, site number, structure number. Won't this cause confusion in implementation? What if the address is 111 Cato Street, Building 13? There seems to be a further confusion between "Address number" designated as "building number" with data element 1.7.3.2 "Building Identifier". 2. The data element 1.7.1.4 "separator element" is not really a data element it is presentation or format. 3. Finally, just an observation: The use of very fine-grained data elements for XML exchange, e.g., one element for "1300", another element for "Pennsylvania", another element for "Avenue", another element for "NW" is way beyond the level of detail at which most people will exchange data.

Proposed_Changes

---

Standard_Part_Section:

1.7.1 Address Number Elements

Type:

Substantive

Name:

Wendy Blake-Coleman

Organization:

USEPA

Organization_Comment:

I am commenting on behalf of my organization.

Email:

blake-coleman.wendy@epa.g

Date:

16 Jan 2006

Comments

1. It is our understanding that a single data element should not refer to multiple concepts. In the standard the use of multiple concepts for a single data element occurs throughout, for example, in the standard data element 1.7.1.2 "Address Number" can mean street number, building number, house number, site number, structure number. Won't this cause confusion in implementation? What if the address is 111 Cato Street, Building 13? There seems to be a further confusion between "Address number" designated as "building number" with data element 1.7.3.2 "Building Identifier". 2. The data element 1.7.1.4 "separator element" is not really a data element it is presentation or format. 3. Finally, just an observation: The use of very fine-grained data elements for XML exchange, e.g., one element for "1300", another element for "Pennsylvania", another element for "Avenue", another element for "NW" is way beyond the level of detail at which most people will exchange data.

Proposed_Changes

---

Standard_Part_Section:

1.7.1 Address Number Elements

Type:

Substantive

Name:

Wendy Blake-Coleman

Organization:

USEPA

Organization_Comment:

I am commenting on behalf of my organization.

Email:

blake-coleman.wendy@epa.g

Date:

16 Jan 2006

Comments

1. It is our understanding that a single data element should not refer to multiple concepts. In the standard the use of multiple concepts for a single data element occurs throughout, for example, in the standard data element 1.7.1.2 "Address Number" can mean street number, building number, house number, site number, structure number. Won't this cause confusion in implementation? What if the address is 111 Cato Street, Building 13? There seems to be a further confusion between "Address number" designated as "building number" with data element 1.7.3.2 "Building Identifier". 2. The data element 1.7.1.4 "separator element" is not really a data element it is presentation or format. 3. Finally, just an observation: The use of very fine-grained data elements for XML exchange, e.g., one element for "1300", another element for "Pennsylvania", another element for "Avenue", another element for "NW" is way beyond the level of detail at which most people will exchange data.

Proposed_Changes

---

Standard_Part_Section:

1.7.1 Address Number Elements

Type:

Substantive

Name:

Wendy Blake-Coleman

Organization:

USEPA

Organization_Comment:

I am commenting on behalf of my organization.

Email:

blake-coleman.wendy@epa.g

Date:

16 Jan 2006

Comments

1. It is our understanding that a single data element should not refer to multiple concepts. In the standard the use of multiple concepts for a single data element occurs throughout, for example, in the standard data element 1.7.1.2 "Address Number" can mean street number, building number, house number, site number, structure number. Won't this cause confusion in implementation? What if the address is 111 Cato Street, Building 13? There seems to be a further confusion between "Address number" designated as "building number" with data element 1.7.3.2 "Building Identifier". 2. The data element 1.7.1.4 "separator element" is not really a data element it is presentation or format. 3. Finally, just an observation: The use of very fine-grained data elements for XML exchange, e.g., one element for "1300", another element for "Pennsylvania", another element for "Avenue", another element for "NW" is way beyond the level of detail at which most people will exchange data.

Proposed_Changes

---

Standard_Part_Section:

1.7.1 Address Number Elements

Type:

Substantive

Name:

Wendy Blake-Coleman

Organization:

USEPA

Organization_Comment:

I am commenting on behalf of my organization.

Email:

blake-coleman.wendy@epa.g

Date:

16 Jan 2006

Comments

1. It is our understanding that a single data element should not refer to multiple concepts. In the standard the use of multiple concepts for a single data element occurs throughout, for example, in the standard data element 1.7.1.2 "Address Number" can mean street number, building number, house number, site number, structure number. Won't this cause confusion in implementation? What if the address is 111 Cato Street, Building 13? There seems to be a further confusion between "Address number" designated as "building number" with data element 1.7.3.2 "Building Identifier". 2. The data element 1.7.1.4 "separator element" is not really a data element it is presentation or format. 3. Finally, just an observation: The use of very fine-grained data elements for XML exchange, e.g., one element for "1300", another element for "Pennsylvania", another element for "Avenue", another element for "NW" is way beyond the level of detail at which most people will exchange data.

Proposed_Changes

---

Standard_Part_Section:

1.7 Address Elements - Generally

Type:

Substantive

Name:

wendy blake-coleman

Organization:

EPA

Organization_Comment:

I am commenting on behalf of my organization.

Email:

blake-coleman.wendy@epa.g

Date:

16 Jan 2006

Comments

The Draft Street Address Standard violates the basic premise in data standards of a data standard should deal with one unique issue per element. The Street Address data standard should be about the Street ( road, thoroughfare,etc.) not the mailing addresses ( Postal Delivery address) or the Community Landmark's. Is "Community" as a class truly necessary in a street data standard. This document appears to be mission crept as its finest. The proposed standard stretches to the far reaches the concept and definition of "Street."

Proposed_Changes

---

Standard_Part_Section:

1.1 Organization

Type:

Substantive

Name:

wendy blake-coleman

Organization:

USEPA

Organization_Comment:

Email:

blake-coleman.wendy@epa.g

Date:

16 Jan 2006

Comments

Our primary issue is that this standard should be aligned with and reference "The International Postal Address Components and Templates", Universal Postal Union S42-X. However, as part of that concern, we do not understand the need to rewrite the postal address data elements contained in S42-X. The Universal Postal Union standard is accepted and used internationally. It was revised recently-- in 2003. Please contact me with a specific email and we will sen a PDF of the International Postal Address Standard.

Proposed_Changes

---

Standard_Part_Section:

1.7.1 Address Number Elements

Type:

Substantive

Name:

wendy blake-coleman

Organization:

USEPA

Organization_Comment:

I am commenting on behalf of my organization.

Email:

blake-coleman.wendy@epa.g

Date:

16 Jan 2006

Comments

It is our understanding that a single data element should not refer to multiple concepts. In the standard the us