GEO Codes and Boundary Realignment

[lajackson]

I think they were a straightforward and negative review of a bad software design, a criticism with which you disagree. . . .

But except for lajackson's intrepid reverse-engineering that is published deep in these forums, I would never know this other behavior was happening.

Well, I would characterize it more as simply paying attention to the detail of what was happening so that I could make it work for my purposes.

The only person for whom this matters at all is the stake clerk. He either instructs the ward clerks to enter a second geocode in the ward MLS for the stake field or he does not. He either uses the information from the ward or he does not. The ward clerk doesn't care.

As for the design and programming of MLS, don't even get me started. This thread is about geocodes. I suppose we could start a thread on software reviews, but it would not really solve any of my MLS problems. And, I promised a long time ago when I joined that I would behave here. [grin]

I have learned that, for better or worse, the Church has different objectives in its programming than having a nice, polished, software product to sell on the commercial market. Specific functionality is key. Within MLS, some areas are more important than others, geocodes (along with a number of other things) are way down the list of priorities, and the programmers don't give a whit about . . . ok, I'll stop right here. The developers do listen to bug reports, prioritize them, and try to do what they can about the ones that affect the most folks.

I get more answers from this forum than anywhere else, because folks who participate in this forum are on the front line trying to make it all work and have more experience than anyone else. And yes, it is Ok to discuss what works and what does not, and how to work around it where possible to get the job done.

The bug reports are of much higher quality after some discussion and experience here in the forum.

[aebrown]

Aebrown and lajackson, the system does have a bug as I have tried to outline. On the stake computer neither of the "Remove" buttons does anything and they certainly don't change the Stake Geo code back to the "add button". However, the next time I go back to the stake computer I will change all those extraneous ward geo codes to one code as you have suggested and hopefully that will get rid of all the extra extraneous codes now residing in the drop down list.

Okay, I took a closer look at this on live data (the test data is not helpful for this issue). I'm pretty sure that I know exactly what is happening.

1. When you press the Remove link and choose to remove a stake geo code, the code is indeed removed.
2. But, when a stake code is removed, and a ward code exists, that ward code is immediately copied to the stake geo code. Thus it may appear that nothing has happened.
3. If a stake code is removed, and no ward code exists, then the Add link will appear in the stake geo code column.
4. You can indeed replace a stake geo code with another code.
5. But if a stake code that doesn't match the ward code is removed, then the ward code immediately is copied into the stake geo code, as mentioned in #2 above.
6. When the last instance of a stake geo code has been removed or replaced, that geo code will no longer appear in the selection list.

So although it may appear that the Remove link is not functioning, that is not really what is happening. The apparent change is that the ward code flows to the stake code immediately when the stake code is blank and the ward code exists.

That's certainly a problem -- the stake should be able to set the geo code to any value it wants, including a blank value. But at least this explains why some people could duplicate the problem and others couldn't -- it all depends on whether a ward had defined a geo code or not.

There also seems to be a problem where a ward modifies or removes ward codes, and those don't flow to the stake. I have not taken the time to verify that problem yet -- the above statements apply only to the issue with stake MLS itself.

[russellhltn]

That's certainly a problem -- the stake should be able to set the geo code to any value it wants, including a blank value.

Then how would the stake get the wards stake code into that field?

Can you save a value that is a single space? That would give the appearance of a blank value.

[aebrown]

Then how would the stake get the wards stake code into that field?

I don't understand what you are asking.

Can you save a value that is a single space? That would give the appearance of a blank value.

A space is not allowed. But you could use a period, which is pretty unobtrusive. However, that's not really the point. There is a reasonable desire to return the stake code to the default value of not being present at all, which leads to the Add link appearing in the stake geo code column. Even if a space were allowed, that wouldn't accomplish that goal.

[lajackson]

Okay, I took a closer look at this on live data (the test data is not helpful for this issue). I'm pretty sure that I know exactly what is happening.

1. When you press the Remove link and choose to remove a stake geo code, the code is indeed removed.
2. But, when a stake code is removed, and a ward code exists, that ward code is immediately copied to the stake geo code. Thus it may appear that nothing has happened.

So although it may appear that the Remove link is not functioning, that is not really what is happening. The apparent change is that the ward code flows to the stake code immediately when the stake code is blank and the ward code exists.

There is a reasonable desire to return the stake code to the default value of not being present at all, which leads to the Add link appearing in the stake geo code column. Even if a space were allowed, that wouldn't accomplish that goal.

Thank you for the research. You make a very valuable point about the desire to return the stake code to the default. On the other hand, if it actually returned to a blank field rather than immediately reposting the ward code, the ward code is going to return the next time it is sent on a Send/Receive anyway, the way the program is currently set up.

So unless the underlying architecture is changed, the current immediate return of the ward code should be expected.

I am finding myself in the camp of wondering why the ward code flows to the stake. I suppose the original concept that it allows the ward to help the stake is still true, as long as the wards cooperate and have made good geocode decisions.

Other than that, I guess I just don't really see the need. A stake clerk who has helped divide two dozen wards and a half-dozen stakes over five years might, though.

[aebrown]

So unless the underlying architecture is changed, the current immediate return of the ward code should be expected.

