Map location of members

[donaldranderson]

Dear Bretheren
I am the Stake clerk in charge of Technology a problem has been put in my lap. I have been asked to find a way to show our membership on a map. to assist our leaders. One thing that is on everyones mind is saving gas. by trying to assign home and visiting teachers closer to each other. There are others as well. Any suggestions would help.

[opee]

Dear Bretheren
I am the Stake clerk in charge of Technology a problem has been put in my lap. I have been asked to find a way to show our membership on a map. to assist our leaders. One thing that is on everyones mind is saving gas. by trying to assign home and visiting teachers closer to each other. There are others as well. Any suggestions would help.

Welcome to the Forum Don. You can run a search for items in the forum from the "Search" link. When I put in "member map location", it came up with these 5 discussion threads. This has been a popular topic, so you can see some of the many ideas that are out there to help you with your assignment.

http://tech.lds.org/forum/showthread.php?t=179
http://tech.lds.org/forum/showthread.php?t=141
http://tech.lds.org/forum/showthread.php?t=37
http://tech.lds.org/forum/showthread.php?t=310
http://tech.lds.org/forum/showthread.php?t=297

Hope this helps.

[RossEvans]

Here is a deep link to my post in one of the aforementioned threads, with a recent release of scripts for geocoding and mapping from ward MLS extracts, using Google Earth as the display medium. The scripts support mapping of a general ward roster, as well as home- and visiting-teaching assignments.

http://tech.lds.org/forum/showpost.php? ... stcount=67

What my scripts -- as well as several other solutions referenced upthread -- do is to geocode addresses and render a simple display via one of the Internet-based mapping engines..

At the stake level, where the leaders presumably have more sophisticated requirements associated with gerrymandering ward boundaries, I suggest that you investigate commercial GIS software. Unfortunately, it tends to be expensive, but there are viable low-cost options. (I recommend Manifold for a lot of bang for the buck. I am using a personal copy of it now to design fast-offering districts, which is a task similar to designiing ward boundaries but much simpler.) GIS software does have a bit of a learning curve.

[jay.askren]

I created an application that does this for our ward's emergency preparedness plan. It's not geared towards home teaching, but it might be helpful. It will only handle one ward at a time. Just export your membership data from MLS and import the file into ERDB:
http://jay.askren.net/emergency/


Jay

[kmmoss-p40]

I am a Stake Clerk in the Chicago Area. We export the addresses from MLS and run them through a GEO Coding program, which adds fields for Lattitude and Longitude to the spreadsheet. I then use the $30 version of Google Map to import the data and present for our stake leaders. You can do a virtual flyover of the stake, mouse over for more details about the member, color code by unit, superimpose other data, etc. It only requires minimal technical skill. kmmoss@wideopenwest.com if you requre further detail. Good luck.

Dear Bretheren
I am the Stake clerk in charge of Technology a problem has been put in my lap. I have been asked to find a way to show our membership on a map. to assist our leaders. One thing that is on everyones mind is saving gas. by trying to assign home and visiting teachers closer to each other. There are others as well. Any suggestions would help.

[RossEvans]

I then use the $30 version of Google Map to import the data and present for our stake.

Google Map?

Do you mean Google Earth Plus, the $20/year version of the application, or Google Maps, the free web site?

[RossEvans]

The post above by kmmoss motivated me to use Google Earth Plus (which I assume is what he used) to batch-geocode our ward roster, and compare the results with those of our own geocoding process. The primary findings are these:

