Filtering on verified location status missing

The previous version allowed a nice filter to sort those households that are verified, unverified, unmapped (looks like this status has been changed to unknown), or approximate location. This ability is missing but is very, very useful.

The use case is that our ward was able to start with the Ward List and start organizing every household based on whether we knew they were there or not. We were able to filter out the list based on the status and (using the download utility or the print map utility, printing only the pages with the names) with the help of the FTMs in our ward reduce the number of households we knew nothing about to a much smaller number. This is allowing us to know where we needed to spend our efforts and which households we should focus on finding a new address for, in one way or another.

It's such a simple feature, but has turned out to be an important tool in organizing our efforts. Please make sure it isn't left out of the new version.

dobrichelovek wrote:The previous version allowed a nice filter to sort those households that are verified, unverified, unmapped (looks like this status has been changed to unknown), or approximate location. This ability is missing but is very, very useful.

The use case is that our ward was able to start with the Ward List and start organizing every household based on whether we knew they were there or not. We were able to filter out the list based on the status and (using the download utility or the print map utility, printing only the pages with the names) with the help of the FTMs in our ward reduce the number of households we knew nothing about to a much smaller number. This is allowing us to know where we needed to spend our efforts and which households we should focus on finding a new address for, in one way or another.

It's such a simple feature, but has turned out to be an important tool in organizing our efforts. Please make sure it isn't left out of the new version.

Thanks for your feedback, it's on list of to-do items.

dobrichelovek wrote:The previous version allowed a nice filter to sort those households that are verified, unverified, unmapped (looks like this status has been changed to unknown), or approximate location. This ability is missing but is very, very useful.

The use case is that our ward was able to start with the Ward List and start organizing every household based on whether we knew they were there or not. We were able to filter out the list based on the status and (using the download utility or the print map utility, printing only the pages with the names) with the help of the FTMs in our ward reduce the number of households we knew nothing about to a much smaller number. This is allowing us to know where we needed to spend our efforts and which households we should focus on finding a new address for, in one way or another.

It's such a simple feature, but has turned out to be an important tool in organizing our efforts. Please make sure it isn't left out of the new version.

Thanks for your feedback, this is on our list of to-do items.

Erin, thanks for following up confirming that it is in the works. I'm glad to know that, as a feature, it will be back. That feature combined with the ability to sort the list by map number have been great tools that allow us to be more efficient in finding people and organizing visits.

So I'm curious now that the old map app has been replaced with the new version. I still don't see the ability to filter on the status of household location information (verified, unknown, etc.) and this is a really important feature that we had before. Is it there and I just can't find it, or is it not yet implemented? Erin suggested it was on the to-do list. Is it still there?

dobrichelovek wrote:So I'm curious now that the old map app has been replaced with the new version. I still don't see the ability to filter on the status of household location information (verified, unknown, etc.) and this is a really important feature that we had before. Is it there and I just can't find it, or is it not yet implemented? Erin suggested it was on the to-do list. Is it still there?

The option is there for me. Just above the directory, next to the search box, there is a funnel-shaped icon with a drop-down arrow. Clicking the arrow shows the filter options, which include the verification status.

But from your initial post, I don't understand your use of this feature. You said:

The use case is that our ward was able to start with the Ward List and start organizing every household based on whether we knew they were there or not. We were able to filter out the list based on the status and (using the download utility or the print map utility, printing only the pages with the names) with the help of the FTMs in our ward reduce the number of households we knew nothing about to a much smaller number. This is allowing us to know where we needed to spend our efforts and which households we should focus on finding a new address for, in one way or another.

But the concept of verification within the maps.lds.org application is supposed to refer to whether that address is plotted correctly at that location, not whether the member actually lives at the address. Verification is essentially just a manual geocoding step.

RossEvans wrote:The option is there for me. Just above the directory, next to the search box, there is a funnel-shaped icon with a drop-down arrow. Clicking the arrow shows the filter options, which include the verification status.

As it turns out, the filter-by-verfification-status is not there after all. When I posted the comment above yesterday, I was apparently pointed at the older version of the maps application, which I reached from logging into lds.org and selecting Tools -> Maps. But now, following that same login path, I am pointed at the new version of the maps application.

