Unmapped Locations
-
- New Member
- Posts: 16
- Joined: Wed Oct 12, 2011 1:50 pm
- Location: Canada
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
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
- aebrown
- Community Administrator
- Posts: 15153
- Joined: Tue Nov 27, 2007 8:48 pm
- Location: Draper, Utah
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.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
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.
Questions that can benefit the larger community should be asked in a public forum, not a private message.
-
- Member
- Posts: 286
- Joined: Thu Jan 24, 2008 9:36 am
- Location: Battle Creek, MI
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: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 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).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.
- aebrown
- Community Administrator
- Posts: 15153
- Joined: Tue Nov 27, 2007 8:48 pm
- Location: Draper, Utah
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.
Questions that can benefit the larger community should be asked in a public forum, not a private message.
-
- Senior Member
- Posts: 2649
- Joined: Sun May 09, 2010 9:16 pm
- Location: Washington, USA
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.
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.
-
- Community Administrator
- Posts: 34499
- Joined: Sat Jan 20, 2007 2:53 pm
- Location: U.S.
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.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.
So we can better help you, please edit your Profile to include your general location.
So we can better help you, please edit your Profile to include your general location.
-
- Member
- Posts: 286
- Joined: Thu Jan 24, 2008 9:36 am
- Location: Battle Creek, MI
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.
-
- Senior Member
- Posts: 2649
- Joined: Sun May 09, 2010 9:16 pm
- Location: Washington, USA
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.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.
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.
-
- Senior Member
- Posts: 2649
- Joined: Sun May 09, 2010 9:16 pm
- Location: Washington, USA
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.
-
- Community Moderators
- Posts: 1184
- Joined: Sun Oct 21, 2007 6:04 am
- Location: Utah, united states
Welcome to the forum. I hope we are helping to figure out this problem, but we probably need additional input from you.bspittle wrote:wondering if there is any particular reason why BING Maps does not recognize most of our addresses (1382 are Unamapped)....
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?bspittle wrote:Approximately Verified 12 Member Verified 2 Unmapped 1382 Unverified 720 Verified 42 Grand Total 2158
- "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.
- "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?
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....