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.]
