GEO Codes and Boundary Realignment

[RossEvans]

The utility of the hard-keyed GEO code fields for boundary analysis, invented when paper maps were the norm, is diminishing. It is no secret that the church is moving toward capturing precise lat/lon coordinates for every member, which will be much more flexible and useful. Meanwhile, geographic software using such coordinates continues to proliferate.

As far as I know, our stake abandoned the use of GEO code fields in MIS some time ago, and uses GIS software instead. (See the top of this thread.)

As for the ward GEO code field, since ward MLS software does nothing with this data except allow users to key something in and get it out again in a simple report or export, the data element is basically free-form 8-character text. Its principal value is that the field is integrated into MLS -- which is also a detriment because the only MLS computer is locked in the clerk's office.

[aebrown]

The utility of the hard-keyed GEO code fields for boundary analysis, invented when paper maps were the norm, is diminishing.

And thus this thread completes one revolution around the circle. This will be almost an exact duplicate of the first post in the thread, with you claiming that the geo code field is not very useful, and me repeating that it is the best tool we have now for boundary realignment. I am grateful for the contributions you have made by sharing your expertise and experience in many of the uses of accurate lat/long for many other purposes. But that is not the topic of this thread -- it is boundary realignment.

I have not yet heard of a workable alternative where GIS is used independent of MLS geo codes for the real process of boundary realignment, which you admit you have not been involved in, but several of us have. I'd love to hear practical advice as to how clerks are able to simplify the process of boundary realignment beyond that provided in MLS, but I haven't heard it yet.

[RossEvans]

And thus this thread completes one revolution around the circle. This will be almost an exact duplicate of the first post in the thread, with you claiming that the geo code field is not very useful, and me repeating that it is the best tool we have now for boundary realignment.

I do not disagree that the GEO Code field "is the best tool we have now," if that means only church-supplied software. However, if one includes third-party GIS tools in the definition, then I certainly disagree.

True, I haven't done unit boundary realignment hands-on, but I have viewed the church training video and done similar non-stake tasks with church and non-church data. And my understanding is that our stake now uses GIS software for boundary analysis, tabulating the various unit demographics and statistics directly. As I understand it, that is all the stake MLS system does, except it uses the hard-keyed GEO code values instead of dynamic geographic queries.

The point of my comment a few minutes ago was just to make a forward-looking observation about where the church software seems to be headed. We know that an official geocoding solution is already in the works. Someday I expect there will be some kind of GIS-based tools provided. I wonder whether that will be in MLS on the web. Until that happens, third-party desktop GIS seems like a viable and efficient option. The principal barriers I can think of are budget and learning curve, and getting the geocoding done somehow.

Am I correct that there is not a policy requirement to use the GEO code fields in MLS to tabulate the detail of a boundary proposal, only that such tabulation be performed somehow and submitted on the form to CHQ?

[aebrown]

I do not disagree that the GEO Code field "is the best tool we have now," if that means only church-supplied software. However, if one includes third-party GIS tools in the definition, then I certainly disagree.
... my understanding is that our stake now uses GIS software for boundary analysis, tabulating the various unit demographics and statistics directly. As I understand it, that is all the stake MLS system does, except it uses the hard-keyed GEO code values instead of dynamic geographic queries.

I did not say, nor did I intend to say, that I was limiting my comments to Church-supplied software. If indeed your stake is using GIS software to do boundary analysis, then I stand corrected. However, I think it's safe to say that with the current state of GIS software, there are very few stakes in the Church that have clerks with the expertise to use such software for these purposes.

Looking forward is great, and that's how we'll make the helpful innovations we all hope for. I did not mean to dismiss the possibility of such innovations; on the contrary, I very much welcome them. I was simply focused on the what is available and practical now for general use by stakes doing boundary realignment.

Am I correct that there is not a policy requirement to use the GEO code fields in MLS to tabulate the detail of a boundary proposal, only that such tabulation be performed somehow and submitted on the form to CHQ?

