skip to content | skip to navigation

GIS.NY.GOV

NYS ITS GIS Program Office

Geographic Information Systems Clearinghouse

NYS Standards and Data Coordination Workgroup
(NYSDCW)

Comments on Proposed FGDC/URISA Street Address Data Standard 10/05
Standard/Part/Section Comments Proposed Changes
2.1.2 Address Number Missing from this standard is an acceptable way to represent the “Queens-style” hyphenated addressing that occurs in New York City, primarily in Queens. The standard Queens hyphenated address number format is XXX-XXX. An address number in this format is NOT an address range but rather a single address number of a specific building where the three digits preceding the hyphen generally reference the numbered cross-street (or if the cross-street is named and not numbered, what the street would be numbered) that intersects the given street segment.

Note that if a Queens-style address number is represented with its hyphen explicitly expressed, it must have a TEXT data type. The digits following the hyphen must be stored with leading zeros within the three bytes.

Add simple elements and create a compound element to appropriately represent Queens-style addressing.
2.2.2 Street Pre-Directional Since the Street Pre-Directional is a simple element with a clearly defined domain, we strongly support use of abbreviations as recommended in USPS Publication 28. Data storage is minimized and use of an abbreviation would clarify that in a complex element representing the entire street name, this is the pre-directional rather than the Street Name simple element. The abbreviations can always be exported fully spelled out. We do recognize the need to fully spell out a directional that is the Street Name (e.g. WEST STREET should always be spelled out). Recommend use of abbreviations and change element Length.
2.2.3 Street Prefix Type ESRI users may confuse the “pre-type” reference in Note 1 and Note 3 with ESRI’s “Pre-type” element that is required for geocoding in ESRI software. While the “Avenue A” example mirrors what would be parsed out into ESRI’s Pre-type element, “County Road 28” does not and is handled much differently (i.e. ESRI parses the name as Pre-type=County Road and Street Name=28). More clarification is needed in the comments section.

Also, please confirm that “Boulevard East” would also be treated as a street name without a Prefix Type or Post Type (i.e. Street Name=Boulevard, Post-Directional=East).