That's possible, but in my mind, any setting of the code at the stake level -- including removal of the code -- should be treated as an indication that the stake has overridden the ward's code that was copied into the stake field. The stake's wishes should prevail.

I am finding myself in the camp of wondering why the ward code flows to the stake. I suppose the original concept that it allows the ward to help the stake is still true, as long as the wards cooperate and have made good geocode decisions.

As I've mentioned before, the ward geo code can be helpful to the stake, since wards generally know their neighborhoods better than the stake does. But that's merely an argument for making the ward geo code available on the stake level, not for automatically copying the ward geo code into the stake geo code field. A kinder implementation would be to have a feature in stake MLS that allows the ward geo code to be copied into the stake code, either for a single household or in bulk. Then the stake clerk can decide if or when the stake code is affected by the ward code.

[RossEvans]

I am finding myself in the camp of wondering why the ward code flows to the stake. I suppose the original concept that it allows the ward to help the stake is still true, as long as the wards cooperate and have made good geocode decisions.

As I've mentioned before, the ward geo code can be helpful to the stake, since wards generally know their neighborhoods better than the stake does. But that's merely an argument for making the ward geo code available on the stake level, not for automatically copying the ward geo code into the stake geo code field. A kinder implementation would be to have a feature in stake MLS that allows the ward geo code to be copied into the stake code, either for a single household or in bulk. Then the stake clerk can decide if or when the stake code is affected by the ward code.

There may be a consensus evolving here. I suggest the business rules for revised Geo Code functionality might be:

1) The ward should own the Ward Geo Code field in ward MLS and stake MLS. Only the ward clerks could edit this data, and it should always flow to the Ward Geo Code field in stake MLS as read-only data that updates that content unconditionally. This field should not flow automatically by default to the Stake Geo Code field in either system.

2) The stake should own the Stake Geo Code field in ward MLS and stake MLS as a matter of policy. The stake may request the ward clerks to assist by populating the Stake Geo Code field in ward MLS so it can flow to the Stake Geo Code in stake MLS, but it should not overwrite non-null content there.





3) Within stake MLS, the stake clerks should be empowered to expressly control the Stake Geo Code content with user-interface functions to:

• Remove (clear to null) a single Stake Geo Code value. (This may just done with Select-Cut)
• Globally remove (clear to null) all Stake Geo Code values per unit.
• Globally copy all Ward Geo Codes per unit to fill non-null Stake Geo Code values.
• Copying a single Ward Geo Code value to a Stake Geo Code value can probably be done by Select-Copy-Paste.

4) Within ward MLS, the ward clerks should be empowered to

• Remove (clear to null) each Ward Geo Code or Stake Geo Code value. (This may even be done with Select-Cut)
• Globally remove (clear to null) all Stake Geo Code or Ward Geo Code values.

This basically would eliminate today's overly automated default functionality and replace it with user-managed functionality, mostly controlled by stake clerks. If they do want the Ward Geo Code values to flow to the Stake Geo Code, they can do that with one or two clicks. If they don't, they no longer have to try undoing the default flow record-by-record.

Of course, if developers are opening up this logic, it would be highly beneficial as a next step also to allow an external CSV file to be imported and populate the Geo Code fields.

This is probably the shortest route to leverage the work done by the LDS Maps team and ward clerks capturing lat/lon values, as well as any external GIS preprocessing, to generate the codes themselves. (jwtaber has been begging for this simple enhancement for years.) Traditionalists could be still be satisfied that the demographic totals were being calculated within MLS. Surely this would be easier to implement than building minimal GIS functionality into MLS or MLS-web (which should still happen someday as a further evolutionary step).

That way, ward clerks can be better redeployed to their recent assignment of capturing precise lat/lon placement on the maps.lds.org site manually for each household. It is kind of a lot to expect them to do this more modern geocoding as well as key in the legacy Geo Code data for the stakes.

[rhusted]

Has anyone in this forum attempted boundary realignment using the new online maps application (https://lds.org/maps/index.jsf)? It's unfortunate that the dots aren't different colors based on Priesthood, or that you can't change a boundary line to see what that results would be. I can only imagine that such an improvement to the maps software would save poor Stake Clerks hundreds of hours in realigning boundaries and/or creating/dissolving units. But I'm wondering if anyone has attempted to use the online maps and if they had any recommendations.

[samsymons1]

Dear Person,
Thank you for educating me about GO Codes. I helps me be thankful for stake clerks and assistant stake clerks and their talents that they all use.
Sincerely,
Sam Symons!

[RossEvans]

Has anyone in this forum attempted boundary realignment using the new online maps application (https://lds.org/maps/index.jsf)? It's unfortunate that the dots aren't different colors based on Priesthood, or that you can't change a boundary line to see what that results would be. I can only imagine that such an improvement to the maps software would save poor Stake Clerks hundreds of hours in realigning boundaries and/or creating/dissolving units. But I'm wondering if anyone has attempted to use the online maps and if they had any recommendations.

That general concept has been under discussion here for years. (See the top of this thread, for example.) [EDIT: Never mind. I misread the date on rhusted's comment, which was actually from several years ago.]