Membership maps

[goldcntry-p40]

Personally, in my discussions with friends and family, a more general mapping using Google Earth is more along the lines of most of my associates wants.

i.e. We're looking for Ward/Stake/Area/Mission/Temple bounderies shaded or outlined on the map with appropriate screening options included. For instance, while looking for a place to live in Taylorsville, I wanted to look in the area of a specific Stake and Ward but had no real idea of the actual bounderies. Being in California, our bounderies are a little more... ummm... less complicated. However, you get into a more member-intensive neighborhood or community and you may have three stakes within a five-mile sphere. One block could end up being a junction point for five Wards, two Stakes, and three Temple districts! (point-in-fact: the Stake/Ward I was looking at is one of the most compact in the entire church)

Having a comprensive map that shows ward boundries with appropriate meeting houses and stake centers would be invaluable in my estimation. It wouldn't show individual member addresses, so the privacy issue shouldn't come up.

[RossEvans]

Having a comprensive map that shows ward boundries with appropriate meeting houses and stake centers would be invaluable in my estimation. It wouldn't show individual member addresses, so the privacy issue shouldn't come up.

I thnk there is demand for both boundary and member mapping. (In our ward, the leadership uses member-mapping for several purposes. And many rank-and-file members want it, too.) The priivacy issues for KML files are manageable, just as the privacy issues for downloaded CSV files are manageable. All members who log on to the LUWS site are already trusted with those.

Meetinghouses are already mapped at maps.lds.org. And the Church's applications under development are expected to include display of unit boundaries. I don't know if they will also include an easy download function.

In any event, the boundaries themselves are not a secret. Units can get printed maps or PDF files for the asking from CHQ. Given those, it is not difficult to make boundary files yourself in Google Earth. You can just trace the boundaries carefully to create a polygon file. (To get greater precision, I use GIS software to do that and create the KML file, but not everyone requires such precision.)

[goldcntry-p40]

Which GIS software do you use? Are there any good trial/freeware versions available? When our stake re-created all the wards and bounderies earlier this year, I was able to cobble together a fairly accurate map using (mashing together) Illustrator and Photoshop. It'd be great to create a clearer KML file (I'm one of those nit-pickers when it comes to dynamic graphics... *sigh*).

[RossEvans]

Which GIS software do you use? Are there any good trial/freeware versions available? When our stake re-created all the wards and bounderies earlier this year, I was able to cobble together a fairly accurate map using (mashing together) Illustrator and Photoshop. It'd be great to create a clearer KML file (I'm one of those nit-pickers when it comes to dynamic graphics... *sigh*).

I use Manifold (www.manifold.net), a commercial product, at home and at work. Not free, but moderately priced compared to the industry-leading ESRI. There is some freeware out there, but I don't have the experience to recommend any of it. The major investment is really in wetware. Any GIS program is going to have a pretty significant learning curve.

[russellhltn]

There is some freeware out there, but I don't have the experience to recommend any of it.

Any thoughts on QGIS? It sounds like it has enough features, but knowing nothing about GIS, I wouldn't know.

[RossEvans]

Any thoughts on QGIS? It sounds like it has enough features, but knowing nothing about GIS, I wouldn't know.

I just discovered QGIS a couple of months ago, and have not made time to try it. All I really know about the software is from reading the web site. It does have a relational back end (PostgreSQL), and does offer a way to import shapefiles, which are the most common format for publishing public domain data. I didn't notice anything about exporting KML, which is becoming very useful for publishing maps via Google products. But that is not too hard to program.

The price is right. But since I have a pretty full-featured solution in hand, I just haven't been motivated to invest the time. Too much to learn and do elsewhere.

[russellhltn]

Just listing the functions we'd most likely be interested in would be a huge help. I know that's not something I'd know I was missing until I had invested a great deal of time in the product.

[mkmurray]

Just listing the functions we'd most likely be interested in would be a huge help. I know that's not something I'd know I was missing until I had invested a great deal of time in the product.

Or in other words, if you wouldn't mind, please list the most common and helpful features that one would need in GIS software (for the purpose of doing membership maps and the like).

[RossEvans]

Or in other words, if you wouldn't mind, please list the most common and helpful features that one would need in GIS software (for the purpose of doing membership maps and the like).

Well, here is a modest description and primer on features I think are important. I am not trying to define all possible features of GIS systems, but focusing on what I think wards and stakes might need. Conceptually, it is helpful to think of GIS software as a conventional DBMS married to geographic objects. It's not just about drawing maps.