This general method of geocoding a batch blind, without intermediate warnings and human intervention to deal with the errors, was proved to be inherently flawed. (That is the biggest difference between kmmoss' method and our own, which does involve the clerks to resolve errors identified by an initial pass of automatic geocoding, before the map is plotted.)

I took the 549 addresses in our ward -- all of which have been geocoded satisfactorily -- and submitted them to a "quick and easy method" in Google Earth Plus such as kmmoss describes. Of course, I had to break that into six batches of 100 or less and recombine them when finished. The 549 excludes about 12 families for which we have no address at all, and one family whose recorded address is known to be non-existent.

Of those 549 addresses, Google Earth Plus failed to geocode 49 of them, which errors Google Earth reported at runtime.

In addition to these errors of omission, there were several obvious errors of commission: In at least 9 cases obvious to a quick visual inspection, Google Earth guessed wrong in translating the street addresses, and plotted the points very far, even miles away, from their actual location. (Those are just the most obvious errors plotted outside our ward boundaries. I did not scientifically test all the points.)

Google Earth does not report any warnings about such guesses during batch processing; it just applies its best guess to resolve ambiguities and plots the points. Probably, most often, that guess is correct, but sometimes it is very wrong. The same problem applies to geocoders in general. If you want accuracy, there must be opportunity for humans to resolve problems guided by one or more fields reporting how precise the geocoding result was. In fact, this universe of 549 already reflects several rounds of error-correction upstream in MLS to fix other errrors flagged by our geocoding process. I would estimate that at least 40 of those addresses have already been fixed at the source that way.

I can understand how a "quick and easy method" with an error rate of more than 10 percent might be acceptable at the stake level. If the purpose is just to present a bird's eye overview of the stake it is useful. Even boundary realignments might be made on the basis of aggregations where 90 percent is considered good enough. There certainly have been realignments executed on the basis of even cruder data, such as map-grid codes, keyed into the legacy "Geo code" fields in MLS.

But if the purpose is more microcosmic, such as the work within a ward, where we really want to look at a map and be confident that "Brother and Sister Smith live here," that level of accuracy falls far short. I also suggest that in the church's forthcoming member-mapping application (on LUWS, for example), that level of of accuracy would turn rank-and-file users off. Members sophisticated enough to have used Internet mapping engines are willing to forgive small errors, I think, but not whoppers.

One other interesting finding: Of the many addressess where Google Earth did geocode the addresses close to our own geocoded points, but still a few houses away, Google Earth's results were superior to ours. Our geocoding is based on Yahoo's free geocoder as the primary engine, with other sources used as manual exception-handling. I spot-checked about 10 such cases and used the City of Austin's excellent GIS web site as a gold standard to determine the truth. Google Earth aced these situations.

In such cases, I am not comparing the overall batch methodology of kmmoss against ours, but rather the internal accuracy of the two Internet geocoding engines. And at least in our area, Google Earth has superior coverage. It is obvious from the comparisons above that in our city Google Earth is able to use parcel-level geocoding, which for typical single-family home sites is usually spot-on, while Yahoo is only able to use the more common method of interpolating street-address ranges. YMMV.

I have considered capturing these results and folding them into our own geocoding process, to take advantage of Google Earth's superior accuracy in such cases. But unfortunately, since the application provides no fields denoting the precision its geocoding achieved -- when it guessed at street names, when it used parcels, when fell back to zip centroids, etc. -- I have no reliable way to separate the wheat from the chaff.

[p.s. I just realized, after reading the Google Earth Plus license closely, that it may be a license violation to use the product as a batch geocoder and export the lat/lon coordinates. So even though that is a trivial task technically, the legal restriction might preclude this. I think that partially explains why Google crippled the product, which is only supposed to be used for viewing points already geocoded or plotted on-the-fly from addresses. But it is too bad they don't allow their users to control the threshhold of precision in such mapped sets.]

[kshowtime-p40]

I know this is an old thread, but in case anyone is still listening, I found this web site this am.

http://www.batchgeocode.com/

good luck

[RossEvans]

I know this is an old thread, but in case anyone is still listening, I found this web site this am.

http://www.batchgeocode.com/

good luck

Anyone using batchgeocode.com should be aware of its failure to handle errors, which are almost inevitable in geocoding. See discussion in this thread.

[daddy-o-p40]

Try this instead....
http://wardmap.hpaulsen.com/wiki/Main_Page