Verification status of a changed address

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

Postby RossEvans » Mon Mar 05, 2012 6:47 am

aebrown wrote:I certainly agree with almost everything you said in your post, but that particular statement is certainly not correct. Yes, the current system can increase the effort required, and certainly will in cases where the address change reflects an actual move. But in cases where the change of address is simply a correction or standardization, your proposal will definitely increase the effort on the part of ward clerks, because it will once again require verification of an already-verified address. In this particular use case, the current system works perfectly and requires no extra work on the part of the clerk.

Please note that I am talking here only about the use case where the address change is a correction such as a standardization or spelling correction, not about an actual move. I know that the frequency of these two different kinds of address changes will vary dramatically in different stakes, and particularly in different areas of the world. But in an area (such as my stake) where the wards are very small geographically, the number of moves within a ward is very small (a handful of such events in the whole stake per year), whereas the number of address corrections and standardizations is much higher.


So the system as developed was optimized for Utah clerks, even to the point of sacrificing the veracity of what is being reported on the maps site! Truly, intraward moves are much more common outside the Wasatch Front, and those moves are more likely to be two miles than two blocks. Such Utah-first bias has influenced the design philosophy of the maps.lds.org project from the outset, when the original prototype was based on a dense and geographically tiny ward in Orem. I would bet that the uptake of this system has been greater in the Wasatch Front than elsewhere. (Ironically, it is in the less dense areas that mapping is more needed and would be more useful.) Our stake has not mandated the verification process on maps.lds.org , and although our ward clerk has verified most families as a labor of love, I notice that our neighboring wards have done little verification at all. The result is a product with locations that are not credible. So for any serious work, when I must trust the data, I eschew the maps.lds.org output and still geocode our own addesses externally.

Yes, the only redundant work that is being saved by the current workflow is that which might be caused by standardization and validation of addresses. It is also true that automated geocoding inherently depends on the quality of addresses. So for all of us, ward clerks must do two things:


  1. Manually standardize the addresses as the families move in.
  2. Manually verify and precisely locate the map markers.

Since changing the address (even just to standardize it) could improve the automated geocoding, that geocoding should be refreshed whenever addresses change, along with the status. The way to avoid redundant work is a matter of training the clerks to fix the addresses first, then wait to verify the locations until after the final automated geocoding has occurred. If clerks seek real-time updates, they would have to do it twice, but I doubt that real-time updates on maps.lds.org are occurring anyway. In all cases, the clerks could rely on the online status filtering to identify unverified addresses. I suggest that this training would become self-reinforcing if automated refresh of the geocoding were in place.

User avatar
aebrown
Community Administrator
Posts: 15096
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Mon Mar 05, 2012 8:47 am

RossEvans wrote:Since changing the address (even just to standardize it) could improve the automated geocoding, that geocoding should be refreshed whenever addresses change, along with the status.


I might agree with that statement IF the automated geocoding were better than it currently is. But the current automated geocoding is mediocre. At least in my stake, the automated geocoding is off by more than one lot (i.e., the marker is on the wrong house altogether) more often that not. So what you propose would make a lot more work in the case of standardization, at least for my stake. There's no reason to refresh the geocoding in the case of address standardization if the marker is already in the correct place.

But just because I offer a different point of view on one or two issues, please don't think that I disagree with you completely. To the contrary, I agree with at least 90% of what you're saying and I wish that the geocoding were better, and that the system didn't keep the marker in the same place for moves within the ward, and that there were address standardization, and that the system accommodated the differences between dense and sparse wards. I appreciate your efforts to constructively offer suggestions for improvement.
Questions that can benefit the larger community should be asked in a public forum, not a private message.

atticusewig
Member
Posts: 308
Joined: Fri Jan 19, 2007 9:48 am

Postby atticusewig » Mon Mar 05, 2012 9:22 am

While definitely more work, I could imagine a system that compares the previous address to the new address and
calculates a level of change. For example, 5 characters have changed in the street address. Based on this amount
of change it could determine whether standardization or an in-ward move has occurred and re-geocode or not based
on this judgement. Setting those thresholds would be tricky, and might have a few false positives, but I think it
could cover most cases. I think resetting the "Verified" flag for all address changes is probably a good practice.
As long as standardization doesn't move the marker, re-verifying addresses isn't that much extra work.

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

Postby RossEvans » Mon Mar 05, 2012 9:30 am

aebrown wrote:I might agree with that statement IF the automated geocoding were better than it currently is. But the current automated geocoding is mediocre. At least in my stake, the automated geocoding is off by more than one lot (i.e., the marker is on the wrong house altogether) more often that not. So what you propose would make a lot more work in the case of standardization, at least for my stake. There's no reason to refresh the geocoding in the case of address standardization if the marker is already in the correct place.

But just because I offer a different point of view on one or two issues, please don't think that I disagree with you completely. To the contrary, I agree with at least 90% of what you're saying and I wish that the geocoding were better, and that the system didn't keep the marker in the same place for moves within the ward, and that there were address standardization, and that the system accommodated the differences between dense and sparse wards. I appreciate your efforts to constructively offer suggestions for improvement.


There would be increased work for the clerk only if he verifies the location before he standardizes the address. If he is trained to fix the address first, then verify the location after the new geodcoding, there is no extra work. All the clerks would have to learn is the simple rule that changing an address for any reason would trigger a reset of the geocoding. That commonsense worklflow (which is inherent because geocoding is based on addresses) would be supported by an online status that always tells the clerks and other users the truth. And it would be reinforced naturally, as clerks learn to avoid the redundant work caused by verifying new locations before fixing the addresses.

