Unmapped Locations

I'm working on a project for my Stake that would benefit from the LDS Maps tool. I was shocked to see the current status of our 2158 households and wondering if there is any particular reason why BING Maps does not recognize most of our addresses (1382 are Unamapped). We are located in BC, Canada, and usually BING is pretty good.

Approximately Verified 12 Member Verified 2 Unmapped 1382 Unverified 720 Verified 42 Grand Total 2158
I downloaded all the data using the Green Down Arrow key and I did notice that is nearly every case (any category above), the CITY, PROVINCE and POSTAL CODE were all in the FIELD = ADDRESS-2

bspittle wrote:I'm working on a project for my Stake that would benefit from the LDS Maps tool. I was shocked to see the current status of our 2158 households and wondering if there is any particular reason why BING Maps does not recognize most of our addresses (1382 are Unamapped). We are located in BC, Canada, and usually BING is pretty good.

Approximately Verified 12 Member Verified 2 Unmapped 1382 Unverified 720 Verified 42 Grand Total 2158
I downloaded all the data using the Green Down Arrow key and I did notice that is nearly every case (any category above), the CITY, PROVINCE and POSTAL CODE were all in the FIELD = ADDRESS-2

I think your detective work yields the clue -- cramming all that data into the address-2 field is probably the reason. I don't know how the data is passed to Bing's geocoder, but it certainly makes sense that passing nothing to the city, province, and postal codes but expecting all that data to be parsed out of the address-2 field could cause some problems.

It's a bit surprising that the problem would be so widespread. I can understand if a ward clerk or two entered addresses incorrectly, but it appears that a majority of your wards have entered city/province/postal code into the address-2 field. There are several good reasons to make sure the addresses are done correctly; proper interaction with LDS Maps is only one. Custom reports, setting of Geo Codes in MLS, and other benefits will also come from proper use of the address fields. It's a big job to fix it, but ward clerks can gradually work on this over time.

aebrown wrote:I think your detective work yields the clue -- cramming all that data into the address-2 field is probably the reason. I don't know how the data is passed to Bing's geocoder, but it certainly makes sense that passing nothing to the city, province, and postal codes but expecting all that data to be parsed out of the address-2 field could cause some problems.

I don't think it's trying to parse the data out of the address-2 field. More likely it's being parsed INTO the address-2 field (if "parsed" is the right term for that). All of my addresses have the same info "crammed" in the address-2 field (except State instead of Province).

aebrown wrote:It's a bit surprising that the problem would be so widespread. I can understand if a ward clerk or two entered addresses incorrectly, but it appears that a majority of your wards have entered city/province/postal code into the address-2 field. There are several good reasons to make sure the addresses are done correctly; proper interaction with LDS Maps is only one. Custom reports, setting of Geo Codes in MLS, and other benefits will also come from proper use of the address fields. It's a big job to fix it, but ward clerks can gradually work on this over time.

I agree that addresses should be formatted correctly, but the auto-mapping of unverified addresses really has nothing to do with what is currently in MLS (they're not linked) and has everything to do with what the address was when the records were first moved into the unit. If an address was messed up and therefore not able to be mapped when the record was first moved in, it will continue to be unmapped even if it is corrected in MLS. The only way to correct the mapping is to manually verify the location in every case (and be prepared to do it again when someone moves within the unit).

greggo wrote:I don't think it's trying to parse the data out of the address-2 field. More likely it's being parsed INTO the address-2 field (if "parsed" is the right term for that). All of my addresses have the same info "crammed" in the address-2 field (except State instead of Province).

I see what's going on now. The reference to address-2 field was talking not about the original MLS data, but the exported data from the Maps site. But we have no way of knowing what data is actually being geocoded. It's possible that the data is nicely compartmentalized when it comes from MLS to Maps, and it's even possible that it is still compartmentalized when it is sent to the geocoder. The fact that the fields are crammed together when the Maps site prepares a download file really doesn't tell us anything about what is sent to the geocoder.

So in my previous post I was making an incorrect assumption. But I don't know how to tell what is actually sent to the geocoder.

It is possible that the clerks in your wards are not correcting addresses. Most of the records that get moved into my ward show the city/State/Zip all in the address 2 field and MLS offers to update them to the new format. If the clerk doesn't automatically (through MLS' suggestion) or manually do that, it could explain some of your problems.

I have never ignored this suggestion so have no idea what happens if one were to go some months or longer without cleaning that "urgent" task in MLS.

davesudweeks wrote:It is possible that the clerks in your wards are not correcting addresses. Most of the records that get moved into my ward show the city/State/Zip all in the address 2 field and MLS offers to update them to the new format.

