Standardizing MLS Addresses

Discussions around using and interfacing with the Church MLS program.
jbh001
Senior Member
Posts: 856
Joined: Thu Mar 13, 2008 6:17 pm
Location: Las Vegas, NV

Standardizing MLS Addresses

#1

Post by jbh001 »

boomerbubba wrote:I am definitely opposed to abusing the existing fields. Address fields, phone-number fields, email fields, etc, should contain exactly what they are labeled to contain, and not extraneous comments. Clerks should not write in . . . "big white house at the end of the road," or any other spurious remarks.
Then your unit is obviously not in rural Oklahoma. :D
scion-p40
Member
Posts: 259
Joined: Sun Apr 22, 2007 12:56 am

Standardizing MLS Addresses

#2

Post by scion-p40 »

Hmmmm . . . . perhaps our data fields are not only US centric, but also focused on more populated regions than rural regions. A freeform field with enough space to write some directions, a neighborhood, etc., would be helpful.
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

#3

Post by aebrown »

scion wrote:Hmmmm . . . . perhaps our data fields are not only US centric...
The MLS address format is indeed US-centric in the US, but not anywhere else. The address format is controlled by settings from the local administration office, so there is flexibility to handle different formats in different countries. There's no way to see that flexibility in a US-based MLS installation, but the MLS developers did allow for different formats.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#4

Post by RossEvans »

Alan_Brown wrote:The MLS address format is indeed US-centric in the US, but not anywhere else. The address format is controlled by settings from the local administration office, so there is flexibility to handle different formats in different countries.

In that case, it is too bad they did not take the next step and include USPS validation and standardization of US addresses. If not at the point of data entry in MLS itself, because many units are not on the Internet, then such functionality could still be built in as batch processing at CHQ. This is hardly leading-edge technology. Other large organizations have been doing it for many years.

Addresses in our ward's MLS database are a mess, and since many of them originated with clerks elsewhere -- or even with church headquarters -- when records were shipped to us, I presume we are not alone.
lajackson
Community Moderators
Posts: 11460
Joined: Mon Mar 17, 2008 10:27 pm
Location: US

#5

Post by lajackson »

boomerbubba wrote:Addresses in our ward's MLS database are a mess, ...
In the good old [hehehe] MIS days, I used to go through the files to standardize the addresses and phone numbers. After I had done it a few times, I figured I could print a report and visually scan it to check for needed changes.

I used to export my reports to WordPerfect, so it was easy to find differences that needed correction. I would edit the report, delete all the good lines, then print out the page with the five or six names that needed fixing and take care of it the next time I was at the computer.

If I was diligent in looking over all of the incoming records, I found I could do the standardizing about once a quarter to keep up.
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

#6

Post by aebrown »

boomerbubba wrote:In that case, it is too bad they did not take the next step and include USPS validation and standardization of US addresses. If not at the point of data entry in MLS itself, because many units are not on the Internet, then such functionality could still be built in as batch processing at CHQ. This is hardly leading-edge technology. Other large organizations have been doing it for many years.
While I agree that USPS validation would be very helpful, I hope I did not give the wrong impression when I mentioned the MLS address formats. The flexibility in MLS allows for different order of fields (does Country come before Street Address 1, etc.), the presence of a State or Province field, postal codes, etc.

MLS doesn't dig down into what is actually in a Street Address field to distinguish between 123 North Main, 123 N Main Street, 123 Main St, etc. I understand that this is part of what you are proposing MLS should do, and I don't disagree, but I just wanted to clarify what I meant by MLS address formats.
boomerbubba wrote:Addresses in our ward's MLS database are a mess, and since many of them originated with clerks elsewhere -- or even with church headquarters -- when records were shipped to us, I presume we are not alone.
Although it would be nice if there were tools to automate the standardization of addresses, in the meantime, there is nothing stopping clerks from updating addresses by hand to conform with USPS and mapping standards. It may take a few hours to clean up a ward's addresses, but then the job is done and addresses for new move-ins are more likely to be done correctly. Ongoing maintenance should be minimal.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#7

Post by RossEvans »

Alan_Brown wrote:
Although it would be nice if there were tools to automate the standardization of addresses, in the meantime, there is nothing stopping clerks from updating addresses by hand to conform with USPS and mapping standards. It may take a few hours to clean up a ward's addresses, but then the job is done and addresses for new move-ins are more likely to be done correctly. Ongoing maintenance should be minimal.

That has been our intention. We have even explored options for getting a spreadsheet of standardized addresses from 3rd party sources for cut-and-paste efficiency.

But in our huge ward, the time burden is steep. Our overburdened membership clerk started out on a full pass through the roster to make all addresses conform to USPS style. It took him two hours to get through A-B in the alphabet. The biggest frustration is the multiple steps in the MLS user interface, and accompanying latency, to call up each member record and edit it.

