Verification status of a changed address

cdw3423 wrote:One guy here had damage to his house on 71st St from a tornado and while it was being fixed he lived in another house on Cedar Ln. His map location is marked as verified at the house on Cedar Ln, but he has been back at the house on 71st St now for quite a while (over a year I think). Wouldn't changing his street address to a completely different address (probably the same zip though) key the map to unverify his location and then do an address look-up to find the approximate new location?

No, changing the address doesn't unverify the address. The challenge is that some address changes are the result of address standardization, spelling corrections, or other changes that are unrelated to any move. In those cases you wouldn't want to have to reverify the address. But clearly it's also possible to move within a ward. Apparently the developers favor the first case over the second in how they treat address changes.

aebrown wrote:No, changing the address doesn't unverify the address. The challenge is that some address changes are the result of address standardization, spelling corrections, or other changes that are unrelated to any move. In those cases you wouldn't want to have to reverify the address. But clearly it's also possible to move within a ward. Apparently the developers favor the first case over the second in how they treat address changes.

I, for one, dissent from the developers' decision, which I think results in the most egregious defect of maps.lds.org today. It would be much better to favor accuracy. A changed address should simply reset the status and trigger geocoding the address anew. Not only is it difficult for clerks to manage the current process, but the display of seriously wrong locations, especially those flagged as "Verified," can only undercut the credibility of the product.

At the very least, when a clerk changes an address, he should be forced to answer the question is this just a clerical change or is it an actual change of address.

Chris W

RossEvans wrote:I, for one, dissent from the developers' decision, which I think results in the most egregious defect of maps.lds.org today.

I agree. While the current situation prevents unnecessary work, it allows wrong and misleading information.

+1. You can add me to the list of those who find themselves doing unnecessary work and not liking it one bit.

jdlessley wrote:+1. You can add me to the list of those who find themselves doing unnecessary work and not liking it one bit.

What's the unnecessary work you're referring to? It seems to me that the proposed change is the option that creates unnecessary work in some cases -- the cases where the address is adjusted for reasons (e.g., address standardization or spelling corrections) that don't involve an actual change of address. If an actual move occurs, a clerk is going to have to verify the address anyway (at least in my experience, the automatic geocoding is so inaccurate that it is rare that the marker is even placed on the correct lot).

cdw3423 wrote:At the very least, when a clerk changes an address, he should be forced to answer the question is this just a clerical change or is it an actual change of address.

Although this implies some changes to the back-end systems that are probably not trivial, this is probably the best solution of all, since it allows clerical changes to be made to the address without creating unnecessary work of moving and verifying a marker that was already correct, and also allows the marker to be "unverified" when an actual move takes place.

aebrown wrote:What's the unnecessary work you're referring to?

A household moves within the ward boundaries yet the position does not, nor is there a notice of a change. I am not the membership clerk and the membership clerk is not into keeping the map locations current. So when there is a change I do not know about it. I have to go through each household to find those that have moved and relocate the map location. That is a lot more work just to find so called verified locations and then move them. I would prefer that if a change has occurred to have the location revert to unverified. Trying to keep so called verified locations up to date following a within boundary move is more work than needs to be.

aebrown wrote:

cdw3423 wrote:At the very least, when a clerk changes an address, he should be forced to answer the question is this just a clerical change or is it an actual change of address.

Although this implies some changes to the back-end systems that are probably not trivial, this is probably the best solution of all, since it allows clerical changes to be made to the address without creating unnecessary work of moving and verifying a marker that was already correct, and also allows the marker to be "unverified" when an actual move takes place.