The sofware must read and write common GIS file formats. The most common interchange format is the ESRI-sponsored, open format called a shapefile, which really is a collection of several physical files. (Years ago I wrote some software from scratch to read and create .shp files. I don't want to do that again.) In recent years, the Google-sponsored KML file format also has become important, mostly as a platform for publishing maps to end-users. KML is not readily comparable to a GIS format, partly because it lacks tabular data, but it is becoming a popular display format that does define basic geographic coordinates. (I find it useful that my own GIS sofware, Manifold, will import and export simple KML. To create rich and complex KML, I write my own scripts.)

It is important to remember that just having the GIS software is not sufficient. One must also have base map data for the areas in question. Hopefully the user can locate public-domain sources for such data. Commercial map layers are expensive. A good, but not perfect, source of U.S.base map data is the Census TIGER data, which now is being disseminated in shapefile format. Some states and localites publish their own base map data. (Luckily,my own cityis such a place. If yours is not, start pestering your local officials. They probably have this stuff internally.)

The GIS sofware should be able to read and convert a variety of map projections-- the various schemes that geographers have devised for representing a curved planet on a flat surface. It also should be able to read and convert from one datumto another. (A datum is a mathematical model of the Earth, which is not a sphere but an ellipsoid. Unless you know what datum you are using, you don't know precisely where a given latitude-longitude coordinate is on the planet.)

The GIS platform should provide a GUI for displaying, selecting, editing and creating basic geographic objects (points such as addresses, lines such as streets and creeks, and polygon boundaries defining such areas as counties, cities, census tracts, stakes and wards.) Typically, these geographic objects are organized into separate layers. There should be tools to transform sets of intersecting lines into poylygons, and vice versa. Also, there should be the capablity to combine such objects from different map layers into new layers. The interface should provide easy means to divide existing polygon areas with bisecting line objects or polygon subdivisions, and to merge line and polygon objects. In practice, for example, that allows a user to define a stake or ward boundary that combines streets, creeks, political boundaries and custom-created lines.

The program should provide rich options for formatting and displaying maps that are created by such dynamic processing -- both on screen, in print, and in export formats.

The sofware should provide relational tables for storing, querying and transforming text and numeric data (integer, decimal and floating point) associated with such geographic objects. For example, streets and street segments associate street names and address ranges; creeks typically are associated in network hierarchies; points might be associated with addresses and with families or indiviudals; polygon areas might have names and codes for counties, Census tracts, population values, etc. I consider a decently implemented SQL engine to be the best database platform. It should allow import and export of common tabular data formats and sources such as ODBC or OLEDB in Windows. That way, for example, all the MLS export files can be imported and manipulated as SQL tables. Some of those tables, such as addresses, would be associated directly with geographic coordinates.

The basic SQL query language also should be extended include geographic functions. One such basic function is commonly known as a "point in polygon" query -- find all points from a certain map layer that are within a certain polygon. Similar functions should exist to find lines and polygons that contain, touch or overlap each other. In addition to the query language, it is useful to have a scripting language to perform repetitive tasks, and and API is even better.

Taken together, those functions allow the user to perform such tasks as calculating the total number of members, families, priesthood holders with current temple recommends, YM/YW, etc. within a given boundary area or set of boundary areas. In performing such analysis, the user is essentially performing the same task that a legislature does when gerrymandering congressional districts. The typical method is to divide the overall area into small jigsaw pieces and recombine them in different ways to provide different possible outcomes. A legislature does this with voting precincts; stakes do this with "GEO Code" areas of their own choosing. With a GIS system, it is often useful to start with the work of others, such as the Census Bureau, or postal service, who have professionally created areas such as Census tracts and carrier routes that make intuitive sense on the ground. These can then be customized as needed. Of course it is also possible to invent such jigsaw pieces from scratch. It is also nice if the GIS package provides any easy GUI to do all that what-if querying by clicking around a base map. This is much easier than combining pieces in SQL queries.

Some GIS software offers add-on modules for geocoding. This function can be integrated, and might theoretically involve some of the same base map data. But it really is a distinct function, and I consider the choice of geocoding tools to be a separate question.

There are other nice-to-have features, such as calculating driving directions and measuring driving distances. Even if the GIS software has this functionality, it requires sophisticated base-map data that handles such things as one-way streets and freeway ramps. So it is difficult to implement well in a reasonably priced, standalone package. The online providers such as Google and Microsoft have a natural advantage there because of the expensive base maps they license from providers such as Tele Atlas and NAVTEQ.

For further GIS primer stuff, here is aWikipedia link.

I'm leaving out a lot of stuff. In general, a full-featured GIS program has a lot of complex functionality. So I have no qualms about writing a check for such power if I can afford it. (That's why I like Manifold when I am spending my own money.) I should add that the professional GIS market is dominated by ESRII certainly can't afford ESRI's flagship products myself, and its price tag would make a stake president blanch. Another significant commercial player is MapInfo, which my state agency uses for its web site and some desktop mapping. I like the feature set of Manifold better, so it is on my desktop at work.

[russellhltn]

Thanks for the info! That's a lot to digest.