Improper "Standardized" format for apartment addresses

Discussions about the Leader and Clerk Resources on lds.org.
RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Improper "Standardized" format for apartment addresses

Postby RossEvans » Tue Jul 02, 2013 12:09 pm

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.

rontilby
Member
Posts: 129
Joined: Mon Apr 20, 2009 7:22 pm
Location: Salt Lake City, UT, USA

Re: Improper "Standardized" format for apartment addresses

Postby rontilby » Tue Jul 02, 2013 12:27 pm

I concur 100%. This needs to be fixed.

jdlessley
Community Moderators
Posts: 6527
Joined: Sun Mar 16, 2008 11:30 pm
Location: USA, TX

Re: Improper "Standardized" format for apartment addresses

Postby jdlessley » Tue Jul 02, 2013 12:48 pm

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.
JD Lessley
Have you tried finding your answer on the LDS.org Help Center page or the LDSTech wiki?

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Re: Improper "Standardized" format for apartment addresses

Postby RossEvans » Thu Nov 28, 2013 12:23 pm

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.

User avatar
sbradshaw
Senior Member
Posts: 2501
Joined: Mon Sep 26, 2011 8:42 pm
Location: Provo, UT
Contact:

Re: Improper "Standardized" format for apartment addresses

Postby sbradshaw » Wed Mar 12, 2014 8:32 pm

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

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Re: Improper "Standardized" format for apartment addresses

Postby RossEvans » Thu Mar 13, 2014 7:03 am

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.

russellhltn
Community Administrator
Posts: 20780
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Re: Improper "Standardized" format for apartment addresses

Postby russellhltn » Thu Mar 13, 2014 10:41 am

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.
Have you searched the Wiki?
Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Re: Improper "Standardized" format for apartment addresses

Postby RossEvans » Thu Mar 13, 2014 11:37 am

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.

chmsant
Member
Posts: 51
Joined: Mon Sep 19, 2011 11:00 am
Location: Elk Grove, CA, USA

Re: Improper "Standardized" format for apartment addresses

Postby chmsant » Sun Mar 16, 2014 10:16 pm

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

michaelcox
Member
Posts: 67
Joined: Sun Feb 18, 2007 12:51 am
Location: La$ Vega$, NV, USA
Contact:

Re: Improper "Standardized" format for apartment addresses

Postby michaelcox » Thu Jul 10, 2014 12:38 am

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.


Return to “Leader and Clerk Resources”

Who is online

Users browsing this forum: No registered users and 2 guests