Geo Code Usage

We are anticipating creation of a new ward or ward(s) in the future in our Stake. As a fairly new Stake Clerk, I have not used the geo code function in MLS in the past. I have read some information on the current wiki. From what I can see, while MLS has some powerful features that utilize geo codes, most of our units are way behind in keeping them current and they all seem to have come up with their own "definition" of gride size and other parameters when it comes to geo codes. Our presidency would like to use this tool in making adjustments to current boundaries. It almost appears that we need to start from scratch with a consistent definition of the grid size for geo codes. Are there other tools (google maps, etc.) available for helping us determine future boundaries or is the geo code still the best approach? Any suggestions would be appreciated.

sgrigg wrote:It almost appears that we need to start from scratch with a consistent definition of the grid size for geo codes.

You don't need a consistent definition of grid size. You just need to divide the potentially affected wards into logical geographical groups. Some of those groups may be big; others may be small. The primary attribute of a group is that you almost certainly wouldn't put a ward boundary in the middle of it. So think of issues like major streets, school districts, geographical features like rivers or ridges, or natural neighborhood boundaries. Then assign a stake geo code to each group.

sgrigg wrote:Are there other tools (google maps, etc.) available for helping us determine future boundaries or is the geo code still the best approach?

The advantage of using geo codes in MLS is that you can use the boundary realignment features of Stake MLS to create various scenarios. You can say that a proposed ward contains areas 1, 4, and 6, and another ward is 2, 3, and 5, and then MLS will show how many men, women, youth, children, priesthood holders, etc. are in each proposed unit.

You may well want to use Google Maps or some other tool to help you visualize the boundaries. In particular, using LDS Maps will put a marker on each household in the stake, which can be very helpful as you then create the groups and need to assign households to each group. There are a couple of people on this forum who advocate using GIS software for this purpose, but if you're not already comfortable with that, I'd strongly advise you to stick with stake MLS, geo codes, and LDS Maps.

sgrigg wrote:...most of our units are way behind in keeping them current and they all seem to have come up with their own "definition" of gride size and other parameters when it comes to geo codes. Our presidency would like to use this tool in making adjustments to current boundaries. It almost appears that we need to start from scratch with a consistent definition of the grid size for geo codes.

You need to understand that the Stake owns the stake geo code field in stake MLS. However, under circumstances described in this post, you may see values in the stake geo code fields, that have flowed there from ward level MLS. You'll be best off if you do as Allan recommends and define and enter your own codes. Just disregard any existing values that may already be there. Your changes will not be flow back to the ward level and thus will have no impact on their use of geo codes. I would also recommend reading this thread.