I'd make the rules this way: If it's a clerical change, then don't move a verified marker. If the marker isn't verified, then it should be moved based on the new results of the geocoder as the original non-standard address may have confused it the first time around. (Of course, if the change isn't just clerical, then the marker should be processed just like a new move-in.)

RussellHltn wrote:I'd make the rules this way: If it's a clerical change, then don't move a verified marker. If the marker isn't verified, then it should be moved based on the new results of the geocoder as the original non-standard address may have confused it the first time around. (Of course, if the change isn't just clerical, then the marker should be processed just like a new move-in.)

I can endorse suggestions to enable the clerk, when changing an address in MLS, to expressly check a box to leave the maps location unchanged. But I think the default behavior should be to reset the geocoding when addresses change.

The current system does not save effort on the part of ward clerks, but can actually increase it, because among the users of maps.lds.org who are deceived by wrong "Verified" information online are the clerks themselves, at both the ward and stake level. No one can be confident that a "Verified" address is really verified. If someone is newly called as a ward clerk, and finds that his predecessor has "Verified" many or all addresses but some are obviously wrong, the only method he most likely would have to be sure is to reverify every address because he cannot rely on the "Verified" status he sees online. Stake clerks, emergency coordinators, quorum and auxiliary presidencies, etc. -- any users of the data -- are also potential victims when the reported status online lies to them. Is it really a good idea, when the flood hits, to show the widow Jones at a "Verified" location on high ground when her true address is in the flood plain?

As for level of work, typically there is more than one person within a ward with MLS privilege to change an address, and our clerk's office is barely controlled chaos on Sundays. The clerk or assistant who updates an address handed to him on a scrap of paper may be the one updating MLS. If a conscientious clerk absolutely wants to avoid introducing errors into the map when updating a moved family that is "Verified," he must:

• Login to maps.lds.org and unmap the family.
• Change the address in MLS.
• Wait a day or so for the change to propagate to the maps site.
• Login to maps.lds.org and manually map the family's marker.

Frankly, I doubt that happens very often, if ever.

By contrast, if the new address were just automatically regeocoded when it changed, it would most probably be plotted at a location very close to its true lat/lon, and classified as "Unverified," just like any move-in. Then, filtering by "Unverified" status online, ward clerks can prioritize these addresses for verification because that status would be trustworthy.

If the concern really is to reduce the redundant work occasioned by address standardization by clerks, the right place to attack that problem is at its source. The best way to mitigate this inefficiency is to standardize and validate new move-in addresses before they are even sent down to local MLS systems. (This could have the additional substantive benefit of trapping invalid addresses from even being disseminated to wards in the first place. Right now our ward roster is burdened with more than a dozen invalid addresses sent to us, mostly missing apartment numbers, for less active families. They never should have gotten past Address Unknown because the true addresses are actually not known)

But meanwhile, developers should just get the current tool as it exists functioning according to the overriding principle that getting the data right online is paramount, and users should be informed reliably if it is ambiguous. This principle trumps any concerns about efficiency.

RossEvans wrote:The current system does not save effort on the part of ward clerks...

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.

RossEvans wrote:If the concern really is to reduce the redundant work occasioned by address standardization by clerks, the right place to attack that problem is at its source.

That would be a great improvement. It's probably a challenge to implement worldwide, but could be done fairly reasonably for countries that represent a large portion of the membership of the Church. Once implemented, it would render much of the previous discussion moot.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Biggles wrote: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.

Google Earth doesn't show the house number though, does it? If not, how does it help you to verify that the map is locating the address correctly. I have found that I can only verify addresses that I have been to.

nbflint wrote:Google Earth doesn't show the house number though, does it? If not, how does it help you to verify that the map is locating the address correctly. I have found that I can only verify addresses that I have been to.

In the majority of cases, certainly in the UK which has horrible street numbering, it is possible to work it out by going along a line of houses and getting a number then working out the correct one. It's not always easy, but as I stated before I can do it at my schedule. I did say using Street View, didn't I?

nbflint wrote:Google Earth doesn't show the house number though, does it? If not, how does it help you to verify that the map is locating the address correctly. I have found that I can only verify addresses that I have been to.

This is getting off-topic onto the general issue of how to verify addresses. But you might also try the Quick Geocoder at GPSVisualizer for a single address. Use the default Google geocoding, and pay attention to the detailed report that comes back. It should tell you how precise the Google geocoding was. (The Google geocoder's API that is doing the work reports when it is guessing.)

A reported status of "(precision: address)" on that tool should be reliable. Zoom in and eyeball the plotted location, then -- if need be -- drag the marker on maps.lds.org to that location and mark it "Verified." It may be that you can only verify it as "Approximately verified" if the precision is not good enough.

My preference for a rule set to cover this issue would be:

Any time there is a change to an address where the assigned ward does not change and if the location was verified, ask if the change was merely to standardize the address or if it represented an actual household move. If the change was due to standardization then leave the marker where it was and leave it verified. If the change was an actual household movement, relocate the marker, make it unverified and notify the user that the marker has been re-positioned and is now unverified.

Any time there is a change to an address where the assigned ward does not change and if the location was not verified, re-position the marker and notify the user that the marker has been automatically re-positioned and remains unverified.

These actions should be taken regardless of whether the change was made through MLS or the web application.

It would be nice if an address change initiated through the web application that looked to place a member outside of their assigned ward or branch would generate a message through MLS than an address change had been made that might necessitate a MLS Move.

egowen wrote:Any time there is a change to an address where the assigned ward does not change and if the location was verified, ask if the change was merely to standardize the address or if it represented an actual household move. If the change was due to standardization then leave the marker where it was and leave it verified. If the change was an actual household movement, relocate the marker, make it unverified and notify the user that the marker has been re-positioned and is now unverified.

A good suggestion. But please note all the steps it would take to implement: The question has to be added to MLS. The communication between MLS and CHQ has to be modified to carry the question. The new data has to be picked up by the mapping application and "understood". It also requires some training for the clerks on the meaning of this question and the ramifications.

The church developers work on many projects, presumably prioritized. The more complex the change requested, the longer it will be before it happens.

I finally got fed up with this enough to check the forums to see if this was reported. I was surprised that this is a considered a feature and not a bug. To anyone that isn't an original developer of this software, this is unintuitive (think "Principle of Least Surprise") and defeats the purpose of such a tool.

When you have people constantly moving (I'm in a singles ward but some of our family wards are similar) it is a waste of time to manually update it. Now add on top of that a 25%+ turn over every 6 months, there is no way people are going to even "verify" the locations (similar to how pointless it was keeping a picture directory up to date before pictures transfered wards with you). The website doesn't even make it clear why we need to verify and why it matters on maps but not the directory.

The idea of this tool is great. Elders Quorum presidents can get a better feel for how well home teaching is geographically distributed; FHE committee chairs can use it to divide the ward into FHE groups; and so on. Unfortunately because of this problem this amazing feature of lds.org is useless for my ward and I imagine quite a few other wards (singles like my ward, student married, low income, etc).

epage wrote:I finally got fed up with this enough to check the forums to see if this was reported. I was surprised that this is a considered a feature and not a bug. To anyone that isn't an original developer of this software, this is unintuitive (think "Principle of Least Surprise") and defeats the purpose of such a tool.

I can certainly see how the process for validating addresses could be improved. But in no way does this defeat the whole purpose of the tool. A clerk has to update the address when a member moves within the ward. The clerk simply needs to have the discipline to also verify the map location when this happens. It's not that hard.

aebrown wrote:The clerk simply needs to have the discipline to also verify the map location when this happens. It's not that hard.

To add what Alan is saying, there's only a few ways a member's address can change. When they first move in, the system tries to place the marker at it's best guess and marks it "unverified". But all further changes to the address is done by a clerk at the MLS computer. If you have the discipline and office procedures in place, then you'd know when you have to move a verified marker. The trick here is to limit the number of people who can edit the member's address.

(And for the record, yes, I'd like to see the current way it works changed.)

RussellHltn wrote:To add what Alan is saying, there's only a few ways a member's address can change. When they first move in, the system tries to place the marker at it's best guess and marks it "unverified". But all further changes to the address is done by a clerk at the MLS computer. If you have the discipline and office procedures in place, then you'd know when you have to move a verified marker. The trick here is to limit the number of people who can edit the member's address.

(And for the record, yes, I'd like to see the current way it works changed.)

I sure hope they end up changing it. I'm not a fan of the "apply discipline" approach:

1. DRY: We already changed it in one location, why do we need to change it in another?

2. Our clerk computers work fine for MLS but are slow browsing any modern website. If I am changing an address through the website, it is usually on my phone while I am moving the person or passing a leader in the hallway and a phone doesn't work all that well for updating the maps.

3. There isn't any kind of button in the maps to guess again at the new location. Instead you have to drag it around and hope you get close enough to where the house address is (which means you also need google maps up)

4. I'm always hoping this is a fluke that will end soon but for the last couple years we've not even kept a membership clerk for longer than 4 months (and our stake takes several months to respond to calling changes). Oddly as the executive secretary I end up picking up the slack. So (1)-(3) are more annoying when it isn't even your calling.