GEO Codes and Boundary Realignment

[RossEvans]

Tithing declaration status is not uploaded from the ward to the stake. That information is communicated from bishop to stake president via a printed report each January. (It is uploaded from the ward to the Church, but that has no bearing on the current topic.)

No financial information on individual donors is available in stake MLS. Indeed, no financial information of any kind is in any MLS export files, at the ward or stake level.

Thanks for clarifying that.

In that case, unless you know of other data elements in the stake MLS reports required for boundary work that are not present in the four MLS export csv files, I am quite confident that a decent GIS program could do the job.

A GIS application just combines conventional database functionality with geographic functionality. So if you could reproduce the MLS report content by crunching the content of the stake version of Membership.csv in a spreadsheet or DBMS (using the hard-keyed GEO code fields), be assured that you could do it in a good GIS program (using dynamic geographic queries instead.)

The dynamic functionality that GIS brings to this task is a point-in-polygon match. ("Does point X lie within polygon Y?") Once that is present, the implementer can also perform such tasks as: "Find the polygons that contain each point;" "Find all the points that lie within each of the polygons and list their database attributes such as name and age;" or "Count the points with database attribute Z for each polygon in the database," etc.

The points (member-address records geocoded by lat/lon) are fixed by their precise place on the planet. The polygons -- whether individual jigsaw pieces you now know as GEO code areas, or larger areas we know as wards -- can be flexibly defined, combined and redefined as necessary.

HPaulsen has built a basic point-in-polygon implementation into his cool mapping program, although it lacks all the functionality and integration of a full GIS application. Point-in-polygon functionality is not present in simple map viewers such as Google Earth, Yahoo Maps or Bing.

[jwtaber]

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.



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.

But until you rekey the codes into MLS, you can't:

a) put together hypothetical units in MLS and see what they'd look like, names and numbers, or

b) use that same part of MLS to generate statistics to plug back into GIS and generate maps showing where your strengths are.

Yes, it can be tedious moving data between three computers (home, work, church). But it's well worth it, even if it could be more efficient. And even if Salt Lake comes up with something to generate lat/long for everybody (what Bruce Hall sent me a while back would require some polishing at the ward level) I don't see what I do changing much, other than not having to generate lat/longs myself - for most members.

[RossEvans]

But until you rekey the codes into MLS, you can't:

a) put together hypothetical units in MLS and see what they'd look like, names and numbers, or

b) use that same part of MLS to generate statistics to plug back into GIS and generate maps showing where your strengths are.

Thanks for responding. I was hoping you might join this conversation.

But I don't understand your response. What GIS software do you use? All those functions could be performed within the GIS application I use (Manifold).

[jwtaber]

Thanks for responding. I was hoping you might join this conversation.

But I don't understand your response. What GIS software do you use? All those functions could be performed within the GIS application I use (Manifold).

I use ArcGIS 9.3.1 at work, and ArcView 3.2a at home. Theoretically, yes, I could do all that at work, except a) I only deal with households for geocoding, not individual members, b) I really don't have the time to do it all on my lunch break at work, and c) I'm not the only one poking around with the data. If anyone who has access to stake MLS wants statistics for a school district or something, the geocode ranges are on the bulletin board in the stake clerks' office.

Also I can generate geocodes just as easily at home as at work (changing the blocks/districts has to be done at work), though my wife does think I spend too much time on the computer at home. It is easiest to generate new geocodes from the list of households without them, or for a unit or two, from home, and email it to myself so I can print it off at the stake center. And the fact that I usually am just filling gaps, and don't have to do the whole stake each time, saves a lot of time.

This is what works for me after seven years of trial and error, with the software I have access to. It may not work so well for anyone else.

[RossEvans]

I use ArcGIS 9.3.1 at work, and ArcView 3.2a at home.

I actually have never gotten my hands on ArcGIS because I've never worked for an organization that wanted to spend the big bucks for it. (I know it is the market leader among GIS pros.)

Most of the folks in my shop who do mapping or GIS tasks use MapInfo products (mostly for web site development, but some desktop use.) I looked at the functionality of desktop MapInfo and decided I preferred Manifold at any price, so I have a copy at work and a personal copy at home. The integrated SQL engine in MapInfo is right up my alley, since I am a database generalist rather than a GIS specialist. The price is so moderate (low three figures) that this full-featured GIS package can even fit an individual or a unit budget.

The biggest problem of GIS for general clerk use is really the learning curve, I think. It would be nice if the church could provide a tool that incorporated the GIS functionality needed for this vertical application in a simple user interface. (Much of the functionality of a full GIS package is not needed and just confuses end-users.) Theoretically, that could be built in a web-based app or a desktop MLS extension.

From a software-development viewpoint, I think it would make sense to use licensed back-end geographic objects (including free open-source or commercial products) and write a custom interface for a church application.

Another nice resource for an end-user tool, in addition to the vector layers of points, lines and polygons, is a raster layer of eye-friendly. rendered cartographic map tiles (like we see on the map websites of Google, Yahoo or MS Bing) Similar map tiles are now available from public-domain OpenStreetMap.org. Manifold, with the help of third-party components, can integrate the rendered map tiles served by Microsoft or OSM-based providers over the internet.

