Alan_Brown wrote: I do work at the stake level, and I have been involved in boundary realignment. I can't imagine how a GIS program would be able to generate the details needed.
Using external GIS software for this purpose is really is quite doable, at least as accurate and much more flexible than using the fixed codes keyed into MLS.
A decent GIS program is basically a relational database married to geographic objects. So to use it for this purpose, the boundaries of all the small geographic areas are defined within the GIS application intead of being hard-keyed into MLS. Then all the metrics for the members and households -- for example, priesthood holders with current temple recommends, or youth, etc. -- are computed easily from the Membership.csv file that is imported into the GIS package.
This enables much more flexibility for the analyst in choosing the small geographic areas. If one set of what-if jigsaw pieces are not a useful fit, try another set of jigsaw pieces. The ward clerks do not have to be involved or even informed. Like the manual process contemplated for "GEO Code" areas, it is up to the local units to select areas that are useful as local policy. But unlike the manual process, this can be readily changed without new data entry.
In our stake, although no one has told me so, it is readily apparent that the stake clerks are using Census tracts or block groups as their jigsaw pieces, which are handy because Census has done the work to create bounded areas that make sense on the ground. (I am using the same public-domain map data within the ward for similar purposes: defining fast-offering districts by using GIS software to gerrymander them from smaller areas. For example, my ward boundaries span 159 Census block groups or about 100 Census tracts, the next larger unit. That would not work in the dense Wasatch Front, where a Census tract might be more than one stake! Smaller jigsaw pieces would have to be used. But those areas would just need to be defined in a GIS file.)
The weak link in this from the stake perspective has got to be the errors inherent in the sloppy addresses harvested from ward MLS systems, and no address validation, which you have seen me rail about in this forum. So when the stake does batch geocoding of the addresses, it has to live with a significant error rate. However, the manual process likely has its own error rate. I know ours did in my previous stake, which relied on ward clerks to populate the GEO Code field manually in the old MIS system. For the aggregate metrics the stake is generating by either method, I assume that some level of error is acceptable
Hopefully, these underlying accuracy probems with geocoding will be resolved sooner rather than later, when the Church rolls out its new process to get each household in the Church geocoded and the coordinates stored in the member records.