As everyone seems to agree, an optimal system would allow the MLS clerk user, when changing an address, to override the reset of the geocoding. An even more optimal system would also provide MLS whatever automated address standardization works for each area of the world. In the United States, that technology is very mature; the mailing industry has used it for decades. I presume that similar technology is available In other developed areas. Where such address technology is not available, we obviously cannot expect it to be applied.

Meanwhile, if the automatic reset of the geocoding were simply applied on maps.lds.org, the harm experienced by those clerks who fail to learn the lesson of efficiency -- a little extra work -- would be far less than the harm of the status quo system: Today many address locations -- especially outside Utah -- are unnecessarily displayed in grossly wrong locations, and even falsely shown as "Verified." This harm is not just the fault of imperfect geocoding technology, but results from the way that technology is applied by design decisions.

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

Postby RossEvans » Mon Mar 05, 2012 9:45 am

atticusewig wrote:While definitely more work, I could imagine a system that compares the previous address to the new address and
calculates a level of change. For example, 5 characters have changed in the street address. Based on this amount
of change it could determine whether standardization or an in-ward move has occurred and re-geocode or not based
on this judgement. Setting those thresholds would be tricky, and might have a few false positives, but I think it
could cover most cases. I think resetting the "Verified" flag for all address changes is probably a good practice.
As long as standardization doesn't move the marker, re-verifying addresses isn't that much extra work.


I doubt that such methods would be effective. Even changing a few characters -- "1000 Lamar Blvd" vs "1000 N Lamar Blvd" or fixing the spelling a street -- might make a huge difference; but large changes lexically -- abbreviations, for example -- might make no difference. You really have to apply the logic of the geocoder to know.

What might work would be to store the empirical location that resulted from the last automated geocoding in the database, even if it has been overidden by manual verification for display online. Then the process could know if the address change made a substantive difference in the automated geocoding and could avoid a reset. That would make the processing complicated, but it might avoid unnecessary manual effort. Or it might still be best to keep it simple.

greggo
Member
Posts: 276
Joined: Thu Jan 24, 2008 9:36 am
Location: Paw Paw, MI, USA

Postby greggo » Tue Mar 06, 2012 11:28 am

I agree 100% with RossEvans.

To me it makes no sense to expect a map marker to NOT move based on the system's interpretation of the changed address (even if it's just a correction to the address and not an actual move). Lacking an option in MLS to indicate that it is not an actual move, I would expect to re-verify the location after the change.

Our ward is one where moves within the boundaries are relatively common (or corrections were made to addresses that were originally unmappable), and I estimate that probably 10 to 15% of the locations are wrong or not mapped at all. Is there a way to somehow "reset" the system to re-map all the addresses (barring moving out those in question and re-requesting the records with the same address)? As far as I know, my house is the only location that has been verified - so there's no concern there.

mikesir87
New Member
Posts: 4
Joined: Thu Mar 29, 2012 6:46 pm

Postby mikesir87 » Thu Mar 29, 2012 7:15 pm

We have had this issue as well. We live in a ward that has lots of students, many of which move to either save money or move into a larger place (growing families). However, verified locations aren't notified/updated. I'd be all up for when updates occur, verification is removed and geocode is performed. If a geocode doesn't resolve, keep the current location but mark as unverified.

aufderheide.j
New Member
Posts: 1
Joined: Wed Apr 11, 2012 4:01 pm

Why worry about verification?

Postby aufderheide.j » Wed Apr 11, 2012 4:08 pm

Hello,

For a small YSA branch that I belong to, I run the EQ and am the branch clerk. I don't think it is fair for a clerk to have to worry about verifying addresses. If an address is changed then the map should change. My branch is extremely transient with many address changing monthly and at least 10 records moving out a quarter.
I am not going to waste my time on verifying addresses on a map. Maps are suppose to tell us where things are, we are not suppose to tell the map where things are.
These need makes my branch/ward map completetly useless even to the point that when an address change does happen the unverified address stays at the old address location.

Just get rid of this process, we have enough to do. Please let the Ward/Branch Counsels keep track of verified addresses, as they are the ones that actually need the information.

Thanks

Josh Aufderheide
Ocean YSA Branch, Santa Cruz Stake

User avatar
nbflint
Member
Posts: 204
Joined: Mon Mar 12, 2007 8:07 pm

Postby nbflint » Fri Apr 13, 2012 8:03 am

aufderheide.j wrote: Please let the Ward/Branch Counsels keep track of verified addresses, as they are the ones that actually need the information.


There is some merit in allowing other ward members assist in the verification process. My ward encompasses an entire city of 27,000 people, half a city of 86,000 people and dozens of small towns up to a hour or more drive away. Our membership records list 500 people and we have an average sacrament attendance of 70.

As the ward clerk, verification of the location of households in my ward is nearly impossible. I can't visit every home in the ward to verify it's location. Extending verification rights to the ward council could make the system more useful to our ward.


User avatar
Biggles
Senior Member
Posts: 1159
Joined: Tue May 27, 2008 4:14 am
Location: Watford, England

Postby Biggles » Fri Apr 13, 2012 8:24 am

I find that using Google Earth/Street View is a great tool to be able to use to verify. No fuel usage, no air pollution etc.. Done then at my schedule.


Return to “Maps”

Who is online

Users browsing this forum: No registered users and 1 guest