Change “pre-type” in Notes 1 and 3 to “prefix type”. Also in Note 3 add “US Highway 20, State Route 5” as additional names with a street type occurring in the middle of the name.
2.2.5 Street Post Type ESRI users may confuse the “pre-type” reference in Note 1 and Note 3 with ESRI’s “Pre-type” element that is required for geocoding in ESRI software. More clarification is needed in the comments section. Change “pre-type” in Notes 1 and 3 to “prefix type”. Also in Note 3 add “US Highway 20, State Route 5” as additional names with a street type occurring in the middle of the name.
2.2.6 Street Post-Directional Since the Street Post-Directional is a simple element with a clearly defined domain, we strongly support use of abbreviations as recommended in USPS Publication 28. Data storage is minimized and use of an abbreviation would clarify this is the post-directional rather than part of the Street Name simple element when included in the complex element that represents the entire street name. The abbreviations can always be exported fully spelled out. We do recognize the need to fully spell out a directional when it is considered the Street Name (e.g. WEST STREET should always be spelled out). Recommend use of abbreviations and change element Length.
2.2.6 Street Post-Directional The USPS Publication 28 note 233.23 Two Directionals reference is confusing. It would help to show these parsed out in the Example section. Add to the Example section and parse (bold) the name appropriately.
2.5.1 Landmark Name The term “Landmark” is commonly interpreted as an officially designated site of historical significance, often included in an historical register. Since “historical significance” is not a requirement for a landmark as used in this standard, it is recommended that a note be added for clarification. Under the Notes/Comments section clarify that a Landmark does not have to be officially designated as a historical site or be recorded in a historical register.
2.7.1 USPS Box Type Examples are not complete or bolded to show correct parsing. Add Box numbers to the examples and bold “PO Box” and “Box” (e.g. PO Box 6943)
2.7.3 USPS Box Group Type Examples are not complete and the information in parenthesis belongs in the Notes/Comments section. Add route/box numbers to the examples and move the information in parenthesis down to the Notes/Comments section.
2.8.6 Complete Occupancy Identifier The Definition should list complex elements rather than simple elements. Change the Definition to {Building}+{Floor}+{Unit}+{PMB}
2.8.10 Place State Zip The width of the two columns in the table does not match the column widths of the other tables in the standard. Reduce the width of the first column and increase the width of the second column to match the other sections.
3 Address Attribute Elements Several of the Examples throughout section 3 are not bolded as in previous sections. Bold examples to show correct parsing.
3.1 Location Attributes We concur with the previous submitted comment regarding adding separate items for Geographic Latitude and Geographic Longitude as non-required elements. These (x,y's) will prove to be very useful in the future as GPS is increasingly integrated into existing technologies (cell phones, palms, etc). Add Geographic Latitude and Geographic Longitude elements.
3.1 Location Attributes We concur with previous submitted comments regarding the need for projection and datum elements. These elements would be necessary for data sets that contain coordinates that are not all in the same projection or datum. We also support the suggestion to include a Z coordinate for specifying coordinates for multi-story structures. Add elements:

Address Z Coordinate,

Projection, Datum, etc.

3.2 Non-Locational Attributes When addresses are classified as address ranges (e.g. block face, building), very often a parity attribute also exists (usually defined as B=Both, E=Even, O=Odd). Add a Parity attribute to the standard.
3.2.2 Address Start Date

3.2.3 Address End Date

Dates should be in one consistent format with forced entry as mm/dd/yyyy, the preferred date format for storing dates in a database. Consider replacing the date example with one in mm/dd/yyyy format or at least adding another date example in this format. Replace the existing example or at least add a second example date in mm/dd/yyy format in the Example section of these elements.
3.2.11 Address Direct Source Often data providers already have addresses in their database and need to verify or validate them with the local addressing authorities. Change Definition to “From whom the data provider obtained or validated the address.”

Part 2:

Street Address Data Classification

The syntax throughout Part 2 often includes {Place Name*}+{State*}+{Zip*}+{Zip+4} which is exactly the same as the complex element Place State Zip (including the asterisked/required simple elements). Simplify the syntax by using Place State Zip. Replace {Place Name*} + {State*}+{Zip*}+{Zip+4} with {Place State Zip}

Part 2:

Street Address Data Classification

There appears to be inconsistent bolding of the elements in the syntax line throughout Part 2. Bold all elements listed in the syntax lines.

Part 2:

Street Address Data Classification

Quotes are often used in the TYPE lines following the syntax lines for many of the listed classes. The use of quotes should be explained in Section 1.1 Formatting Conventions. Add an explanation on the usage of quotes in Section 1.1 Formatting Conventions.
Part 2:

2.2.5 Block Address Range

The parenthesis and brackets do not pair up correctly in the syntax line. Pair up the parenthesis and brackets in the syntax line.
Part 2:

2.2.3 Community Place Name Address

The Community Place name element is shown incorrectly in the syntax line. Change the second element to {Community Place Name (Urbanization) Place}
Part 2:

2.4.3 USPS Postal Delivery Office

The name of the first element in the syntax line is incorrect. It should NOT include “USPS”. Change the first element to {Postal Delivery Office*}.
Part 2:

2.4.3 USPS Postal Delivery Office

It is not clear if the “Complete Example” at the bottom of page 15 is supposed to be two separate examples or one single example. If it is supposed to be one example, remove the square bullets. If it is supposed to be two examples, change the heading to “Complete Examples” (with an ‘s’).
Part 1:

2 Simple Elements

Was consideration given to creating a second normalized street name format within the addressing standard that is dedicated solely to support sorting? It is possible that some address databases may include this type of element(s). A more detailed description provided by one of our subcommittee members follows:

The conventional normalized street name format defined in the Addressing Standard is suitable for display on reports and application screens, but it is not suitable for sorting. The sort problem occurs with street names that have one or more words that consist of one or more numeric digits, possibly followed by an ordinal suffix (the endings “st”, “nd”, “rd” and “th” that can follow a numeric value). To illustrate the problem, consider the following sorted list of street names in the conventional normalized format:
1st Street
11th Street
103rd Street
182nd Street
2nd Street
214th Street
5th Street

The above clearly is not an appropriate sort order for these street names. A suggested solution to the problem is to define a second normalized street name format within the National Addressing Standard that is dedicated solely to support sorting. Let’s provisionally call this the “Normalized Street Name for Sorting” (NSNS) format.

The NSNS format would be a second normalized street name format defined in the standard, in addition to (not instead of) the conventional normalized street name format. The conventional normalized format is suitable for display but not for use in address sorting. The NSNS format is suitable for sorting but not for display. No one format can support both needs. Either format would be usable for address matching purposes.

One way to define the NSNS format that would be effective in supporting appropriate street name sorting is as follows. Any word in a street name that consists entirely of one or more numeric digits possibly followed by an ordinal suffix would be expressed in the NSNS format as a four-byte, right-justified, zero-filled word with no ordinal suffix. Words in a street name that do not consist solely of digits with or without an ordinal suffix would be identical in the conventional and NSNS normalized formats.

For example, the word 1st would be replaced by 0001; 11th would be replaced by 0011; 214th would be replaced by 0214.

So our example list of street names would look as follows in NSNS format:
0001 Street
0002 Street
0005 Street
0011 Street
0103 Street
0182 Street
0214 Street

Clearly, the NSNS format produces the appropriate sort order for our sample list. It would be equally effective regardless of the position of the numeric word (or words) within the street name. Example:
Beach 0001 Street
Beach 0002 Street
Beach 0005 Street
Beach 0011 Street etc.

Notes:

  1. The NSNS format would never be used for display.
  2. The number of bytes allocated to the numeric words in NSNS format must be defined as the largest number required to accommodate all U.S. street names. That number was assumed above to be four. It may be necessary to increase it.
  3. The NSNS format was defined above so that numeric words do not contain ordinal suffixes, but consist only of numeric digits. It would be equally effective to define the NSNS format so that numeric words always contain the ordinal suffix. The definition should specify either always to include or always to exclude ordinal suffixes; it should not allow a mixture.