And dobrichelovek is correct. That filter option is absent. The option was very useful for its intended purpose of tracking verification of the geocoding. You can work around that by downloading the member list as a CSV, which displays the information in the Location Status column.

RossEvans wrote:[...] from your initial post, I don't understand your use of this feature. [...]

But the concept of verification within the maps.lds.org application is supposed to refer to whether that address is plotted correctly at that location, not whether the member actually lives at the address. Verification is essentially just a manual geocoding step.

So let me try to explain how we have been using it once more.

Yes, we use the verification status to identify whether the location is plotted correctly, but what would be the point of verifying an address at the correct location when we have discovered that the person doesn't live there at all? When we started we had a list of member households (over 100) that nobody in the ward leadership knew anything about, and we started with all households unverified. We quickly were able to verify those who come to church and those who were receiving their home and visiting teachers regularly, but we needed an organized way to keep track of, and sort through, those who were left.

The verification status of the maps worked great for this purpose, as we were able to change the status of those households where we knew that the members of that household were either there or not. The list of unverified locations were households that we still needed to address, those who no longer live in the ward were unmapped and put on the list of households that the clerk needed to deal with. Almost everyone else was verified as being where they were mapped, whether we see them regularly or not.

The point I made about the use of the filter feature is the fact that it would carry forward (in the previous version) to printing, allowing us to filter on the statuses when printing a map and unit list associated with that map. When the missionaries or quorums printed the map, they could filter on those who were verified, or those who were unverified (depending on their goals for the map) and sort them according to map number, which is a rough North-South/West-East filtering of the addresses, so the households would be generally grouped based on their neighborhoods, allowing those who were going to visit an easy way to consider a nearby household to their current location after a dinner appointment or some other visit. In areas where the units take up more than four city blocks this tends to be particularly useful.

I am aware that it is possible to download the list into a .csv file, but this doesn't address the point I just made about being able to use that filtered list when applying it to the map when printing and using a map-number sorting.

