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.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.
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:
- Manually standardize the addresses as the families move in.
- 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.