Just out of curiosity, are the moving in from "out of area"? Or perhaps they're being "sent" as opposed to "requested". MLS deals with many different address formats. It uses a template sent by the area office. But to support world-wide addresses, there's probably a "unformatted" verizon being used for some transfers.

Someone please correct me if I'm wrong, but my experience is that the locations on the map are unrelated to the addresses in MLS (unless you are talking about the addresses you put in when requesting new move-ins). The locations always stay the same (or remain non-existent) as they were when the records first arrived in the unit (unless they are manually verified). No matter how many times you change or correct addresses in MLS, the locations on the map are unaffected.

RussellHltn wrote:Just out of curiosity, are the moving in from "out of area"? Or perhaps they're being "sent" as opposed to "requested". MLS deals with many different address formats. It uses a template sent by the area office. But to support world-wide addresses, there's probably a "unformatted" verizon being used for some transfers.

The behavior I see is always when a record is "pushed" into our ward. If I recall correctly, it is normally when records are sent from another unit, not from the "Address Unknown" file.

Probably 20%-30% of the move-in's have addresses with the City/State/Zip loaded on the 2nd address line as opposed to the proper locations on the address mask.

greggo wrote:Someone please correct me if I'm wrong, but my experience is that the locations on the map are unrelated to the addresses in MLS (unless you are talking about the addresses you put in when requesting new move-ins). The locations always stay the same (or remain non-existent) as they were when the records first arrived in the unit (unless they are manually verified). No matter how many times you change or correct addresses in MLS, the locations on the map are unaffected.

This is the behavior I see as well. My comments concern how the address is formatted in MLS, but that could affect how accurate it will show on the map when MLS transmits. I have never seen a household move within my ward on the map when the member's address changes within the ward boundaries - I have to always move the pin manually.

bspittle wrote:wondering if there is any particular reason why BING Maps does not recognize most of our addresses (1382 are Unamapped)....

Welcome to the forum. I hope we are helping to figure out this problem, but we probably need additional input from you.

bspittle wrote:Approximately Verified 12 Member Verified 2 Unmapped 1382 Unverified 720 Verified 42 Grand Total 2158

To make sure we all are on the same page, I've broken down your listing to identify the problem areas. Am I correct in assuming the following?

• "Approximately verified 12," and "Verified 42" means a ward clerk "verified" those household placements, 12 of which he could only place "approximately."
• "Member Verified 2" means a member confirmed his/her own household placement within the "mapping" tool. Once their ward clerk confirms this placement, they will change to become "Verified" as listed above.
• "Unverified 720" are those households waiting for their ward clerks to log-in and "verify," or confirm they are placed correctly, or waiting for a member to correct his own marker, and then have it "verified" by a ward clerk. These are as close as "maps" can get automatically, and now they wait for a manual verification on a local level. Obviously, this is a training issue, perhaps from stake to ward, to educate each ward clerk on this new "maps" tool, and ask each one to perform this task. "Verification" remains a leader function in the hands of the ward clerks.

Up to this point, the "mapping" tool is working as expected...although it is waiting on some tasks that still need to be done by local ward/branch leaders.

• "unmapped 1382" These are the ones at issue, as you suggest. Why cannot the system map these? A ward clerk cannot verify these, either. When you compare stake MLS address data, on-screen, not from your download, what does your MLS addresses show for these names that may be different from the MLS addresses for those that are verified, or even unverified, but mapped? Are there differences in MLS address data form the data listed in MAPS for the same household?

The problem could be local, within your MLS, or at the Church, with data transferring or MAPS itself, or somehow involve BING, as you suggest. Others here are much more observant and smart than I, but I think I would:

1) make sure MLS is correct first, making sure your addresses are formatted correctly, with data in the correct fields for those housholds that show as "unmapped."
2) start comparing data across the three church systems for the same household that cannot be mapped: Are MLS addresses and the directory and MAPS addresses for the same household the same, or is data being scrambled at some point in the interchange? Call it up "on screen" to check, as your "data download" could also be changing things....
3) Start comparing those addresses that are mapped correctly in Maps, to those addresses that remain "unmapped," and try to begin finding clues to the differences.
4) Then I'll consider contacting the "help" from within maps with the info I've discovered above....

greggo wrote:Someone please correct me if I'm wrong, but my experience is that the locations on the map are unrelated to the addresses in MLS...No matter how many times you change or correct addresses in MLS, the locations on the map are unaffected.

kisaac wrote: 1) make sure MLS is correct first,

I believe it is true that your location marker in MAPS is "somewhat" independent to the addresses in MLS...You can't change an address in MLS by dragging the MAPS marker across town, nor will changing MLS correct or move the marker.