HPaulsen has built the core of a nice desktop application that marries the map tiles from Google with MLS export data in an embedded SQL database. To this he adds a point-in-polygon match function, which Google's API omits. His app provides a visual tool for users to draw their own polygons by tracing the Google maps, but so far no facility to import, combine and edit GIS layers from outside sources. That, I suspect, would be a complex undertaking. But because the membership data is there in the SQL database, I should think that adding query output to mimic stake MLS boundary reports would be a less difficult enhancement to program. All in all, HPaulsen's tool is impressive and very promising.

[lajackson]

The price is so moderate (low three figures) that this full-featured GIS package can even fit an individual or a unit budget.

I guess everything is relative and it may be true for some. But sadly, this would not be true for the budget of this individual or the unit I support. [grin]

Nevertheless, if it were:

While an excellent GIS package might be able to be programmed to provide all of the functionality MLS already furnishes, what kind of effort would that take? I do not have those database skills.

The labor intensive part of the exercise for me is getting the Geo Codes into MLS. Once a well-defined system is in place, that only has to happen once. Then, all of the needed tools are already there to accomplish the work that needs to be done.

[RossEvans]

While an excellent GIS package might be able to be programmed to provide all of the functionality MLS already furnishes, what kind of effort would that take? I do not have those database skills.

The labor intensive part of the exercise for me is getting the Geo Codes into MLS. Once a well-defined system is in place, that only has to happen once. Then, all of the needed tools are already there to accomplish the work that needs to be done.

I do agree that learning-curve issues are the biggest barrier to widespread use of shrink-wrapped GIS packages. Cost is certainly another. GIS and mapping literacy is growing, however. (I obviously am not the only map geek in my stake, for example, because our stake clerks been doing this already.)

The best hope for non-geeks may be the building of vertical applications that focus on particular tasks. That is HPaulsen's approach, and it has much to recommend it. If users want to draw the small GEO-code areas for from scratch by tracing visually, then have the software match members to areas automatically, his app already provides such functionality.

Using GIS technology for boundary definition the way JTaber and I have described is more complex. It typically involves importing and editing third-party boundary files -- from sources such as Census and local governments --as a starting point. Building that complexity into a vertical app seems more daunting to me, and there is some inherent complexity for a user to learn about this task whatever the tools is.

As I see it there really are three phases of work to be suipported:

1. Intelligently designing the small jigsaw pieces that correspond to stake or ward GEO Codes. This is mostly a one-time task, but as Jtaber points out the area definitions themselves sometimes have to be adjusted. (For example, the school districts in his region altered their boundaries.) Also, development drives change, and that requires maintenance.
2. Assigning households to those small areas, based on their own geocoded locations. This is an ongoing task because of member moves.
3. Doing what-if analysis of potential boundaries by combining the jigsaw pieces in various configurations. I would guess the frequency of this task would depend on several factors, driven primarily by growth and leadership decisions.

If there is no tool for such support on the church IT drawing boards, a significant advance would be simply to provide for importing certain membership data -- the GEO Code fields as well as several others such as addresses -- from batch files. That way units could find their own solutions without a lot of rekeying.

[LTORDUSA1-p40]

My ward is contained in two small area neighborhoods. I used a simple method to use the GeoCode field. I assigned each residence a three position alpha numeric code. As families come and go they are assigned that specific code. The GeoCode can be sorted and printed to help leadership determine who is living in an apartment complex or on a certain street. Missionaries find it helpful.

[RossEvans]

My ward is contained in two small area neighborhoods. I used a simple method to use the GeoCode field. I assigned each residence a three position alpha numeric code. As families come and go they are assigned that specific code. The GeoCode can be sorted and printed to help leadership determine who is living in an apartment complex or on a certain street. Missionaries find it helpful.

That's a great example of where scale makes a difference. Different tools and methods might be optimal for different densities.

In Wasatch Front units, where the LDS density is very high (90 percent plus in Layton UT?) it is feasible to preprocess a table of all street addresses that exist in a ward or stake boundary. It would be even easier if residential development in the area is essentially stable and complete.

That is less feasible where the density is low and the list of existing addresses is very large and growing. In my ward, that list would not be a few hundred street addresses, but a few hundred thousand.

If one did want to do mapping and apply GIS tools to a high-density area, the appropriate map layers might include detailed parcel boundaries from the county. I have heard of that done in Wasatch units. I have parcel boundaries for my entire ward area and environs loaded in my GIS software, but they are of limited use to us in Texas because we operate at a larger scale. For us, aggregate areas such as Census tracts are more useful.

[RossEvans]

Just as a conceptual footnote, the method describe by LTORDUSA1 -- however useful it may be for other purposes within a ward -- would not be appropriate for stake boundary analysis based on GEO codes because it is too granular. Each household is assigned a unique GEO code. And each code does not represent an area, but a point.

That would be entirely too cumbersome for stake boundary analysis in MLS, I think. For this purpose, stake GEO codes would need to define a moderate number of areas (jigsaw pieces) each of which might contain a moderate number of households.

And any method using stake GEO codes in MLS relies on some external method to ensure that the GEO codes relate to areas in the first place -- in particular non-overlapping contiguous areas. As far as I know, stake MLS has no intelligence about those properties at all. It does not visualize or describe boundaries. MLS basically tabulates the demographics of external geographic analysis, which might also be tabulated externally.