Home » About URISA » Initiatives » Draft Address Data Standard

Draft Address Data Standard - Data Transfer

Data Transfer

Part 4: Street Address Data Transfer

The purpose of this section is three-fold: to provide a template for the XML documents and metadata that will move addresses from place to place, to provide information on preparing data to be packaged, and to provide information on unpackaging received street address data.

Historically, the data format aspects of data transfer have impeded the flow of information. In providing a single, flexible data structure for transferring street address data, routine exchanges of data between parties will become simpler to implement and more reliable, especially over time. Local data processing systems and applications change over time and frequently data exchange programs and reports must be rewritten along with those changes. Such changes may be as seemingly minor as the renaming of a data element, shortening or extending the length of a field, or the addition or subtraction of a field. When new data sharing partners are identified, a data format for sharing data with that partner must be constructed and implemented by each party. The Address Standard aims to minimize local changes necessary when upgrading computer systems and to provide a structure that can be reused by all data sharing parties without their having to implement something new.

The data sharing benefits of the Address Standard will only be realized when local agencies have implemented both export and import engines to process exchanged street addresses. The initial implementation of these data engines or programs will provide a lasting benefit to implementers in that once created, the agency will never again need to be concerned with creating programs or engines to share data with any new data sharing partners that they identify in the future.

The Address Standard is designed to be flexible enough to fit within current data sharing methods. There are two basic forms of sharing data between parties:

  • Monolithic, in which all records are in the exchange package.
  • Transactional, in which the exchange package records include commands to add or remove a record from the local copy of all records.

The Standard supports both of these forms, using a slightly modified structure to enable transactional exchanges.

Part 4: Data Transfer
(in .pdf form)

 


 

Standard_Part_Section:
4.2 The XSD Data Model - Generally
Type:
Editorial
Name:
Henning Schulzrinne
Organization:
Columbia University
Organization_Comment:
Email:
hgs@cs.columbia.edu
Date:
17 Dec 2005

Comments

The schema description does not indicate the element type. It would be helpful to indicate which of the standard XSD types is being used for each element.

Proposed_Changes

Add schema data types to table on p. 115 and following.

Standard_Part_Section:
4.2 The XSD Data Model - Generally
Type:
Substantive
Name:
Henning Schulzrinne
Organization:
Columbia University
Organization_Comment:
Email:
hgs@cs.columbia.edu
Date:
17 Dec 2005

Comments

Nothing is said about whether elements should be in all uppercase (bad, in my opinion) or which character set should be used. No indication is given what should be done about accented characters that can occur, e.g., in French or Spanish names. No indication whether it would be possible to render street names in multiple languages.

Proposed_Changes

State that normal capitalization should be used (i.e., New York, not NEW YORK). State that UTF-8 should be used. Say something about how street names with names in multiple languages (streets in Chinatown?) should be handled. This can be done with the lang attribute in XML elements, but then would need multiple instances of the same type of element.

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

Comments

The address standard supports two basic forms of data sharing "monolithic and transactional" These exchange mechanisms are biased towards synchronizing databases of addresses. This is only one of many potential applications that could use the address exchange format. Suppose I create a service that accepts an address in your standard format and returns back a JPEG satellite image. This application does not fix either exchange form described in the document. We recommend that references to specific applications be removed from the specification.

Proposed_Changes

Remove all references to data sharing applications or provide a more generic discussion.

Standard_Part_Section:
4.2 The XSD Data Model - Generally
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

We strongly urge the standards committee to adopt GML 3.1.1 instead of the OpenGIS simple feature specification for SQL.

Proposed_Changes

Standard_Part_Section:
4.2 The XSD Data Model - Generally
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

XML is one view of the address data model. To support generic data modeling objectives the address model should be presented in a standard modeling framework like UML. For example suppose I wanted to create a database based on the address standard? I would have a hard time doing it. UML is the de facto modeling standard. There are many tools that convert UML to other products like databases, XSDs, computer code. A UML model is a necessity!

Proposed_Changes

Create a UML model for the standard.

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

Comments

Many potential users of this standard will not be familiar with the technical details of implementing an XML based transfer. It would be a shame if folk failed to take advantage of this standards effort because they (a) thought they were mandated to manage their data in an XML environment and/or (b) had no clue how to process an XML transfer package.

Proposed_Changes