The download doesn't work correctly for some other languages, either, and gives unreadable characters when downloading the file, instead of household names. This is currently a problem in units where their language is based on Cyrillic characters. Not really a workaround for those whose language wasn't considered (or if it was, the fix hasn't been a priority) when the feature was implemented.

So, if the concept of the verification status was only meant to whether the address was plotted correctly and I am using it incorrectly, then I guess I didn't quite understand correctly but I figured it's a forgivable offense, since it really met the need that we had in our ward and I am advocating for it, with this explanation, as a way to accomplish the same things we did where the lists had gotten stale and we needed to sort them out.

I was hoping, by bringing it up when the new version first entered Beta, to avoid the situation where this feature was missed in the new version when it 'officially' replaced the old one. I am hoping, as I said, that this feature is still on the list and will be implemented.

dobrichelovek wrote: Yes, we use the verification status to identify whether the location is plotted correctly, but what would be the point of verifying an address at the correct location when we have discovered that the person doesn't live there at all? When we started we had a list of member households (over 100) that nobody in the ward leadership knew anything about, and we started with all households unverified. We quickly were able to verify those who come to church and those who were receiving their home and visiting teachers regularly, but we needed an organized way to keep track of, and sort through, those who were left.

The verification status of the maps worked great for this purpose, as we were able to change the status of those households where we knew that the members of that household were either there or not. The list of unverified locations were households that we still needed to address, those who no longer live in the ward were unmapped and put on the list of households that the clerk needed to deal with. Almost everyone else was verified as being where they were mapped, whether we see them regularly or not.

Much better to use the application as designed. There is always an ongoing task of tracking MLS membership when records come in without verifying that the members are really there. But that is a larger, complex problem that needs to be worked outside the maps application.

During the period between the time the member's presence at the address is confirmed to be wrong and the time the clerk resolves that situation in MLS, I suppose there is no harm in unmapping the location on maps.lds.org. Only bishopric members and clerks have the privilege to do that, anyway, with good reason. This is their responsibility. But the maps application does not come close to meeting the clerks' need for tracking the status of lost members and forwarding addresses, etc. They and other ward leaders still have to keep this family on some separate to-do list to distinguish it from other addresses that simply could not be geocoded, which is the documented definition of what unmapped is supposed to mean on the website.

If the clerk does unmap the address during this period of limbo, then it doesn't interfere with the map-based canvassing effort you describe -- without additional filtering -- by other ward leaders.

But there is confusion introduced among all users if members are told that "Unverified" effectively means, "We don't even know if this person really is in the ward at all." In fact, many active members may show up as "Unverified" for some significant period of time. Since the "Unverified" status was typically assigned automatically by a geocoding process that is inherently fallible, all that status is supposed to communicate is that there is a chance the geocoding might be inaccurate. Conversely, rank-and-file users should not be led to believe that "Verified" means anything more than it is supposed to mean in the churchwide design of the maps applications -- that the geocoding of the address is accurate. Clerks often can verify that much using online tools without ever going to the location.

Just by showing up at the door and confirming or refining the geocoding on a GPS-enabled phone, that address can be marked "Verified" even if no one answers the doorbell. That itself is progress for the clerk, who ultimately is responsible for setting the location status of everyone on maps.lds.org. Once the geocoding is flagged as "Verified," he knows that he does not need to repeat that task.

RossEvans wrote:Much better to use the application as designed. There is always an ongoing task of tracking MLS membership when records come in without verifying that the members are really there. But that is a larger, complex problem that needs to be worked outside the maps application.

Well, we're using it as it was designed, just for a purpose that wasn't originally intended, which is often how products morph into something better and more useful. But that's a discussion beyond my point.

In reality, all new addresses (so far, unless I misunderstand the way the process works) get put in an unverified status until someone who has permission changes that. This serves very well as a list of households that haven't yet been 'processed' and I see absolutely no reason to not utilize this a a good starting point for a trigger for other activities (much like the member's moved in list, but with a state machine that takes them off the list once they have been verified) that need to happen. Is it THE solution to what we are trying to do? No. It's a tool, just like all the other lists that are available in MLS, which would be a greater burden on the Clerk if he had to distribute the same information to those who can now get it so easily when we use it this way. Your point about tracking MLS membership being larger than this is well understood, but it met our needs to get things under control, and continues to meet the need by giving the WML a list of new members to visit when the missionaries (ward or full-time) are in a certain area and an appointment falls through. If we simply used it to confirm or correct the accuracy of an automated geo-location attempt, we would be getting busy work done, but in this case, we get that task done and accomplish even more.

What we do is run the risk of the program changing and not working as we have come to expect because it was not originally intended to meet the need it happens to fill so nicely. I suppose it is a risk that I think is worth it, but in general, most people use something the way it is designed without specific regard to how it was intended to be used. I think it's a great thing that it was originally designed in a way that was not restrictive so that we could get something done that was needed in a more efficient way.

Should all the members come to expect that a certain status means something specific? No, probably not, but I also see no reason why members that aren't where their address says shouldn't be unmapped, and the clerk could use that list of unmapped households to do what a clerk should do with those households, including moving them out, or correcting their address and verifying their correct location. Members that aren't verified are a good indication that someone needs to verify that location, and if we make an effort to ensure that someone is actually there in the process, it's a good thing in my book... because that means there was personal contact, instead of just a verified address. If the HPGL and the EQP and the RS President happen to use the list to make sure they have home and visiting teachers for everyone who has been verified, because we know that they are actually there, then they can at least have a better hope that they won't be sending someone to a house where a member never actually lived, because we have already dealt with that in the process of 'verifying' the address.

So, wherever this documented understanding of what verified means is canonized, I hardly think that what we have chosen to do with this tool breaks that, because at the end of the day we have verified that a household address is physically where it is represented on the map, but we also have taken the opportunity to sort out and visit those individuals who are actually there, represented by a dot. While doing so, we might have saved some home teacher months of frustration knocking and getting no answer, just to find out that the person actually lived across the street... even though the address that was recorded was 'verified'. Perhaps a spiritual thought was shared with someone who needed to hear it while we did just a little more than confirming the address was plotted correctly.

Respectfully, if your goal was to convince me that our use was not really acceptable, you'll have to try again. I can be stubborn sometimes.

