GEO Codes and Boundary Realignment

Discussions around using and interfacing with the Church MLS program.
Locked
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

GEO Codes and Boundary Realignment

#1

Post by aebrown »

boomerbubba wrote:I don't think this is the general intent, unless the stake clerks want to do a lot of data entry and maintenance. In my last stake, the stake set the policy for populating the stake "GEO Code" field, but the actual data entry was the responsibility of all the ward clerks and membership clerks. (My current stake does not populate this legacy field. Instead the stake clerks use real lat/lon geocoding for boundary work.)

Whoa! The stake GEO code fileld is by no means a "legacy field." It is absolutely critical to the process of boundary realignment. If you don't keep it updated along the way, and the need for boundary realignment comes, you'll have a ton of work to do in relatively short order. But if your stake chooses to take that risk, go right ahead.

The stake GEO code field was never intended to specify precise coordinates, but rather to group the members by neighborhoods, villages, towns, etc. It exists primarily for boundary realignment, but of course may be used for other purposes.

If you want to do precise geocoding, then it is definitely wise to use real lat/lon, and to store it somewhere other than the stake GEO code. But don't forget that the stake GEO code does have a real purpose.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#2

Post by RossEvans »

Alan_Brown wrote:Whoa! The stake GEO code fileld is by no means a "legacy field." It is absolutely critical to the process of boundary realignment. If you don't keep it updated along the way, and the need for boundary realignment comes, you'll have a ton of work to do in relatively short order. But if your stake chooses to take that risk, go right ahead.

The stake GEO code field was never intended to specify precise coordinates, but rather to group the members by neighborhoods, villages, towns, etc. It exists primarily for boundary realignment, but of course may be used for other purposes.

If you want to do precise geocoding, then it is definitely wise to use real lat/lon, and to store it somewhere other than the stake GEO code. But don't forget that the stake GEO code does have a real purpose.

I call the "GEO Code" a "legacy" field to distinguish the term from lat/lon address-based geocoding, which is what almost everyone means by "geocoding" today. I wish the two fields in MLS were named something else to avoid this confusion.

I don't work at the stake level, but my understanding is that while the "GEO Code" may be used for boundary analysis, it is not a requirement. It is a tool, a means to an end of fulfilling the requirement that stakes provide a detailed statistical breakdown on a form for proposing boundary changes. If the "GEO Code" field is populated, then MLS will generate those details. But it also is possible to generate those details from a GIS program without ever populating the "GEO Code" field. I know that is what my stake does today, although I am not involved in that process so I don't know all the details.
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

#3

Post by aebrown »

boomerbubba wrote:I call the "GEO Code" a "legacy" field to distinguish the term from lat/lon address-based geocoding, which is what almost everyone means by "geocoding" today. I wish the two fields in MLS were named something else to avoid this confusion.

I absolutely agree with you that the naming is unfortunate. I'm certain the MLS developers had no intention that the GEO Code would have anything to do with geocoding; it was simply a geographical code assigned to a group of homes in the same area. Some people have tried to cram real geocoding information into the ward and/or stake GEO codes, but that attempt is doomed to fail.
boomerbubba wrote:I don't work at the stake level, but my understanding is that while the "GEO Code" may be used for boundary analysis, it is not a requirement. It is a tool, a means to an end of fulfilling the requirement that stakes provide a detailed statistical breakdown on a form for proposing boundary changes. If the "GEO Code" field is populated, then MLS will generate those details. But it also is possible to generate those details from a GIS program without ever populating the "GEO Code" field. I know that is what my stake does today, although I am not involved in that process so I don't know all the details.

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. The whole MLS boundary realignment process depends on assigning stake GEO codes to the involved homes. Then you can create various proposals with different sets of GEO codes going to different units. For each proposal, you can see all the detailed statistics (how many priesthood holders, youth, children, women, etc. are in each proposed ward) and keep playing with those proposals until you get some that look reasonable, then discuss those with the stake presidency, get their inspired guidance, revise and repeat until it is right. Occasionally you have to subdivide a GEO code, but usually if the GEO codes were done right, that rarely happens.

Certainly it is only a tool. Sure, you can do boundary changes without MLS (we did to boundary changes in the Church before computers even existed :)), but it would be a LOT more work.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#4

Post by RossEvans »

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.
User avatar
mkmurray
Senior Member
Posts: 3266
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah
Contact:

#5

Post by mkmurray »

Perhaps this conversation should be forked from the thread...and perhaps I'm biased because I started the thread and want it to stay focused on my original question. :)
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

#6

Post by aebrown »

mkmurray wrote:Perhaps this conversation should be forked from the thread...and perhaps I'm biased because I started the thread and want it to stay focused on my original question. :)

Agreed. Done!
jwtaber
Member
Posts: 109
Joined: Wed May 30, 2007 8:01 am
Location: Elsmere, Delaware, USA

#7