1) Add a short introductory subsection on "How XML Affects Your Use of this Standard", which should reassure folk that they can use whatever tools and technologies they wish to manage their address data and still be compliant with this standard. XML is only the specified transfer protocol, etc. etc. 2) Add a very concise discussion of the XML data architecture involved in a transfer. What types of software are needed, how to use the XSD file, and etc. Also, include a forward-looking statement about how we think vendors will utilize this standard drawing on SDTS as an analogy. (The intent is to help early adopters understand what they will need, and to reassure others that they don't have to get out on what they will think of as the "bleeding edge" of new technology.) I suggest also including some sources of info and community for XML technology, even though this stuff gets dated quickly.

Standard_Part_Section:
4.1 Structure of a Transfer Package - Generally
Type:
Substantive
Name:
Carl Reed
Organization:
URISA member
Organization_Comment:
Email:
the.reed3s@gmail.com
Date:
12 Jan 2006

Comments

Not sure if this is the correct sectin to provide a comment for. Anyway, I read this section as well as Appendix A. My question is perhaps more general in nature than most, "What is the relationship of this draft address standard to other address encoding and use standards being used/developed by other standards organizations?" For example, the IETF GeoPRIV Working Group has an Internet Draft titled "Dynamic Host Configuration Protocol(DHCPv4 and DHCPv6)Option for Civic Addresses Configuration Information". They do reference Postal and NENA standards but they extend to deal with international requirements. Also, OASIS has developed a standard titled xAL (http://www.oasis-open.org/committees/documents.php?wg_abbrev=ciq for XML encodings of addresses. I was wondering what the relationship is between xAL and the FGDC Street Address draft standard (if any). The issue I am concerned about is consistency with other street address encoding standards (existing and in progress). Technology providers would love to be able to write just one encoding/decoding application for addresses and then use this capability without having to re-write for new address standards or other parts of the world. To this end, I was wondering if anyone has tried to use GML to encode addresses as per the draft FGDC street address content standard.

Proposed_Changes

I would suggest that there be more information added to the informative annex about the relationship of this address standard to other international standards work related to encoding and transmitting addresses. I also think that another informative annex that demonstrates the use of GML for encoding addresses as per the rules in this document would be extremely valuable.

Standard_Part_Section:
4.3.2 Relation of the Address Standard XSD Data Model to the Content and Classification Parts
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

4.3.2 Crosswalk Chart, page 119 -- The “Address Scheme Axes” class name is misspelled as well as two other occurrences of the word “axis” in the same line.

Proposed_Changes

In the Crosswalk Chart on page 119, change “axes” to axis” (3 occurrences).

Standard_Part_Section:
Introduction
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

Appendix C -- Throughout Appendix C there are several misspellings of the word “axis”.

Proposed_Changes

In Appendix C, change all occurrences of “axes” to “axis”.

Standard_Part_Section:
4.1 Structure of a Transfer Package - Generally
Type:
Substantive
Name:
wendy blake-coleman
Organization:
USEPA
Organization_Comment:
Email:
blake-coleman.wendy@epa.gov
Date:
16 Jan 2006

Comments

Much of the standard and the data exchange formatting for XML, does not support -- -- -- "Street addresses are critical information for administrative, emergency response, research, marketing, mapping, GIS, routing and navigation, and many other purposes." The exchange format section, requires an intimate knowledge of addresses being exchanged and does not appear to be conducive to automated processes since the pre-directional and post-directional elements could be unique the primary street names. Why separate the street number from the street name also appears to be overly prescriptive in the standard. The Part 4 Street Address Data Exchange section has " Required Elements", such as Address data and Metadata. The inclusion of the metadata requirement is highly burdensome on the exchange of the physical address and should be voluntary at best and defined as needed when trading partners require such documentation on the data. It appears that much of the 137 pages does not deal with the important standardization of the Street Address data standard but other areas of the data that exchange partners should be controlling to be as seamless as possible between sharing partners.

Proposed_Changes

Standard_Part_Section:
4.1 Structure of a Transfer Package - Generally
Type:
Substantive
Name:
wendy blake-coleman
Organization:
USEPA
Organization_Comment:
Email:
blake-coleman.wendy@epa.gov
Date:
16 Jan 2006

Comments

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:
4.2 The XSD Data Model - Generally
Type:
Editorial
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

Provide the XML/Schema document as an XML/Schema document {filename}.xsd in UTF-8 XML format so it is human and machine readable, not as a PDF file that must be exported and hand-edited. Better yet, also set up a server that will return the schema document from its namespace URI.

Standard_Part_Section:
4.2 The XSD Data Model - Generally
Type:
Editorial
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

Exclude the “.xsd” suffix from the namespace http://wfs.co.fulton.ga.us/urisa/addr_std/addr.xsd , e.g. make it http://wfs.co.fulton.ga.us/urisa/addr_std/addr so that the suffix matches the target namespace prefix used for the namespace. This is a convention that proved convenient and understandable in GML, and is used elsewhere as well.

Standard_Part_Section:
4.3.1 General Notes on the XML schema
Type:
Editorial
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

Include a “version” attribute on the schema element. This facilitates automated version negotiation between clients and servers, as is done by OGC Web Feature Services and Web Map Services, once more than one version of the schema is in use. For example: version="0.2"

Standard_Part_Section:
4.2 The XSD Data Model - Generally
Type:
Editorial
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

“Parsing error in file:StreedAddressDataStandard.xsd: Expected comment or CDATA (line 380, column 2)” There is a space between the ! and – characters in the following text: <! -- this is an enumeration of all of the valid USPS road types, plus the conditionally permissable spanish abbreviations --> which makes it an invalid XML comment. Remove the space.

Standard_Part_Section:
4.3.1 General Notes on the XML schema
Type:
Substantive
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

“Parsing error in file:StreedAddressDataStandard.xsd: Expected whitespace (line3386, column 34)” In the text <xsd:element name="Longitude" type="addr:AddressLongitude_type"minOccurs="1" maxOccurs="1" /> there is no space after the quotation mark and before “minOccurs”. Insert one.

Standard_Part_Section:
4.3.1 General Notes on the XML schema
Type:
Editorial
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

“Parsing error in file:StreedAddressDataStandard.xsd: Expected whitespace (line3489, column 47)” In the text <xsd:element name="Unit" type="addr:Unit_type"minOccurs="0" maxOccurs="1" /> There is no space after the quotation mark and before “minOccurs”. Insert one.

Standard_Part_Section:
4.3.1 General Notes on the XML schema
Type:
Editorial
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

In the text <xsd:element name="LandmarkName"minOccurs="1" maxOccurs="1"> There is no space after the quotation mark and before “minOccurs”. Insert one.

Standard_Part_Section:
4.3.1 General Notes on the XML schema
Type:
Substantive
Name:
{Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

Require the use of namespace qualified elements. Do this by adding the attribute elementFormDefault="qualified" to the xsd:schema element. Otherwise, the definitions from the address standard schema cannot be segregated from those defined in schemas that import it by using a namespace prefix, because a validating parser won’t allow one. Here are the results of validation of sampleHousingUnit.xml discussed in Comment 9 below without the change: $ java sax.Counter -n -s -v sampleHousingUnit.xml [Error] sampleHousingUnit.xml:21:34: cvc-complex-type.2.4.a: Invalid content starting with element 'addr:CompleteAddressNumber'. The content must match '(("":CompleteAddressNumber), ("":CompleteStreetName), ("":CompleteOccupancyIdentifier) {0-1}, ("":PlaceName), ("":StateName), ("":ZipCode), ("":ZipPlus4){0-1}, ("":NationName) {0-1}, ("":AddressAttributes){0-1})'. sampleHousingUnit.xml: 438 ms (21 elems, 7 attrs, 0 spaces, 311 chars) Here are the results with the change: $ java sax.Counter -np -s -v -f sampleHousingUnit.xml sampleHousingUnit.xml: 437 ms (21 elems, 13 attrs, 0 spaces, 311 chars) No errors.

Standard_Part_Section:
4.3.1 General Notes on the XML schema
Type:
Substantive
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

Add a substitution group hierarchy for address elements, and put all address elements in the substitution group. Doing so allows XML/Schema writers who import the address standard schema to use element references in their complex type definitions that allow any, or only selected types of address elements to be used in their place, and to rely on a validating schema parser to enforce the restriction. (See message sent to Ed Wells for models here.) The anyThoroughfareAddress element is the head of a substitution group that includes all the thoroughfare address elements. The anyLandmarkAddress element is the head of a substitution group that includes all landmark address elements. The anyPostalAdddress element is the head of a substitution group that includes all postal address elements. Here is the added and changed text for the schema document, contained in the attached StreetAddressDataStandardEditedPwD20060113.xsd: <!-- any address substitution group head --> <xsd:element name="anyAddress" type="xsd:anyType"> <xsd:annotation> <xsd:documentation> This element serves as the head of a substitution group for elements of the standard address types defined in this schema. It's reference in the definition of a complex type in an application schema that imports this one allows instance documents that conform to that application schema to substitute any element in the substitution group for the defined addr:anyAddress element. </xsd:documentation> </xsd:annotation> </xsd:element> <!-- Thoroughfare Address Classes --> <xsd:element name="anyThoroughfareAddress" substitutionGroup="addr:anyAddress"> <xsd:annotation> <xsd:documentation> This element serves as the head of a substitution group for elements of the thoroughfare address types defined in this schema. It's reference in the definition of a complex type in an application schema that imports this one allows instance documents that conform to that application schema to substitute any element in the substitution group for the defined addr:anyThoroughfareAddress element. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="SiteAddress" type="addr:SiteAddress_type" substitutionGroup="addr:anyThoroughfareAddress"/> <xsd:element name="LandmarkSiteAddress" type="addr:LandmarkSiteAddress_type" substitutionGroup="addr:anyThoroughfareAddress"/> <xsd:element name="IntersectionAddress" type="addr:IntersectionAddress_type" substitutionGroup="addr:anyThoroughfareAddress"/> <xsd:element name="TwoNumberAddressRange" type="addr:TwoNumberAddressRange_type" substitutionGroup="addr:anyThoroughfareAddress"/> <xsd:element name="FourNumberAddressRange" type="addr:FourNumberAddressRange_type" substitutionGroup="addr:anyThoroughfareAddress"/> <xsd:element name="UnnumberedThoroughfareAddress" type="addr:UnnumberedThoroughfareAddress_type" substitutionGroup="addr:anyThoroughfareAddress"/> <!-- Landmark Address Classes --> <xsd:element name="anyLandmarkAddress" substitutionGroup="addr:anyAddress"> <xsd:annotation> <xsd:documentation> This element serves as the head of a substitution group for elements of the landmark address types defined in this schema. It's reference in the definition of a complex type in an application schema that imports this one allows instance documents that conform to that application schema to substitute any element in the substitution group for the defined addr:anyLandmarkAddress element. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="SingleSiteLandmarkAddress" type="addr:SingleSiteLandmarkAddress_type" substitutionGroup="addr:anyLandmarkAddress"/> <xsd:element name="MultiSiteLandmarkAddress" type="addr:MultiSiteLandmarkAddress_type" substitutionGroup="addr:anyLandmarkAddress"/> <xsd:element name="CommunityAddress" type="addr:CommunityAddress_type" substitutionGroup="addr:anyLandmarkAddress"/> <!-- Postal Delivery Address Classes --> <xsd:element name="anyPostalAddress" substitutionGroup="addr:anyAddress"> <xsd:annotation> <xsd:documentation> This element serves as the head of a substitution group for elements of the postal address types defined in this schema. It's reference in the definition of a complex type in an application schema that imports this one allows instance documents that conform to that application schema to substitute any element in the substitution group for the defined addr:anyPostalAddress element. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="USPSPostalDeliveryBox" type="addr:USPSPostalDeliveryBox_type" substitutionGroup="addr:anyPostalAddress"/> <xsd:element name="USPSPostalDeliveryRoute" type="addr:USPSPostalDeliveryRoute_type" substitutionGroup="addr:anyPostalAddress"/> <xsd:element name="USPSGeneralDeliveryAddress" type="addr:USPSGeneralDeliveryAddress_type" substitutionGroup="addr:anyPostalAddress"/> <!-- General Delivery Classes --> <xsd:element name="GeneralAddress" type="addr:GeneralAddress_type" substitutionGroup="addr:anyAddress"/> The attached sample schema HousingUnit.xsd defines GML FeatureCollection and Feature types for housing units and houses, and an address property <choice> <element ref="addr:anyThoroughfareAddress"/> <element ref="addr:anyLandmarkAddress"/> </choice> that limits addresses to thoroughfare and landmark addresses, excluding postal and general addresses. The sample file sampleHousingUnit.xml contains a house with a SiteAddress, which is a ThoroughfareAddress, and therefore valid according to the schema. $ java sax.Counter -np -s -v -f sampleHousingUnit.xml sampleHousingUnit.xml: 437 ms (21 elems, 13 attrs, 0 spaces, 311 chars) No errors. The sample file sampleHousingUnit2.xml contains the same house with a USPSPostalDeliveryBox, which is not a thoroughfare or landmark address, and therefore invalid according to the schema. $ java sax.Counter -n -np -s -v -f sampleHousingUnit2.xml [Error] sampleHousingUnit2.xml:20:33: cvc-complex-type.2.4.a: Invalid content starting with element 'addr:USPSPostalDeliveryBox'. The content must match '((("http://wfs.co.fulton.ga.us/urisa/addr_std/addr":anyThoroughfareAddress)| ("http://wfs.co.fulton.ga.us/urisa/addr_std/addr":anyLandmarkAddress)))'.

Standard_Part_Section:
4.3.1 General Notes on the XML schema
Type:
Substantive
Name:
Paul Daisey
Organization:
US Census Bureau
Organization_Comment:
Email:
paul.w.daisey@census.gov
Date:
20 Jan 2006

Comments

Proposed_Changes

Validate the schema against as wide a variety of sample instance documents as possible before you publish it to catch both simple and complex schema errors. Users will be trying to integrate the definitions from this standard schema with schemas that implement other standards, and enforce different XML conventions. Seemingly trivial XML/Schema design decisions adopted for this standard can make their efforts difficult or nearly impossible. Use Apache Xerces. It’s the reference implementation of a validating XML/Schema parser. See http://xerces.apache.org/xerces2-j/

» login to post comments