But the whole point of my reviving this thread is still not accomplished. Is the filter for location status still a feature that will be implemented? I am trying to make the case that is should be, even if it's not a documented and approved reason... it is effective and has uses that make it more effective to serve those for whom we have responsibilities.

dobrichelovek wrote:But the whole point of my reviving this thread is still not accomplished. Is the filter for location status still a feature that will be implemented? I am trying to make the case that is should be, even if it's not a documented and approved reason... it is effective and has uses that make it more effective to serve those for whom we have responsibilities.

It's currently on our list for a future release. We understand that it has proven useful but due to constraints in development resources and other features receiving higher priorities it didn't make the cut for this release. I'll continue to bring this up in project planning meetings but it is up to our product owner and I can't give you a definitive answer as to when this will be completed.

dobrichelovek wrote: Should all the members come to expect that a certain status means something specific? No, probably not, but I also see no reason why members that aren't where their address says shouldn't be unmapped, and the clerk could use that list of unmapped households to do what a clerk should do with those households, including moving them out, or correcting their address and verifying their correct location.

If you read my comment, you will see that I don't disagree that such members could be unmapped.

However, the clerk will need to record more information than that externally to track the membership-in-ward status. He must try to get a new address and record it in MLS, moving the record if necessary, or moving it to Address Unknown. Several intermediate actions are probably required, such as mailing to seek a forwarding address, searching other online resources, etc. All of that is beyond the scope of the map application. Meanwhile, the category of unmapped also can include members who actually live at addresses in the ward that are just not geocoded. So he will have to distinguish those cases outside the maps application.

dobrichelovek wrote:Respectfully, if your goal was to convince me that our use was not really acceptable, you'll have to try again. I can be stubborn sometimes.

I don't disagree with that, either.

But I still believe that abusing designed field values for undocumented purposes is a bad practice. On that larger point we will have to agree to disagree.

First, Erin,

Thank you again for your response. I guess I thought that it might have made it in before turning off the other version, basically regressing a feature that already existed. I do understand the reality of resource constraints, however, and appreciate you clarifying once again that it is still a planned feature. You have told me what I hoped to know, and I'll just look forward to that capability returning.

Secondly,

RossEvans wrote:If you read my comment, you will see that I don't disagree that such members could be unmapped.

However, the clerk will need to record more information than that externally to track the membership-in-ward status.

I think we are generally on the same page here, and I did see that from what you wrote. I basically said the same thing, that it's only a starting point for what a clerk would have to do more than that. No arguments or disagreements there.

RossEvans wrote:But I still believe that abusing designed field values for undocumented purposes is a bad practice. On that larger point we will have to agree to disagree.

We're just not fully on the same page here, and that's fine with me, to agree to disagree. I get the point of not using field values in an undocumented fashion, in programming, and generally agree with that. For what we needed the tool as constituted served our purposes as designed, whether documented or not, of allowing us to 'filter' the households based on how we have verified the status within our own unit. The benefits of using the tool as it is for this purpose in our unit outweighed the problems that might be associated with it not being a perfect and complete solution, when other options were more cumbersome. I just don't see the point of not using a tool that works when it makes things better, but maybe, to your point of it being bad practice, I might refrain from actively advocating it any more than I have. I'm sure I've done enough damage as it is.

I find the use that dobrichelovek and his ward have come up with for the "unverified/verified" feature quite interesting. I had never thought of "verified" as having an extended definition beyond the manual agreement of a geocoded position. I like this thinking. I do, however, see some validity to RossEvan's concern about the intended use of a feature.

When we use a feature of an application beyond its intended use there is the possibility of confusing the users of the application who view the results of this creative use. For dobrichelovek and those who are "in" on the extended definition there is no problem. There is actually an added benefit. But to those who are not "in" on the extended definition there can be confusion. What happens to a member in dobrichelovek's ward who understands the definitions of verified and unverified as was used in that ward who then moves to another ward where the intended programming definition is used?

As long as those using the extended definition are aware of the intended definition then there probably is no concern.

jdlessley wrote:I find the use that dobrichelovek and his ward have come up with for the "unverified/verified" feature quite interesting. I had never thought of "verified" as having an extended definition beyond the manual agreement of a geocoded position. I like this thinking. I do, however, see some validity to RossEvan's concern about the intended use of a feature.