Post by jwtaber »

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
When GIS software can take care of the step of plugging stake geocodes into MLS, I'll be very happy. In the meantime, that's the one thing I have to manually enter. Usually that's just the new move-ins, but once in a while I overhaul the way I have geocodes set up and I have to re-enter the whole stake. Luckily that's not too often - this time it was prompted by Delaware updating the GIS for its school districts.

As for sloppy addresses, I've been working with the wards and branches on that, more than anything else, in the six and a half years I've been an assistant stake clerk. What I've found, though, is that ultimately I have to check the data for obvious problems (e.g. missing/incorrect ZIP Code, address misstructured) before I plug it to batchgeocode.com. I can't just say, well, it's the ward clerk's fault that the address doesn't get picked up. I can point out that the address is incomplete, sloppy, or on the wrong side of the boundary. While I can't fix these problems myself, I can recognize that eventually the unit will. It just might not be that week or month.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#8

Post by RossEvans »

JTaber wrote:As for sloppy addresses, I've been working with the wards and branches on that, more than anything else, in the six and a half years I've been an assistant stake clerk. What I've found, though, is that ultimately I have to check the data for obvious problems (e.g. missing/incorrect ZIP Code, address misstructured) before I plug it to batchgeocode.com.

I think you and I are basically on the same page. I do warn anyone, however, that relying on batchgeocode.com will probably mask a significant number of errors because that site discards the detailed errors and warnings it receives from its source, the Yahoo geocoder.

Some households will just get plotted at very wrong coordinates because Yahoo guesses wrongly in parsing the addresses, and there will be nothing that tells the user so even though Yahoo's geocoder warned about it in the XML transactions upstream that Yahoo's API sent to batchgeocode.com.

I do suppose that stakes can live with such errors because they deal mostly in aggregates.
jwtaber
Member
Posts: 109
Joined: Wed May 30, 2007 8:01 am
Location: Elsmere, Delaware, USA

#9

Post by jwtaber »

boomerbubba wrote:I think you and I are basically on the same page. I do warn anyone, however, that relying on batchgeocode.com will probably mask a significant number of errors because that site discards the detailed errors and warnings it receives from its source, the Yahoo geocoder.

Some households will just get plotted at very wrong coordinates because Yahoo guesses wrongly in parsing the addresses, and there will be nothing that tells the user so even though Yahoo's geocoder warned about it in the XML transactions upstream that Yahoo's API sent to batchgeocode.com.

I do suppose that stakes can live with such errors because they deal mostly in aggregates.
Right, I'm just trying to pin each household down at a level somewhere between Census blockgroup and Census tract, depending on a few other factors. I wish batchgeocode would flag problem addresses. At least it either codes them as "0,0" or (from Yahoo) puts the point at the center of the ZIP Code's area. When I get five or six families with different addresses and the same coordinates, I know what's up. (And usually it's a matter of fixing the ZIP Code.) Normally I take another look at points that land in the wrong ward - and I don't know that they're boundary stragglers.

Families without a street address, I used to just code based on where the point landed, assuming of course it was in the right ward. Now as a matter of policy I give them all a stake geocode of "X" for no known address. (The YSA branch's version of sloppiness, for instance, is to give more than a few members the city and state where the stake center is.)
Ivan-p40
New Member
Posts: 17
Joined: Mon Jul 07, 2008 12:03 am
Location: Sweet Home, OR

Process of stake boundary proposals

#10

Post by Ivan-p40 »

After all my research on this forum and playing around, boundary proposals still seem to be a complicated process. Some things are learned by trial and error, but I would certainly like to minimize this as I work with multiple clerks in the stake. I would appreciate feedback on my statements and observations below.

I sense that it is best to have the ward clerks enter geocodes for their wards. I'm proposing that they use a two letter ward identifier followed by a dash, then an alpha-numeric identifier for their geographic areas (would be easier to sort by ward in MLS and Excel). Their geographic areas should be made based on what makes sense for their ward. I have played with hpaulsen's WardMap tool and feel that the program makes a lot of sense and is easy to use for the wards.

I assume that the ward clerks can just enter a ward geocode, which then will automatically populate the stake field. Here is where this becomes a bit unclear. The ward computers will upload their data to the stake computer. I understand that if the stake computer's stake field is empty, it will be populated by the ward data. However, if the stake computer's stake field is already populated with something, then a manual entry would need to be made for each household.

In order to consider a potential boundary change, the stake would need to obtain maps from the wards showing where their geocodes are located.

Starting with the wards' assigned geocodes, then the stake can proceed to "play" with boundaries, including adding further identifiers to the stake geocodes to breakdown the ward-set geocodes into smaller areas as needed.

Does this process, as I described, sound reasonable? Am I missing anything? All instruction and training that I've seen for geocodes and boundary proposals seems to leave a lot of voids and questions!!

The geocodes can also be used for emergency preparedness. Does anyone have experience with this?

I will appreciate feedback, thanks! :)
Locked

Return to “MLS Support, Help, and Feedback”