For the purpose of the original poster, though, debugging problems with MAPS, you can't overlook that if the data is not correct at the source, it won't ever be correct "downline." Where does it become incorrect?

For those new to MLS, Maps, etc, I guess we should establish for clarity that the "Source" of address data resides on our "official" membership record, housed at Church HQ, with a "local copy" held in our wards on our local MLS.

Our Ward Clerk must make any changes in this address data on our "official" membership record through an upadte in our local MLS, which then transfers to church HQ when a send and receive is initiated, and your "official" membership record is then updated with new address data. See the wiki for more on this process...

So, thinking of it that way, Your ward MLS, Stake MLS, the lds.org Directory, and LDS Maps all get "fed" their information from one source, your membership record at church Headquarters. Start there to look for address problems...if it is correct there, trace the flow of data through the other tools and check each "downstream" component (like the directory, or MAPS,) for accuracy. If they are all accurate, the problem is elsewhere.

Based on what davesudweeks has said, I think this is what's happening:

When a member is "pushed" to your ward, the address is formatted thus:

Address1: 50 E. North Temple St.
Address2: Salt Lake City, UT 84150

Only after it arrives in the ward is it reformatted to:

Address1: 50 E. North Temple St.
Address2:
City: Salt Lake City
State: UT
Zip: 84150

But since this is a change within the ward, this new update isn't being sent to the geocoder. If for any reason, the geocoder doesn't like the first format (perhaps because it's been sent blank City/State/Zip fields so it doesn't know to look at "Address2" for that information) then it can't map the location.

But when one "pulls" a record, the address is entered in the final format up front and the geocoder is happy.

What would a "unit data refresh" show? I'm a little afraid to do one....

https://tech.lds.org/wiki/Unit_data_refresh
This a great tool for troubleshooting any issues that may arise when membership records are moved to or from the unit. The local priesthood leader may contact the administrative office to request information on the different records to determine if the refresh is needed.

