Page 1 of 2

Improper "Standardized" format for apartment addresses

Posted: Tue Jul 02, 2013 1:09 pm
by RossEvans
In the Clerk Resources Member List tool, when editing a member address if the address includes an apartment number, the user interface prompts the clerk to reformat the "standardized" address with the apartment number on the second line. For example, with this (fictional) example, the prompt might read:
Use this standardized residential address instead?
12440 Maple Ave
Apt 1234
Austin, Texas 78701
The problem is, this is not the standard. Our unit (as I believe all U.S. units should) follows USPS standardized format, except that we do not use all-caps. The USPS standardization, and all USPS-certified third-party software for address standardization, calls for appending the apartment number to the first line, not the second line. So the prompt in the above example should read:
Use this standardized residential address instead?
12440 Maple Ave Apt 1234
Austin, Texas 78701
One can easily verify this by visiting the interactive USPS website with a valid apartment address to validate:
https://tools.usps.com/go/ZipLookupAction!input.action

On that site a user can enter the apartment on a second line of the web form, but submitting the form returns the standardized address with the apartment number appended to the first line.

See also this USPS document:
http://pe.usps.gov/cpim/ftp/pubs/pub28/pub28.pdf

It's great that there is a tool to attempt standardization. But let's get the standard right.

I have submitted feedback on lds.org.

Re: Improper "Standardized" format for apartment addresses

Posted: Tue Jul 02, 2013 1:27 pm
by rontilby
I concur 100%. This needs to be fixed.

Re: Improper "Standardized" format for apartment addresses

Posted: Tue Jul 02, 2013 1:48 pm
by jdlessley
When I was a clerk I used the USPS standards for addresses in MLS. I found that printouts from the online Directory would only include the "Street 2" field if "Full Address" was checked. This was troublesome when attempting to print abbreviated directories without the full address in which the city, state, and zip code were not needed.

Re: Improper "Standardized" format for apartment addresses

Posted: Thu Nov 28, 2013 12:23 pm
by RossEvans
I notice that in a subsequent release of Clerk Tools the user interface has changed. But the underlying issue still obtains: The "suggested" address wrongly puts apartment numbers on the second line, contrary to USPS standards.

Re: Improper "Standardized" format for apartment addresses

Posted: Wed Mar 12, 2014 9:32 pm
by sbradshaw
In our ward, we put the street address and apartment number in the first address line, but come to think of it I think it'd be great if we put the apartment number in the second address line. I'm in a Provo YSA ward – our ward includes apartments 1–41 of an apartment complex. We often want to sort by apartment number when we create a directory but are unable to do so easily because the apartment number isn't separated out. By sorting by apartment we can see whose record still needs to be moved in (there are four people in each apartment, and if the directory only shows three then either there's a nonmember [missionary work!] or the records need to be moved in [clerk work!]. In most cases, I like the idea of using the USPS standard, but this is a use case for a different standard...

Re: Improper "Standardized" format for apartment addresses

Posted: Thu Mar 13, 2014 8:03 am
by RossEvans
sbradshaw wrote:In our ward, we put the street address and apartment number in the first address line, but come to think of it I think it'd be great if we put the apartment number in the second address line. I'm in a Provo YSA ward – our ward includes apartments 1–41 of an apartment complex. We often want to sort by apartment number when we create a directory but are unable to do so easily because the apartment number isn't separated out. By sorting by apartment we can see whose record still needs to be moved in (there are four people in each apartment, and if the directory only shows three then either there's a nonmember [missionary work!] or the records need to be moved in [clerk work!]. In most cases, I like the idea of using the USPS standard, but this is a use case for a different standard...
You could always override the suggested address if it were properly standardized in the online tool. But you would find other disadvantages even within MLS. Several standard reports -- including, for example, the new move-in report we routinely distribute in PEC and Ward Council -- are hard-coded to print only the first line of the address.

If I were you, with only 41 possible addresses within my "ward boundaries," I would just build a simple lookup table with all 41 discrete addresses in standardized form. It would then be a trivial matter to export the directory list and compare it to the lookup table when I needed to get the kind of specialized report you describe. This is even feasible in some Wasatch Front family wards, which might have only a few hundred discrete addresses within their boundaries.

However, in the rest of the country the scale is very different. There may be a couple hundred thousand discrete addresses within our ward boundaries, and just getting such a universal table of all possible addresses is not feasible -- especially for apartments. The U.S. postal standard was built for the general U.S. case, and USPS does have such a database for validation. Which is why the intent of the standardization tool is to follow the USPS rules. Unfortunately, it fails to do so.

Re: Improper "Standardized" format for apartment addresses

Posted: Thu Mar 13, 2014 11:41 am
by russellhltn
RossEvans wrote:Which is why the intent of the standardization tool is to follow the USPS rules. Unfortunately, it fails to do so.
What intrigues me is the report above that it adds the zip+4 to the address. It has to be doing a lookup, most likely against USPS tools.

Re: Improper "Standardized" format for apartment addresses

Posted: Thu Mar 13, 2014 12:37 pm
by RossEvans
russellhltn wrote:
RossEvans wrote:Which is why the intent of the standardization tool is to follow the USPS rules. Unfortunately, it fails to do so.
What intrigues me is the report above that it adds the zip+4 to the address. It has to be doing a lookup, most likely against USPS tools.
It may not directly use the USPS API, whose terms and conditions require usage to be associated pretty closely with mailing. Or perhaps those terms are being construed broadly. (I even applied for a USPS API user account a few years ago to build something for general ward use. But I didn't use the API account because I thought my intended application might be coloring outside the lines.)

However, there are several commercial services available for license. Also, just about any geocoding service does address-standardization as a byproduct, because that is the first step in matching the geocoder's address database. I think some might return extended Zip codes, just not officially "CASS Certified" by USPS.

Personally, on an interactive basis rather than batch or API processing, I still prefer the USPS web page for Zip lookup of a single address. On that scale -- at the price of a few extra clicks and keystrokes -- it returns lots of valuable information for free. That output includes an error message if the input address is invalid for mailing, or if there is a missing apartment number for a given street address known to USPS as a multiunit site. The only drawback is that the results come back all-caps. I have never seen the standardization tool in Clerk Resources return such error info for bogus addresses, which is another reason I doubt it is hitting the USPS API or a USPS-licensed data provider.

And, of course, the USPS site returns apartment addresses properly formatted on the first line.

Re: Improper "Standardized" format for apartment addresses

Posted: Sun Mar 16, 2014 11:16 pm
by chmsant
+1 for getting this changed! It's a pain in the butt and needs to be fixed.

Re: Improper "Standardized" format for apartment addresses

Posted: Thu Jul 10, 2014 1:38 am
by michaelcox
I've had it want to drop off the apartment completely if I insert, for example:

123 Main Street Apt 432
City, State 12345

It will return the suggestion of:
123 Main St
City, State 12345-6789

Can be a problem when sending out records and not paying close attention.