I think dobrichelovek's use is rather clever. In most wards, "unverified" really means "we haven't gotten to it yet". His approach of not verifying until the member themselves have been verified would seem to have some merit. It is a more complicated work flow, but if they're happy to do it that way, I don't see a problem.

The only downside I can see with this unusual approach is that someone may misinterpret "unverified" as a recent move-in. But to do that, you'd have to know how often (if ever) the ward goes though verifying all the addresses. In either case, the desired report is useful for all wards because in all cases "unverified" means there's work that needs to be done.

In my mind, the bigger issue is how in-ward moves are handled. (Showing the old location as "verified".) But I think we've beaten that horse to death.

I do agree that in general trying to use things in a different manner has problems, but I'm missing the issue on this one.

RussellHltn wrote: The only downside I can see with this unusual approach is that someone may misinterpret "unverified" as a recent move-in. But to do that, you'd have to know how often (if ever) the ward goes though verifying all the addresses. In either case, the desired report is useful for all wards because in all cases "unverified" means there's work that needs to be done.

I think the more general downside is potential confusion. That confusion can arise among units, across member moves, and across changing callings, both in the minds of rank-and-file users and leaders.

Another practical downside is that by creatively adopting a higher bar before coding an address as "Verified," the clerk delays hitting the desired geocoding standard, thereby thwarting the common goal of capturing rooftop-accuracy geocoding for all member addresses. Capturing that fundamental data correctly is a prerequisite for actually using the lat/lon for many worthwhile purposes (emergency prep, boundary analysis, HT/VT planning, fast-offering routes, etc.).

I am quite sure that if we adopted that higher bar in our huge ward, we would never achieve "Verified" status for everyone.