You are entirely correct. MLS geo codes may be helpful in gathering the data used to submit the boundary realignment proposal, but that is certainly not required. Any means of gathering accurate information for that form is acceptable.

[RossEvans]

You are entirely correct. MLS geo codes may be helpful in gathering the data used to submit the boundary realignment proposal, but that is certainly not required. Any means of gathering accurate information for that form is acceptable.

Thanks. That was my understanding but I was not positive.

I don't know all the details of what statistics are included in a boundary proposal. But I would be very much surprised if the data included any attributes not included in the four core MLS export files, particularly Membership.csv. (I surmise that such factors as the number of priesthood holders with current temple recommends, youth, etc. are important.) Any decent GIS package should be able to import these four files as data tables. I do it at least once a month for our ward.

Edit: If the calculations include any finance data, such as the number of full tithepayers, of course that would would be excluded from the MLS export files. But that condition seems implicit in holding a temple recommend, which data is included.

I am interested in the experience of JTaber, whose posts here indicate that he uses GIS software as part of his stake calling. I have wondered why he apparently takes the step of keying the GEO codes back into MLS. Perhaps that is the way his stake president wants it done, or perhaps it serves some other local purpose.

As far as the inherent task of tabulating the what-if statistics for a boundary proposal is concerned -- after the analytical work is done offline in GIS software -- keying all the GEO codes back into MLS strikes me as similar to using an adding machine to validate the results of a spreadsheet from the raw data. I have sufficient faith in spreadsheets and GIS software to know that is not really necessary. There are easier ways to check one's work for human error, such as confirming that all the crosstabs balance with the totals.

[lajackson]

We know that an official geocoding solution is already in the works.

Did I miss reading something about this earlier?

Am I correct that there is not a policy requirement to use the GEO code fields in MLS to tabulate the detail of a boundary proposal, only that such tabulation be performed somehow and submitted on the form to CHQ?

You are correct. You may gather the information to be submitted on the form in any way you wish. In fact, there is some information required that cannot be gathered from MLS in any form or fashion. [grin]

[lajackson]

I am interested in the experience of JTaber, whose posts here indicate that he uses GIS software as part of his stake calling. I have wondered why he apparently takes the step of keying the GEO codes back into MLS. Perhaps that is the way his stake president wants it done, or perhaps it serves some other local purpose.

It is not about checking the work. It is about using the proposed new information to drive the MLS reports that are needed to review the proposal and determine if it is acceptable or not.

It is about putting names with the numbers to make sure the new units are viable. It is about the ability to make small changes to make the proposal a better one.

It is about the what if's that are a critical part of the decision making process by the stake president. These considerations require that the full range of information about a member or family be available. That only happens in MLS.

That is why JTaber put the Geo Code information back into MLS.

[RossEvans]

We know that an official geocoding solution is already in the works.

Did I miss reading something about this earlier?

Geocoding of members is inherently part of the member-mapping project that was announced last year. Somehow, lat/lon information will need to get captured for every member record. My assumption is that the process will have an automated step combined with correction by clerks.

It is not about checking the work. It is about using the proposed new information to drive the MLS reports that are needed to review the proposal and determine if it is acceptable or not. ...

That is why JTaber put the Geo Code information back into MLS.

My point is that all those numbers can be computed by any decent GIS package directly. Rekeying the codes into MLS to allow it to replicate that computation is not necessary. And as you and Alan_Brown confirm, it is not required by policy.

[mkmurray]

Did I miss reading something about this earlier?

There was a comment a while back (seems like an eternity ago) from either Joel Dehlin himself or some other Church employee implying that an official geocoding solution was in the works. There was only 1 or 2 comments that seemed to indicate this and they were quite a while ago. I have not seen a comment lately to confirm that this is still the case. Alas, boomerbubba holds on faithfully to that hope.

[RossEvans]

I have not seen a comment lately to confirm that this is still the case. Alas, boomerbubba holds on faithfully to that hope.

I and others note that the church member-mapping project has not achieved release. I understand. It is ambitious. But yes, I still have faith.