First off. My apologies for not seeing all the responses. I am not being notified of any responses (I'll have to check the settings). I have confirmed the following:
1. The address data as it appears in MLS is showing up correctly (i.e. the data is in the correct fields and not combined in any way).
2. We have yet to find any incorrect data so far and are stumped as to why most of the addresses in our entire Stake are "unmapped" (65%)

I called Global services and they said to post here to ask the developers for help in "refreshing" out data. They were not able to determine what the issue is or to connect me with anyone familiar with this area.

Actually, when the data arrives in the Ward it is formatted correctly. No reformatting is needed.

bspittle wrote:First off. My apologies for not seeing all the responses. I am not being notified of any responses (I'll have to check the settings).

At the top of each thread is a dropdown labeled "Thread Tools"; an option under that is "Subscribe to this Thread." Choosing that will insure that you are notified (assuming your correct email address is in your forum profile) when anyone posts to the thread.

bspittle wrote:I called Global services and they said to post here to ask the developers for help in "refreshing" out data. They were not able to determine what the issue is or to connect me with anyone familiar with this area.

There's no guarantee that anyone on the development team will see this post (but they might). This is primarily a community forum, but some developers occasionally visit here.

To answer your question on "unmapped 1382":

1. the MLS data is correct and each address component shows up in the corect field.

2. in the online data available through lds.org, the address shows up as follows in two rows below the name (either in the Leader Tools --> "maps" or in the standard "Directory"):
3534 Landie Rd
Kelowna, British Columbia V1W 3E9

3. When I "download" the Stake or Ward data (csv file) from the Mapping application, it shows up as follows, except where I deleted private information:

Longitude unknown
Latitude unknown
Household [hidden for privacy purposes but was accurate}
Street 3534 Landie Rd
City Kelowna
State British Columbia
Zip V1W 3E9
Phone [hidden for privacy purposes but was accurate}
E-mail [hidden for privacy purposes but was accurate}
Location Status Unmapped

I just wanted to say that I'm very happy that someone has identified a method of getting the map function of lds.org to geocode members addresses at times other than when a record is moved into the unit. bspittle should now be able to get addresses mapped that were previously unmapped without having to manually move and verify the markers.

It was discovered last week in a separate post, but I have not been able to find it to provide a link. A member of the bishopric or clerk can use their tools on lds.org to "edit" the address of a household, and the map will then geocode and provide the marker. I apologize for being vague in my description of the process. I am the EQ Pres and don't have access to the clerk tools on lds.org. But I verified with my branch pres that it works. There is no need to actually make any changes to addresses - just choose edit and save without changes. Maybe someone else can provide more details on the method I've described.

I will be instructing our branch clerk to use this method to map those who are currently not shown or mis-mapped and repeat every time someone moves within the branch.

greggo wrote:It was discovered last week in a separate post, but I have not been able to find it to provide a link. A member of the bishopric or clerk can use their tools on lds.org to "edit" the address of a household, and the map will then geocode and provide the marker.

You're most likely referring to this post:

martyriker wrote:I found that if I edited their membership record from the lds.org log in (as the bishop, I can do this) and didn't change anything, that their geocode was updated and their dot moved to their new address. Automagically.

If that method works, then my next obvious question is if there is some way of automatically refreshing the data for the entire Stake, rather than having to open up each record. I'm not going to be much support to having the ward clerks go through and do this in all 11 units.....

bspittle wrote:If that method works, then my next obvious question is if there is some way of automatically refreshing the data for the entire Stake, rather than having to open up each record. I'm not going to be much support to having the ward clerks go through and do this in all 11 units.....

That would only make sense if relatively few addresses were verified, since that would have the effect of unverifying all locations, correct or not. In my stake, what you propose would be a disaster, since over 90% of the addresses are accurately verified. This process would only need to be followed for members that moved into the ward since their address was last verified. I realize that some stakes are highly transient, but resetting the verified locations seems like a very drastic approach.

aebrown wrote:That would only make sense if relatively few addresses were verified, since that would have the effect of unverifying all locations, correct or not. In my stake, what you propose would be a disaster, since over 90% of the addresses are accurately verified. This process would only need to be followed for members that moved into the ward since their address was last verified. I realize that some stakes are highly transient, but resetting the verified locations seems like a very drastic approach.

Not likely drastic in our case because the data is generally not mapping. This is a breakdown from a year ago:

Verified 12
Member Verified 2
Unmapped 1382
Unverified 720
Verified 42
Total 2158

They key for me is finding out why 64% of all addresses in the Stake showed up as UNMAPPED. This suggests a problem with the Mapping program since my random samples of actual MLS address data are fine.

I'm noticing similar ratios of unmapped to maped addresses in my local unit in another stake in BC. It's very frustrating. Does anyone have a solution that doesn't require nagging the clerk to take on the somewhat large task of manually resetting every member's address in the unit? By the way I would happily do the few hundred myself sadly... or perhaps happily, I'm not appropriately privileged.

-Joshua

No. Only clerks can fix it.

I believe that members can verify their own household location. Perhaps a ward/stake wide initiative to have each member household set/verify their own household location would reduce the workload on ward clerks.

rontilby wrote:I believe that members can verify their own household location.

My understanding is that yes, a member can, until a clerk touches it. After that, the member can no longer change it.

This is true if a member moves within the ward, and from what I have read, in many cases this is also true if the member moves to another ward. Once a clerk touches it, the member is out of the picture. I understand this to be a bug, but I believe that is the way it works, at least for now.

What lajackson says is correct. A household that shows either as unmapped or unverified can be verified by the head of household or the spouse of the HoH. I am not certain, but member verification of the household location may also be accomplished by adult members of the household. I just have not been able to confirm this.

The unmapped icon displayed with the household name in the Maps directory is this icon. The unverified household location marker is this icon while the icon displayed on with the household name on the Maps directory is just the yellow triangle with the exclamation point.

When a member of a household verifies the household location, the map location marker displays the blue "member verified" icon. The icon displayed in the Maps directory for the household name is just the blue circle part of the icon.

Once the household location is verified by an administrator it can no longer be "member verified". There are two icons that indicate an administrator has verified the household location the first is the "exact location" icon . There is no icon displayed in the Maps directory of households for a location that is verified as an exact location. The other verified icon is the "approximate location" icon . The icon displayed in the Maps directory of households for an approximate location is the yellow box with the double tilde.

I am the Ward Clerk and am trying to verify a household location on the maps. I am selecting the household and then selecting edit on the pop up box. However, it is not giving me the drop down box options to verify the location. I have been able to verify locations with the other households in the ward but as of this week the pop up box won't give me the drop down boxes to verify the location. I have tried this on two different computers using IE9 and am not able to verify the households. Has a change to the maps been made recently?

rharwood wrote: I am selecting the household and then selecting edit on the pop up box.

The "Edit" link is to edit the emergency response categories. To verify a location click the "Move" link. The "Set Location" dialogue will appear at the top of the Maps households directory. Click the "Start Move" button to proceed with the move operation.

rharwood wrote:Has a change to the maps been made recently?

Yes. In testing the move procedure for this post I noticed some changes in the process and in the dialogue for moving the marker. Before, there was an option to either move the marker or to mark the location with a cross-hair cursor. Now the only option is to mark the location.