One purpose of the mapping tool is to build a churchwide asset, useful across wards, stakes and areas, by capturing standardized data in a central database. That asset is devalued when local units make up their own rules for the content. This is not a free-form field, by design. The developers built a handful of discrete values that can be chosen in the user interface. Discrete, required values are supposed to have defined meanings. (Even in unstructured text fields, I also object to writing comments into fields labeled phone or street address just because a user invents some short cut. That's Database Management 101, Application Design 101 and should be Clerk Training 101, too.)

I have always thought it unfortunate that clerks are obliged to manually verify the geocoding of most addresses in the first place, given the state of the art. But the system is what it is, and clerks should follow consistent rules. For most developed areas, at least it is usually feasible for clerks to verify geocoding using online resources alone, without the additional time, work and perhaps travel required if they conflate this task with confirming each member's residential status.

Also, if some units creatively define "Verified" to mean that the member is confirmed to live at the address, another ambiguity immediately arises: As of when? If you want to record confirmed physical presence, you really need to record a date along with it because people move all the time. The right place to capture that status is in MLS, or some private leadership spreadsheet, not the maps application. By contrast, geocoding accuracy for a given address is essentially immutable. So the designed definition of the field content on the maps site is appropriate.

RossEvans wrote:I think the more general downside is potential confusion. That confusion can arise among units, across member moves, and across changing callings, both in the minds of rank-and-file users and leaders.

Confusion about what? Anyone who moved into a different ward/stake is bound to be confused if the new ward has different "work ethic" on verification.

RossEvans wrote:Another practical downside is that by creatively adopting a higher bar before coding an address as "Verified," the clerk delays hitting the desired geocoding standard, thereby thwarting the common goal of capturing rooftop-accuracy geocoding for all member addresses. Capturing that fundamental data correctly is a prerequisite for actually using the lat/lon for many worthwhile purposes (emergency prep, boundary analysis, HT/VT planning, fast-offering routes, etc.).

That's a trade-off that needs to be considered. OTOH, if you're not sure a member lives at that address, shouldn't that be factored into your emergency plan before you expend efforts to go across a devastation zone looking for them?

RossEvans wrote:I am quite sure that if we adopted that higher bar in our huge ward, we would never achieve "Verified" status for everyone.

I don't see anyone saying that this is something all wards should follow. It's simply what that ward finds best for their needs. And I'm sure that will depend on the ward's past experience with move-ins -whether they normally be accurate or highly suspect.

RossEvans wrote:One purpose of the mapping tool is to build a churchwide asset, useful across wards, stakes and areas, by capturing standardized data in a central database. That asset is devalued when local units make up their own rules for the content. This is not a free-form field, by design. The developers built a handful of discrete values that can be chosen in the user interface. Discrete, required values are supposed to have defined meanings. (Even in unstructured text fields, I also object to writing comments into fields labeled phone or street address just because a user invents some short cut. That's Database Management 101, Application Design 101 and should be Clerk Training 101, too.)

Now we come down to the heart of it. If someone sees this as a "churchwide asset", then someone above needs to make the call in how it's used and how much effort is put into it. I'm sure there are some stake/wards that have put ZERO effort into it. Others, have worked very hard on it. I fail to see how dobrichelovek's use has moved any centralized usefulness outside of those two not uncommon extremes.

If he were to use "verified" to record HT/VT visits, then I'd agree with you.

RossEvans wrote:Also, if some units creatively define "Verified" to mean that the member is confirmed to live at the address, another ambiguity immediately arises: As of when?

Good point. The timeliness of that will depend on how good the HT/VT of a give ward is. And while your suggestion is a good one, that's setting the bar/workload even higher.

RussellHltn wrote:Confusion about what? Anyone who moved into a different ward/stake is bound to be confused if the new ward has different "work ethic" on verification.

Conflationg two concepts -- one about geocoding and another about ward membership status -- is inherently confusing.

One one hand, a user (member or leader) from this ward learns a different expectation: If a household is marked "Verified," that means something different than just geographically verified. It means the family is known for sure to live at this address because either they are active or have been visited. Under that system, a user would tend to think that anyone "Unverified" may just be inactive. But if the user moves to some other ward, "Verified" would mean something else.

On the other hand there may be some locations in this ward that leaders know to be geocoded correctly but are left "Unverified" because membership tracking lags.

RussellHltn wrote: OTOH, if you're not sure a member lives at that address, shouldn't that be factored into your emergency plan before you expend efforts to go across a devastation zone looking for them?

Maybe, but not at the expense of the primary meaning, which is that this address is mapped accurately.

I think you are missing a key point: By adopting this different process, a unit is less likely to get its addresses "Verified" because it takes a lot more time and work. Verification is work, but that can usually just be done online. But under this system, even a visit to the home will not result in a "Verified" status just because no one answers the door.

If emergency prep leaders are supposed to take membership and activity into account, the designers could have made that one of the private fields that are recorded for their use. But I suspect that in an emergency priesthood leaders are supposed to worry about everyone on the rolls. The primary objective should still be to get the address mapped accurately. And as I said above, if it becomes known for sure that the family does not live at this address, unmapping that family is the benign thing for the clerk to do.

For other purposes, such as boundary analysis, the address should govern whether the family comes to church, receives visitors, or not. And in our ward, we first map all members accurately so we can give priesthood holders (fast-offering teams) reliable maps to manage and assist their visits to homes in the first place. Those visits, in turn, may result in learning that the address for a family is wrong because of a move, and that information is fed back to the ward leaders for action.

RussellHltn wrote:Now we come down to the heart of it. If someone sees this as a "churchwide asset", then someone above needs to make the call in how it's used and how much effort is put into it. I'm sure there are some stake/wards that have put ZERO effort into it.

I do agree with you on that. My perception is that the uptake of the mapping tool by units is pretty low, especially in non-Utah areas where it might be the most useful at any level.

Unfortunately, I see this as another sad example of how the rollout of the application is falling short. Instead of automated geocoding, the tools that were delivered are ultimately manual. But the manual work is treated as optional. Compounding the problem, the church geocoding deliberately ignores moves within wards, resulting in some grossly wrong locations. Now it turns out that the tool is sometimes distorted to record different information than it was designed to track, and that seems okay with a lot of folks here.

The bottom line is that the data overall is less reliable and less understood, so the application lacks credibility. I continue to root for its success, but I know the geocoded data being captured is not great. So for real mapping work in our ward, I still bypass it and use my own geocoding because I know it to be more complete and more accurate. Of course, that does not do the users of maps.lds.org any good.

RossEvans wrote:Unfortunately, I see this as another sad example of how the rollout of the application is falling short. Instead of automated geocoding, the tools that were delivered are ultimately manual. But the manual work is treated as optional. Compounding the problem, the church geocoding deliberately ignores moves within wards, resulting in some grossly wrong locations. Now it turns out that the tool is sometimes distorted to record different information than it was designed to track, and that seems okay with a lot of folks here.

Accurate geocoding is expensive. There are more important things that need to be funded. Likewise, there are more important things for members for clerks to work on. I see it as a tool provided by the church for the use of the local leadership. Local leaders use (or not use) the tool according to how useful they find it. It's up to the local leaders to decide how much effort should be put into verification. I see dobrichelovek's process as an extension of support for local leaders. So far I've not seen evidence that anyone higher then a stake is using the information.

RussellHltn wrote:Accurate geocoding is expensive. There are more important things that need to be funded.

Actually, the accuracy of most geocoding in our area seems to have improved over time since the early prototype of maps.lds.org. I don't know what geocoding provider(s) the church is using, but for most addresses we are getting rooftop-level accuracy now for single-family homes. However, the system is not built to recognize that, even though decent geocoders typically report that precision status on the back end. Clerks are still obliged to manually verify each address.

RussellHltn wrote:It's up to the local leaders to decide how much effort should be put into verification.

I understand that. In practice, I think that means stakes need to mandate the use of the process and train clerks accordingly. If and when they do, I hope they train the clerks to a consistent standard that does not conflate geocoding with membership tracking.

Since the church still does not yet provide stakes with software tools that could profitably employ the captured geocoded data for boundary analysis, there is less incentive for stake leaders to get behind the program. If they acquire such tools themselves and are under the gun to do some boundary work, they may find they are too late. The time for rolling out the process to ward clerks needs some lead time to implement. When that time comes, the more expedient course may be just to geocode all the addresses externally.

erinbourgeous wrote:Thanks for your feedback, this is on our list of to-do items.

Hi Erin - our ward also used this feature of filtering and would like to make the request of putting it back on the list.

Thank you.

So, (Probably directed to Erin, since you have been so kind to reply to our messages, thanks!)

Is there any way we can access the old version of maps until this feature (filtering) is re-implemented? Part of what we were doing can be done by exporting the data, but not all. Since you cannot give a committed date as to when this will be completed, it would be great if we could get to the existing capability in the form of the old version until it works in the new version.

Thanks!

dobrichelovek wrote:Is there any way we can access the old version of maps until this feature (filtering) is re-implemented?

The old version of Maps is still available at http://lds.org/maps. But I understand that quite soon that URL will be changed to point to the new Maps feature (currently available at http://lds.org/rcmaps). So that's not much of a long-term solution.

I also would like the Filters to return, and add some user define. So we can add so sub field for EP side. like Ward Geo Code. Equipment, Single Sister, and so on.
I this case. more is better.

I appreciate you being so persistent on getting this filter back dobrichelovek. I'm also very interested in these options and hope they'll be implemented soon.

So this seems to be an exercise in both patience and tenacity.

There is a basic principle in product development that you generally don't regress product functionality that you intend to be part of the product. If the new version of a product has a feature gap, you continue to allow for access to the previous product so that users that found utility in that feature can continue to utilize it until the new version of the product supports it.

I was hoping that the beta/feedback process was there to get the feedback about the new product and what things might not be working correctly or be missing altogether, which is why I immediately provided the feedback about the filters as soon as the beta started. I appreciate all the amazing work that has been put into the map program and other tools, but at the same time, I struggle to understand how long the filter feature for the maps can be hoped for, but not seen.

Again, Erin has been kind enough to respond here that filtering on the status of the household location is a feature that is 'on the list' but I don't feel like I should have to resort to being loud to emphasize the utility of this feature. Now that it's been a good long time, I hope it is only appropriate that I ask again, is this feature still planned and is there any further status update? I still feel the same way as I did when I first wrote the feedback during the Beta, and I have seen more than one voice join in my expression of interest for this feature (with a few additional suggestions).

Any update?

Just checked and I see that Verified and Unverified filters are there again. Not sure how long they have been back, I've been focused on other things lately, but I am certainly glad to see that they have returned.