GEO Codes and Boundary Realignment

[russellhltn]

I haven't done it myself, but here's my take on it based on past conversations:

1) Start off with a map. Use color coding to denote the important factors used in boundary decisions (leadership, etc.)

In drawing the boundaries consider the following:
- School districts. This minimizes the confusion for seminary students.
- Draw boundaries on "barriers" such as mountains, rivers, major highways.
- Avoid drawing boundaries on small roads where you divide neighbors from across the street. Instead, draw the boundaries across the back yard fences. This helps in HT/VT and emergencies.

2) Use the stake geocode to do "trial runs" of proposed divisions to see how the proposed wards will appear.

3) Use the stake geocodes to create lists to hand down to the wards to update their geocodes and do the boundary-realignment mass move-out.

You can find more information in the wiki

[RossEvans]

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

My own guess, never having performed your calling, is that if your primary purpose is designing stake geocodes for future boundary analysis, then you should control that at the stake level rather than relying on ward clerks. You should determine what makes sense across the stake with some rough uniformity. Ultimately, remember that you are making small jigsaw pieces that can be readily recombined to form larger units (possible wards).

In addition to the common-sense advice from RussellHltn --especially respecting school districts -- I suggest you look for other sources of maps, on paper or online, where professionals have done the work to define areas that make sense on the ground. Census Bureau tracts, block groups and blocks are useful in many areas of the United States because they are designed to be roughly on the same scale for general population.

A key variable defining such maps' utility will be the density of LDS population relative to total population. Thus, in my ward in Texas covering about 160 square miles of urban/suburban geography, there are more than 100 such Census-defined areas, which are ideal jigsaw pieces for my stake to use. But that would not help much in Orem UT, where a typical ward might be just a few blocks. I'll bet the LDS density in Oregon is somewhere in between.

[atticusewig]

Another good source of up to date maps can
be your county's appraisal district's website.
Whenever there is an address that google maps
cannot locate, I can almost always find on their
website. Their data is always much more current.

And with many offering pdf maps, you can always
just print off maps, buy some string and push pins,
and realign boundries like they did prior to all these
new-fangled computing machines.

- Atticus Ewig

[lajackson]

. . . if your primary purpose is designing stake geocodes for future boundary analysis, then you should control that at the stake level rather than relying on ward clerks.

. . . in my ward in Texas covering about 160 square miles of urban/suburban geography, . . .

Geocodes are very flexible. That is why one of our branches, covering 1700 square miles, has a simple two-letter geocode.

But boomerbubba's comment about the stake controlling geocodes is important. There are times when you may wish to ask the wards to use a standard code, at least for the first few letters of the geocode, but if you wish to keep confidential the fact that you are preparing a unit division, keeping everything at the stake level is the way to go.

[RossEvans]

For those who are interested in exploring the Census basemap data (called TIGER files), Census has recently completed a pretty thorough pass updating and correcting its files. The results, in an industry-standard format called shapefiles, are available from Census in a release called TIGER 2008. These files are significantly more accurate than their predecessors from just a few years ago.

If you just want to browse Census maps visually online, try the American Factfinder web interface. I don't think it uses the updated TIGER 2008 files -- it uses Census 2000 data -- but for purposes of visualizing boundaries of Census tracts and blocks online this interface is adequate.

If you want to do anything very intelligent with these files, you are best off owning a GIS program. (Most GIS software is expensive. I use a moderately priced commercial product called Manifold.) In general, GIS has a pretty big learning curve.

There are some less-complete solutions that are free or nearly so. One promising GIS system that is open-source and free is MapWindow. The desktop application is not as good as my commercial software. (For example, it lacks an integrated SQL engine like Manifold's, which has spoiled me.) But MapWindow offers basic functionality not only for viewing shapefiles, but also editing them. Its guts are in ActiveX, which also exposes a rich set of geographic functions for programmers to build their own custom applications under Windows.

There also are various tools for converting shapefiles into KML, the open format that Google has popularized with its map viewers in Google Earth and Google Maps. Here is a reviewand links to some of those third-party conversion tools.

[jwtaber]

My own guess, never having performed your calling, is that if your primary purpose is designing stake geocodes for future boundary analysis, then you should control that at the stake level rather than relying on ward clerks. You should determine what makes sense across the stake with some rough uniformity. Ultimately, remember that you are making small jigsaw pieces that can be readily recombined to form larger units (possible wards).

And you need to be flexible so that when it comes time to actually look at boundary changes, you can adjust your building blocks as needed. (Unless you want to maintain a system with 10,000 such blocks at the stake level.) And you will have to adjust them for one reason or another. Also, maintain in your shapefile's attribute tables (I know, big words) all the things that really matter, like school district, county, current unit, proposed unit, or range/township/section. That way, when you do make changes to your system (I do at least a few times a year) you don't have to guess about those things in the process.

One last thing: census blockgroup, tract, and designated place layers may provide lines (like streams, or municipal and other government boundaries) that might be useful as unit boundaries, that you might not see in other sources.

[jbh001]

I assume that the ward clerks can just enter a ward geocode, which then will automatically populate the stake field.

This needs some testing to verify the function. At the ward level of MLS I can edit both the Ward GEO Code and the Stake GEO Code. Only the Stake GEO Code appears to get transmitted. This might mean that they are independent of each other. That is, the stake can have its own set of GEO codes for modeling purposes, and the Ward can maintain an independent set for other purposes, such as emergency preparedness plans, HT/VT routes/districts, multiple elders quorums, etc.

Having not used MLS at the stake level, I don't really know what editing ability a stake may have over these codes, nor whether changes made at the stake level get pushed down to the ward level or not.

[jbh001]

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.

The codes that work the best are going to vary from stake to stake. Along the Wasatch Front a stake might comprise less than 1 square mile. My current ward comprises 1.5 counties. The geo codes that work best are going to be very different for these repsective units.

I came up with a hybrid based on USPS ZIP code and carrier route, and squeezed it into the 8-digits allowed by MLS (e.g. 74464C01, 74464C02, 74464R01, etc., for carrier route C001, C002, and rural route R001, respectively). I ended up using the entire 5-digit ZIP code because our stake crosses state lines. That system probably would not work well in a stake that is all within 1 or 2 USPS carrier routes.

[danpass]

This needs some testing to verify the function. At the ward level of MLS I can edit both the Ward GEO Code and the Stake GEO Code. Only the Stake GEO Code appears to get transmitted. This might mean that they are independent of each other. That is, the stake can have its own set of GEO codes for modeling purposes, and the Ward can maintain an independent set for other purposes, such as emergency preparedness plans, HT/VT routes/districts, multiple elders quorums, etc.

Having not used MLS at the stake level, I don't really know what editing ability a stake may have over these codes, nor whether changes made at the stake level get pushed down to the ward level or not.

In this post in another thread, lajackson provided a very thorough description of ward and stake geo code value propagation (or lack thereof) between ward and stake MLS. His empirical observations seemed accurate at the time. I don't have convenient access to MLS help at the moment, but hopefully this information is presented there.

[lajackson]

In this post in another thread, lajackson provided a very thorough description of ward and stake geo code value propagation (or lack thereof) between ward and stake MLS. His empirical observations seemed accurate at the time. I don't have convenient access to MLS help at the moment, but hopefully this information is presented there.

Last I checked, it still worked that way.