Improper "Standardized" format for apartment addresses

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.

I concur 100%. This needs to be fixed.

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.

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.

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...

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.

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.

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.

+1 for getting this changed! It's a pain in the butt and needs to be fixed.

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.

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

That's even worse! Seriously, can we get someone to look into this?

We have been updating our records in Leader and Clerk Resources and when prompted have used the suggested address with the Apt on the second line. Our Relief Society Visiting Teaching Coordinator has been trying get our members visited and she printed a directory on MLS to take home and use to assign visits. Unfortunately, the directory doesn't print the newly formatted apt #'s. Is there a feature I can turn on so directories will print the second address line or is there a different procedure we should be using?

1historian wrote:Our Relief Society Visiting Teaching Coordinator has been trying get our members visited and she printed a directory on MLS to take home and use to assign visits. Unfortunately, the directory doesn't print the newly formatted apt #'s. Is there a feature I can turn on so directories will print the second address line or is there a different procedure we should be using?

When creating the abbreviated directory, there's a "customize" link in the upper right. Click on that an you're given the option to add the second line. However, it doesn't seem to stick, so that has to be done each time.