So given other pressing matters we have had to deprioritize this task. In the short run, the geocoding scripts that we now run routinely do have the ancillary benefit of kicking out the most serious errors -- misspelled streets, etc. -- into a couple of error/warning files for review. So we focus on those. If MLS had a generalized import capability for selected fields -- the address fields, for example -- that depend on local data entry, that would also be a big help.

I still think integrating the scrubbing of addresses into MLS or its central parent database is optimal. When the heralded new member-mapping app that church developers are working on is built, its quality will rest on this foundation of millions of questionable addresses harvested from all our MLS databases. GIGO.

I have a hard time conceiving of how this can work without harnessing the labor of all the clerks to deal with errors and ambiguities, even with automated assistance. But it is a big job, and is really not feasible without such tools.
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

#8

Post by aebrown »

boomerbubba wrote:The biggest frustration is the multiple steps in the MLS user interface, and accompanying latency, to call up each member record and edit it.
If you use MLS efficiently, and you are working through the list alphabetically (which your A-B comment strongly implied), the number of steps involved to call up each household record after the first household is precisely 1 click.

All you have to do is:
  1. Go to Membership, View and Update, Household Record
  2. If necessary, scroll to the first household to edit, then double click it
  3. Click on Address in the left navigation
  4. Click Edit
  5. Enter the new information (hopefully just the address and postal code)
  6. Click OK
  7. Click the blue right triangle in the upper right corner
That last click is the only click necessary to call up the next household. At that point you are still positioned on the Address page for the next household. Then repeat the process from Step 4 for each household.

If you're not using this technique, then you are probably clicking Close instead of the step 7 I described. I can see how it would be frustrating to have to go back to step 1 for every household. But with the above process, there is practically no effort or latency involved in moving from household to household.

I'm not trying to minimize the size of the overall task, but it seems like the work to standardize the addresses is a far bigger task than inputting those addresses in MLS, yet you pointed out the MLS entry as the biggest frustration. So you probably aren't doing it the way I described above, and so you could save a lot of time by changing your approach.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#9

Post by RossEvans »

Thanks, Alan. I will pass along your tutorial.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#10

Post by RossEvans »

Alan_Brown wrote:
I'm not trying to minimize the size of the overall task, but it seems like the work to standardize the addresses is a far bigger task than inputting those addresses in MLS, yet you pointed out the MLS entry as the biggest frustration.

Just to clarify, the user-interface issue was the biggest frustration of the guy actually performing the work. I did not mean to understate the general problems we have encountered trying to get a source of standardized and validated addresses. This problem is difficult to tackle on the ward level, but I would expect the church to have more opportunities of scale.

Just to share what I have learned:
  • On a one-at-a-time basis, if the user has an Internet connection, the USPS web site will validate an address at http://zip4.usps.com/zip4/welcome.jsp Be aware of a maddening thing about this method: The new address is returned in all-caps.
  • If you are willing to do a little programming, and the USPS approves of what you are doing and grants you an application ID, you can build your own tool based on XML transactions. http://www.usps.com/webtools/?from=zcls ... k=webtools After several rounds of negotiating with the Postal Service, I recently obtained such an ID. But I had to commit to using it only in an application that required user interaction per transaction, not just a batch script, and to apply the addresses for purposes of mailing. Given those conditions, I have not yet proceeded to build an app.
  • Because the USPS basically cripples its applications and their terms of use to defer to private-sector players, for batch processing it is probably best to deal with one of the well established specialty vendors that produces software or services certified to comply with postal standards. The one product I found that seems most nearly in reach of a ward budget is http://www.semaphorecorp.com/CGI/zp4.html I have not tried it and cannot vouch for it, and at $99 (which might need to be repeated soon if your area has as lot of new construction, etc.) this is a non-trivial expense for a ward budget.
  • I also explored some commercial service-based models, but basically we are too small to be their customer. One high-end vendor, Proxix, did run a test file for me gratis, with the bishop's approval. Their forte is really geocoding, not postal processing, but the address results look pretty good (As a general proposition, while geocoding and postal addressing are related, the two goals sometimes are not identical. So a process optimized for geocoding may not always be the best source for addresses if the objective is 100% USPS purity, and vice versa.)
  • As a byproduct of our homegrown geocoding scripts, which use Yahoo's free geocoder, we do capture a reformatted address. But although Yahoo's addresses are sorta-kinda close to USPS standards, they are not perfect. If I had any doubts about an address I would recommend cross-checking it manually against the USPS web site above.
  • All the methods above can be expected to leave a small but significant number of exceptions and ambiguities that requiere intelligent human effort to resolve.
Given some combination of the above, in our particular ward, we can probably come up with some file in a spreadheet that can be used for cut-and-paste editing into the MLS user interface. But it is not at all reasonable to expect thousands of wards to invest the same effort we have on this problem. The biggest lesson learned from this excercise is that the scale of the solutions, not to mention the architecture, demands attention from CHQ.
Locked

Return to “MLS Support, Help, and Feedback”