Many Moons ago (we won't go there...), our Stake set up Geo Codes for the entire Stake. It is a 4-digit alpha-numeric grid system, like F3AB, where F3 is the location vertically and AB is the location horizontally in the grid. Each Ward was provided a boundary map with their grids identified. Alan's point about making the grids small enough that you don't straddle 2 wards is very good advice. The ward is "required" to maintain their Stake GEO Code field to match the Stake Grid and is allowed to do whatever they want with the Ward GEO code field.

From time to time, we receive "friendly" reminders from the Stake Clerk to keep it updated. I don't know how other wards fare, but this is something we just automatically do every time a new member moves into the ward:
1. Lookup their GEO code and add it to their record.
2. Add the families Emergency Preparedness Group for a custom report.
3. [Monthly] Provide a new Emergency Preparedness group list to the EQ President and HP Group Leader for distribution to the appropriate Emergency Preparedness Captains (showing the new members now in their group).

By doing this consistently, the only time we have not been up-to-date is when we have a member moved into the ward with a bad or PO Box address.

Dave

davesudweeks wrote:Many Moons ago (we won't go there...), our Stake set up Geo Codes for the entire Stake. It is a 4-digit alpha-numeric grid system, like F3AB, where F3 is the location vertically and AB is the location horizontally in the grid. Each Ward was provided a boundary map with their grids identified. Alan's point about making the grids small enough that you don't straddle 2 wards is very good advice. The ward is "required" to maintain their Stake GEO Code field to match the Stake Grid and is allowed to do whatever they want with the Ward GEO code field.

From time to time, we receive "friendly" reminders from the Stake Clerk to keep it updated. I don't know how other wards fare, but this is something we just automatically do every time a new member moves into the ward:
1. Lookup their GEO code and add it to their record.
2. Add the families Emergency Preparedness Group for a custom report.
3. [Monthly] Provide a new Emergency Preparedness group list to the EQ President and HP Group Leader for distribution to the appropriate Emergency Preparedness Captains (showing the new members now in their group).

By doing this consistently, the only time we have not been up-to-date is when we have a member moved into the ward with a bad or PO Box address.

Dave

As you indicate, a Stake can decide to have the wards maintain stake geo codes at the ward level. I can think of several reasons, which I don't have time to enumerate now, which would make a boundary realignment project pretty frustrating, if the stake geo codes were managed at the ward level. I'm pretty sure that topic has been previously discussed, possibly in one of the threads I linked to in my last post.

danpass wrote:As you indicate, a Stake can decide to have the wards maintain stake geo codes at the ward level. I can think of several reasons, which I don't have time to enumerate now, which would make a boundary realignment project pretty frustrating, if the stake geo codes were managed at the ward level. I'm pretty sure that topic has been previously discussed, possibly in one of the threads I linked to in my last post.

No arguement there. However, as Ward Clerk, I can change the Stake GEO code field. Hence, the Stake Clerk has to do one of the following (in my opinion):
1. Enter all the GEO Codes himself, instruct the wards to leave them alone, and hope they do. Then correct them when a Ward Clerk does not leave them alone.
2. Provide a consistent GEO Code map to the Ward Clerks and instruct them to keep the Stake GEO Codes up-to-date. If any are not, work with/train the Ward Clerks to fix their process.
3. Ignore the GEO codes except when a boundary change is immenent.

I have never served as Stake Clerk, but without that experience, I would first lean to option 2 as the best way to maintain it. Perhaps I am just naive, but I ALWAYS try to have everything accurate and correct, even if it is a Stake GEO Code that we are asked to keep updated.

davesudweeks wrote:No arguement there. However, as Ward Clerk, I can change the Stake GEO code field. Hence, the Stake Clerk has to do one of the following (in my opinion):
1. Enter all the GEO Codes himself, instruct the wards to leave them alone, and hope they do. Then correct them when a Ward Clerk does not leave them alone.
2. Provide a consistent GEO Code map to the Ward Clerks and instruct them to keep the Stake GEO Codes up-to-date. If any are not, work with/train the Ward Clerks to fix their process.
3. Ignore the GEO codes except when a boundary change is immenent.

I have never served as Stake Clerk, but without that experience, I would first lean to option 2 as the best way to maintain it. Perhaps I am just naive, but I ALWAYS try to have everything accurate and correct, even if it is a Stake GEO Code that we are asked to keep updated.

If the stake geo code worked as you believe it works, I might be more inclined to agree with you. Read this post and you'll see what I mean. When/if the stake assumes control of the stake geo code field in stake MLS, by creating or changing a value in that field, any changes made at the ward level, cease to flow to the stake level. Also, whatever is done with that field at the stake level is only visible in stake MLS. It does not flow back to the ward. This is important, in that it helps keep things under wraps when boundary realignments are being considered.

danpass wrote:If the stake geo code worked as you believe it works, I might be more inclined to agree with you. Read this post and you'll see what I mean. When/if the stake assumes control of the stake geo code field in stake MLS, by creating or changing a value in that field, any changes made at the ward level, cease to flow to the stake level.

What happens if a new record moves into the stake (Geo Code is blank), but before the stake enters a code on their end, the ward clerk enters a code on his end? Can the stake tell that it's a ward-entered code and not a stake code? If they can't, then item #1 still applies.

RussellHltn wrote:What happens if a new record moves into the stake (Geo Code is blank), but before the stake enters a code on their end, the ward clerk enters a code on his end? Can the stake tell that it's a ward-entered code and not a stake code? If they can't, then item #1 still applies.

I'm not aware of any indication from MLS as to the origin of the value in the field. The stake could use new move-in reports to identify households that need geo codes assigned, if there is a current need for that to happen.

danpass wrote:I'm not aware of any indication from MLS as to the origin of the value in the field.

That's what I was afraid of.

danpass wrote:The stake could use new move-in reports to identify households that need geo codes assigned, if there is a current need for that to happen.

While it sounds like it would work, it also seems like a system that would fall into disuse quickly unless there was active interest in boundary re-alignment.

RussellHltn wrote:While it sounds like it would work, it also seems like a system that would fall into disuse quickly unless there was active interest in boundary re-alignment.

In our stake, we only care about what is in this field when a boundary realignment is being considered. When this need arises, we verify and update geo codes for affected segments of the stake as needed. There is no reason for us to care if or how the wards use this field at the ward level.

RussellHltn wrote:What happens if a new record moves into the stake (Geo Code is blank), but before the stake enters a code on their end, the ward clerk enters a code on his end? Can the stake tell that it's a ward-entered code and not a stake code? If they can't, then item #1 still applies.

Our stake uses a set of Geo Codes that is easily recognizable by the stake clerks. About once a month (or more often during moving season), one of the stake clerks opens the Geo Code window in MLS, sorts on the Geo Codes, and updates any that do not fall into the parameters the stake prefers.

The wards know how the stake geo codes. Some wards update their stake field accordingly, others do not. And, unless the stake is actively involved in a re-alignment activity, it does not matter to the stake. We prefer to keep them up on a regular basis so that, should there be a need, they will be more readily available.

Question on Geo Code usage. To use the Geo Codes for Ward boundary adjustments, as our Stake Clerk do we have the wards enter the Geo Codes we assign in the Stake Geo Code field or the Ward Geo Code Field? If the answer is Stake Geo Field, does it flow to our Stake MLS with send receive? Looking for help not having done this before and yes we are starting over or from scratch however you say it to get it uniform.
Thanks,
Bruce Arnold
Driggs Idaho Stake Clerk

If you want to guarantee it is done correctly and in a timely manner, the Stake will likely have to do it. However, my suggestion is try to get the Wards to do as much as you can. A few years ago, our Stake did a big push for the wards to update the GEO Codes in MLS. You might have a few Ward Clerks who don't mind taking care of their piece quickly, thus reducing the burden of doing the entire Stake.

I don't know how our stake is doing overall, but I can tell you that our ward is currently at 100% compliant to our Stake-assigned Geo-Codes and since that first push we have rarely had anyone unassigned for more than a few weeks. The first thing our Clerks do when a new member moves in is check their address formatting, update their Geo Code, and add the family to their appropriate Emergency Preparedness Group. The only time we have a snag is when someone is moved into the ward with a P.O. box or no address.

@barnold, if you read the posts and the other linked to posts of this thread your questions are answered.

I really didn't get my answer to my question. Do the Wards enter the code in Ward Geo Code field or Stake Geo Code field in their MLS so the Stake can use it for Ward Boundary adjustments?

The ward geo code does not propogate to the stake. The stake geo code does but only if the stake does not already have a code provided in stake MLS.

Please look at this post below, which says if the ward entered a Ward Geocode but not a Stake Geocode, the Ward Geocode wil flow to the Stake MLS as the Stake Geocode.
Sorry to be so thickheaded, but I am confused by this post and your most recent reply to me.



Join DateMar 2008
[INDENT]
Originally Posted by mkmurray
I don't know what happens when I populate the Stake Geocode field. It stays populated in our local instance of MLS and never gets changed by anyone from the Stake install of MLS...



I figured this out once. There are actually three geocodes. The Ward Geocode, the Stake Geocode recorded in the ward MLS, and the Stake Geocode recorded in the stake MLS.

The ward can enter a Ward Geocode and/or a Stake Geocode. They are independent. A ward could enter two different codes, one to use at the ward and the other as a stake code. The ward enters one or the other of these two codes and they never change unless the ward changes them.

At the stake, there are several different possibilities. The stake can see the Ward Geocode but cannot change it. The stake can also manage the Stake Geocode (in the stake MLS). This is where the fun begins.

The stake can enter a Stake Geocode in the stake MLS. If this is done, the Stake Geocode does not change unless the stake changes it again.

If the stake does not enter a Stake Geocode in the stake MLS, the ward can send either their Ward Geocode or their Stake Geocode (the stake code they entered in the ward MLS).

If the ward entered a Ward Geocode but not a Stake Geocode, the Ward Geocode will flow to the stake MLS as the Stake Geocode.

If the ward entered a Stake Geocode in the ward MLS, the Stake Geocode will flow to the Stake MLS and become the Stake Geocode in the stake MLS.

Once the stake receives a code from the ward or enters a Stake Geocode in the stake MLS, the stake code stays and does not change, no matter what the ward does. Only the stake can change it.

Finally, the Stake Geocode in the stake MLS never flows to the ward MLS.

And that's about all I know about geocodes. [/INDENT]

barnold wrote:Please look at this post below, which says if the ward entered a Ward Geocode but not a Stake Geocode, the Ward Geocode wil flow to the Stake MLS as the Stake Geocode.

That is correct. My post was not as detailed and did not cover all the possible combinations. Note the conditions under which the ward MLS geocodes will flow to stake MLS. Also note that once the stake has geocodes, whether entered manually in stake MLS or received previously from the ward, no further geocode changes will be received.

The flow of geocodes from ward MLS to stake MLS requires the geocodes in stake MLS to be empty or blank and the ward must do a File > Send Membership Data to Stake. If there are geocodes in stake MLS and the stake would prefer to use the ward Stake Geocode, or Ward Geocode if the ward Stake Geocode is empty, the stake would have to delete the geocodes and the ward do another File > Send Membership Data to Stake.

I'm glad this post continued. We have had numerous moves within our ward and we have dutifully updated the Geocodes as members moved to a new Geocode location. I never even thought that the structure of MLS would prevent those updates from correcting the Stake Data - so thanks for letting me know I have been wasting my time all these years

Actually, I know it isn't a waste because new members moving into the stake are being updated and we use the same Geocodes as the root of our Ward Emergency Preparadness groups. However, I may just update the Ward Geocode going forward and ignore the Stake Geocode column.

davesudweeks wrote: However, I may just update the Ward Geocode going forward and ignore the Stake Geocode column.

I wrote the detailed description that was quoted earlier.

As has already been mentioned, the ward can populate either the ward or the stake geocode. Having both allows the ward to use whatever geocode they wish to use, and send a different one to the stake. If the ward only populates the ward geocode, that code goes to the stake (if the stake does not already have a code). If the ward populates the stake code on the ward system, that code goes to the stake (again, if the stake does not already have a code).

It is still helpful for the ward to populate one of the other of the codes. The stake sees it, even if it does not flow to the stake, and the stake can manually pick it up if they wish to do so.